Why Git? Local Repository

There are many reasons to use git, but right now I’m just going to share one of the main ones, having a local repository.

Most people are wary to commit changes until everything works. While this might qualify as good manners when everyone works off of the same repository, it generates a poor history; each commit typically contains many changes across multiple files. This makes it difficult to go back in time and follow the evolution of the code, and hard to single out a subset of changes to revert.

With a local repository you can commit whenever you’ve completed a unit of work. Since the repository is local you don’t have to worry about whether or your commit will break the build — it’s not going to effect your peers. Only once you’ve competed the overarching task do you seek to merge your changes with the master repository, but at that point you’ve not only completed your work but also left a genuinely useful history along the way.

And it’s not just about generating a meaningful history. Because it’s so easy to fork a project and create your own repository. (In fact, not just easy but necessary.) The barrier to contributing to a project is greatly reduced. A few days ago I checked out a subversion repository for someone’s game. After poking around for a bit I thought I could help improve a thing or two, but because the project was hosted using subversion there was no easy way to start tracking my changes. Furthermore, in order to push my changes upstream I would need to write to the project owner, get write-permission for the group, share and review my changes, and only then could I commit them. Needless to say the many barriers to actually committing code are daunting. Worse, while I’m moving through the motions to get access to the repository I am not developing new code because I don’t have a versioned environment to work in.

Finally, having a local repository is essential in order to use branching effectively. Personally, I find that as I develop I often want to explore a line of thought a little further, but I’m not always certain that I’ll ultimately use the end result. This tends to happen especially frequently when refactoring or prototyping new ideas. Of course, in order to be able to do these things confidently I need version control to track my changes. At the same time, I don’t want to clutter the history of the main development branch with changes which are ultimately thrown out. That’s where branching comes in; in these situations I can create a new branch and start experimenting in a versioned sandbox. If along the way I decide I’m going to fix a bug then I can switch back to the main branch and make the necessary changes. After I’m finished experimenting I can merge the two branches if the changes are worth keeping or I can simply move on. Branching is possible in most version control systems, but only when you have a local repository is it cheap enough to be worth using.

Naturally there are many other good reasons to use git. However, I believe that having a local repository is reason alone to adopt some form of distributed version control. Later I’ll try to touch on some of the more git-specific features which make it stand out from the crowd.

Related Posts