Git is a Distributed Version Control System

• each developer has the entire repository, including the entire change history on his/her local machine
• the developer can see changeset history offline or commit (check-in) changes offline to his local repository

Since the entire repository is local, we do everything locally. This includes, but not limited to:

• Committing changes (Check-in)
• Viewing commit history
• Creating a new branch
• Merging branches
• Moving to a different branch
• Deleting branches
• Reverting older commits

Yes we do have to Check-in or ‘Push’ our changes to the remote repository.

“Check-in” within Git is divided into 2 parts: Commit and Push
Developers can now commit locally whatever they want – Ugly code, comments, and work in progress. The other developers won’t get those changes as the commit is performed entirely local on their respective PC. When the code is ready for the team, they can Push the code changes to the remote repository.  This workflow gives the developer addition management of changes and when/how things are pushed into the central repository for team consumption.

The Staging concept…. this is like Included / Excluded changes in TFS. Only staged files will be committed. Again, why? (well say locally modified configuration files can stay out of source control)

TFS/TFVC is Centralized Version Control System

• the developer has a copy of the repository file system on his machine
• offline actions like commits (check-ins)  and seeing history are impossible since the local repository can’t save “changes”

Technically, when using a bundler like webpack, the result will not make a difference with regard to the output of your bundling process.

That being said, dividing the packages in dependencies and devDependencies still helps you (and others looking at your package.json) to understand which packages are meant to end up being a part of the bundle created (dependencies), and which are needed to build the bundle only (devDependencies).

Just remember main principle:

-> If you need package in production put it into dependencies (most likely axios should be in dependencies in your case).

-> If you need package only during development, put it into devDependencies (e.g. unit-test libraries, which isn't needed in productions should be in devDependencies

Summary of important behavior differences:

• dependencies are installed on both:

  • npm install from a directory that contains package.json
  • npm install $package on any other directory

• devDependencies are:

• also installed on npm install on a directory that contains package.json, unless you pass the --production flag.
• not installed on npm install "$package" on any other directory, unless you give it the --dev option.
• are not installed transitively.

Reference: StackOverflow