Why git?

Better history, less fear

With a typical version control system, the workflow is:

  1. Check out the project from the central repository
  2. Make modifications
  3. Check in/submit/commit changes back to the central repository.

Depending on the change, step 3 can strike fear into the person doing the change: As soon as the “enter” key is pushed, the changes might introduce a bug into everybody’s code.

As a result, the natural tendency is to submit changes to the central repository as infrequently as possible: Pack in more than one bug fix when pushing code to the central repository. Maybe even toss in a new feature or two with each checkin.

However, with git, you have the ability to commit changes to your own local, private branch as often as you’d like, without modifying the central repository. You can make a separate decision on when you would like to push your local changes to the public repository. The work flow for git has an extra step:

  1. Check out the project from the central repository
  2. Make modifications
  3. Check in/submit/commit changes to the local repository
  4. Check in/submit/commit local changes back to the central repository.

The result:

  • You can and likely will make more commits to your local branch.
  • More commits mean a better history of the changes you’ve made to the repository: You can look back at the commit history and see which lines of code were changed for a particular bug fix, rather than having one big set of changes that fixed 3 different bugs.

Flexibility in where you work

When you checkout a git project, you get the whole repository including all of its history. It contains the same contents as the original contents.
You can do local commits, create new branches, and work as much as you’d like, without needing to be connected to the network or central repository.

When you’re ready to check in to a central repository, connect to a network and push the changes in.

Branching is easy

Branching on some legacy version control systems is left to experts and VCS administrators. Not so with git: Think up a new feature? Create a branch and start working on it immediately. Jump between branches. Merge branches back into the
main branch.

Stash the current changes, do work on another branch, check in the changes in the other branch, then continue back where you did the “git stash” (yes, there really is a “git stash” command).

Flexible and Powerful

Git gives you all you need for basic revision control, of course. But it also gives you the tools needed for advanced revision control.

Git was designed and written by the creator of Linux, which has a similar elegant, simple, yet very flexible and poweful design. Many commands can be integrated together and used as needed even more powerful than single commands by themselves.

Git is like Linux: It not only lets you see how it works, but gives you ability to creatively use the git tools to create something bigger or customized for your requirements.

Git is Fast

Everything about git is fast. It doesn’t slow you down, and doesn’t get in the way.

Next: All Git Object Types: Blob, Tree, Commit And Tag
Previous: What Every Version Control System Must Do