I think I finally get git. I did my first rebase today and I understood what it was doing, and it did what I wanted.
Feeling confident in my understanding of git, and my slight understanding of github, I feel the need to point out a funny little thing I noticed about the brave new world of source control management we all seem to have entered into.
In the good old days, you had version control like cvs or svn.
Everybody checked out, made changes and checked in, if somebody got their changes in before you, you had to merge the updates and commit again. If there was a merge conflict, it was your problem. You had to fix it before you committed.
This spread the responsibility of doing the merging around to everybody and I guess it was unfair in that if you were slower, or committed less often, you had to do more merging. But that’s how it was, erm… still is to some people.
In short, you checked out, you did work and you checked in. Everybody played nice, you tried not to break anything and the build ran off HEAD in the repository.
Git is actually very cool, but I think it is overkill. Mercurial I also found out about, is a happy medium, it gives you all the cool parts of git without having gone overboard the way git does, but that’s just my goldilocks opinion.
Git is the cool source control management system of the decade, and ‘github’ is the new way of working.
So this is what I noticed:
svn/cvs/perforce/etc:
1) check out
2) make changes
3) check in.
git + github.
1) fork project
2) clone your copy of the project
3) check out from your local repository to your work directory
4) make changes
5) add changed files to list of things to commit
6) commit changes to your local repository (admittedly this can be done in one step, but it is actually 2 steps)
7) push changes from your local repository to your forked repository on github.
8) open a pull request to the owner/project manager of the original project you forked, where they will then pull the changes from your forked repository to the main repository.
I think we can safely call this ‘progress’.
I think the oddest thing about this new process, is that svn used to tell you when you tried to commit that you had to update and merge changes first.
The github way, github will mention that your changes will or won’t merge cleanly, but that doesn’t stop you from submitting a pull request.
So the effort of not accepting your pull request becomes the problem of a human (the owner of the project who got the pull request) whereas it used to be a computer that did it.
I don’t know github that well, maybe it’s configurable not to allow pull requests if the merge won’t be clean, but if not, the making-the-human-part-of-the-process seems to be a step backwards.
I realize that github now gives the project owner the flexibility of not accepting changes they don’t want, but, I dunno, where I come from, we’re all supposed to be working on the same team.
Maybe that’s the core difference between the open source environment and the corporate environment: you can ignore the work of open sourcers, after all, you’re not paying them anyway.