I didn’t think I would blog about the launch of github, because I thought it was pretty meh. Sure it’s nice to put your projects on it and be able to fork other projects, but it was still pretty useless as there was no way of visualizing all the branches (git is all about the commit graph).
So they fixed their most important flaw and they add features that should make collaboration easier. This makes me really hopeful for github’s future. Github is the place to be for open source projects!
Popularity: 44% [?]
You might have heard about distributed version control systems recently, for example git. There are a lot of articles popping up left and right about DVCS. What I find interesting about this is that version control has again become something to talk about. This is very healthy as version control is such an important tool for software developers.
When I started using using subversion five years ago, version control faded to the background. Subversion greatest strength is its simplicity. After a while, you get used to its quirks and it just works. Sure, some operations are painful, like merging back a branch, but you learn how to do it (and try to minimize to number of times you have to do it).
But five years is a pretty long time in computing terms. Maybe something better has come along. Maybe the reasons you chose something five years ago don’t hold anymore. This applies to everything. Sometimes you come across a company policy that looks stupid. At the time the decision was taken, it might actually have made sense. But things changed (as they tend to) and nobody took the time to check if the assumptions used to make the decision were still true today.
I suggest you use all the hype around git, and the discussions it generates, to revisit, to question all your assumptions about what is version control and what it can do for you. Is version control about sharing code with other developers and having some kind of history and backup? That’s something that, yes, it provides, but it can do so much more.
Have you ever used a VCS that required you to lock a file before editing, to avoid conflicts if two developers edited the file at the same time? If you’ve used any system that doesn’t require it, you just know that it’s a not a real problem. However, how do you explain it to the developer that is convinced that it is a very real problem? That’s the problem I have with git right now after using it for six months. I don’t how to convince people to try it when they raise objections. I can only say that it’s awesome and that going back to subversion from git would be more painful for me than going back to locking file from subversion.
Popularity: 16% [?]
It appears that Rails will switch to git real soon. Nice! However, it means confusion for developers used to svn. You might find a few tips on this blog to help you get started, but right now I want to give you the secret to git mastery:
You need to think in terms of how you want to modify your graph. My what you say?!? A git repository is a directed acyclic graph of commits (the nodes). Huh?? Read this article: Git for Computer Scientists. Do not continue reading before you understand that article. Everything falls into place when you understand that all git commands manipulate these four basic structures: blobs, trees, commits and tags.
From now on, before typing a git command in the shell, try to picture in your head how you want your repository to look after the command. Your best friend is gitk for visualization (use the –all option to see all branches). Run it before and after each command you do with git. Here is what you should be thinking when using these commands:
- git commit: I am creating a new node in my graph, linked to the current node.
- git branch branch_name: I am tagging a node with a name.
- git merge: I am creating a new node that will link two parents nodes, one for each branch I am merging (could be more than two).
- git fetch remote_repos: I am adding all the nodes from a distant repository to my graph.
- git push: I am sending all the nodes I created to a distant repository.
- git pull: I want to fetch all remote nodes AND merge.
Once you think like this, “advanced” git stuff becomes trivial. For example, this morning one coworker realized that his last three commits actually belonged to a branch. Try to visualize the solution. When you think about it, nothing has to change about the actual graph, just which nodes the tag (the branch name) needs to point at. So you just create a branch where you are, on the last commit, and then you can use the reset command to move back the other branch to the correct commit.
That’s the core of git. There are maybe two other things to worry about when using git. The first is the index, which is sort of a staging area where you prepare your commits. The other thing is the way git configuration works and the way it names and references branches (and the special reference HEAD) and remote repositories. Check out the git user manual.
Popularity: 38% [?]