It’s been almost a month since I first committed our project to version control under git, but up until now, I didn’t really know how to leverage git to support our two-person development effort. I’ll talk about the project setup that evolved from the past few weeks that’s really working out for me now.
First, a little bit about our setup: we have a server where we have our application deployed, but we also have active development going on right on that server. This is convenient and is a typical workflow for web projects: you’ll make and upload edits to see the changes on the server immediately. I have a local server set up on my laptop that I’ll work on, which saves me the hassle of the upload, and in this case turns out to be nice in that I’m not inadvertently clobbering work on the remote server.
Every once in a while, I’ll need to pull in the latest changes and also push out my work as well. For the longest time, I didn’t have a great way of doing this. Initially, I was just using FTP, at times to cherry-pick files and other times just batch downloading the whole project tree. Needless to say, this is a big waste of time and involved more point-and-click than I could stand. It also doesn’t give a good feeling about being in sync at all.
Sync? Great idea, we can use rsync! We do have shell access after all. The next step came when I wrote an rsync command to pull the files I care about from the remote server to my machine. Rsync is nice because it just transfers differences, so it’s nice and quick. The problem is that it clobbers old stuff, and for a while I was using a separate folder with rsync apart from my working folder and manually diff/patching. This also got annoying.
But wait a minute, I don’t have to worry about clobbering code, I could just create a branch in git and pull the changes into that branch. My own branch will be untouched and I can use git checkout to switch between branches. From there, I can merge that branch with my main working branch!
For example, the team meets at 5pm to continue work on the project. At that point, I will create a branch for myself do work on, and my partner will go about his work on the remote server. When we call it a night later on, I create another branch from the initial 5pm commit and pull in changes from the server using rsync.
At this point, git recognizes the fork, and when you issue a git merge command, git will do its best to merge changes, presenting a list of conflicted files if it can’t resolve them itself.
atsui@atsui-mmx:~/web/letswoosh$ git branch * alex master parris atsui@atsui-mmx:~/web/letswoosh$ git merge parris Auto-merging app/plugins/woosh/controllers/events_controller.php Auto-merging app/plugins/woosh/models/event.php CONFLICT (content): Merge conflict in app/plugins/woosh/models/event.php Auto-merging app/plugins/woosh/views/events/nearby_events.ctp CONFLICT (content): Merge conflict in app/plugins/woosh/views/events/nearby_events.ctp Auto-merging app/views/elements/tag_form.ctp CONFLICT (content): Merge conflict in app/views/elements/tag_form.ctp Automatic merge failed; fix conflicts and then commit the result.
I’ll go through the files, clean up the conflicts, add them back to git, and commit the changes, after which the two branches are successfully merged.
The benefits are clear: no manual diff/patch business, the ability to check out any past commit later on, and a pretty graph to look at. After doing things a pretty hard way, I guess I learned a lesson about using git.
This was really helpful for understanding merge: