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)
With Git, each branch is not a copy of the files from the parent branch. Instead, it’s simply a pointer to the Commit in the parent Branch from where we created our new branch. With Git when working on a different branch, we tell Git “Move to another branch” (Checkout command) and Git will change our working area to match the desired branch. Again, there is a performance benefit as this entire action is performed locally. Git already contains all the branches on the local machine.
Merging is a lightweight operation. We can merge any branch to any branch. We can merge the entire difference or a specific Commit. Git will find the “Base” Commit where the branches split and allow us to resolve conflicts (This is the same as in TFS)
A good practice with Git is to create a new branch to work on a big feature. Eventually, merging that branch to the master branch and discarding the new branch entirely.
Reference/Tutorial on GIT branching
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”