Git gives us all this amazing power to control what we commit and when. We can even go back and modify commits to rewrite history. This power is dangerous. What’s the point of having it?
The reason is that our version control history tells a story of our project. It is up to us what that story says. Git gives us control over what that story looks like.
1) It gives us privacy. Distributed version control means we have a full-fledged repository right on our hard drive. We can use the VCS to save our work without sharing it with the world. By comparison, Subversion is like a big open locker room. If you put your underwear on inside out, then take it off to flip it around, everybody knows it.
2) It gives us a little preview of what we’re committing. The staging area means we can commit some of our changes, then others. This lets us maintain separation of concerns between commits. Programmers love separation of concerns, right?
3) it lets us adjust our commit history as much as we want before publishing them. This is like editing our video in Camtasia before uploading it to YouTube.
4) It lets us save our game. Create branches all day; git is the honey badger in a fire ant nest. We can go back to any savepoint (any commit, really, but branches are like saved games with meaningful filenames).
Now, what you want your story is to look like is another question. Do you want every tiny step and backstep recorded in the main repo? Do you want each major feature to show up as one commit on the master branch? Do you want to see merges as separate commits, or do you prefer the rebase strategy, wherein we pretend our feature development started from where the repo stands when we finish feature development? This is all a matter of aesthetics. The point is that with git, you have the option to consciously choose what you want your version control history to say about your project.
A prospective new team member came in the other day, and he wanted to look at our commit graph. The commit graph speaks about how development occurs, how team members interact. Think about what you want yours to say about you.
I'm not sure about point 1 – just in the sense of empowering developers to go dark. I would rather see some embarrassing code and know what's going on than wait for a big reveal at the end.
beats them breaking everyone's build with a half-implemented feature.
You don't have to merge it into master, just commit and push your branches every once in awhile