GIT: Coming Up With a Good Workflow

A new environment to work in always brings new challenges. And this one is no exception. And i will be working with git from now on. I tried switching before. But always went back to subversion. Because of my job. And for somebody who worked with subversion solely for the past… say 5 to 7 years it’s kind of a new concept and takes some time to get a grasp on. Ok ok. It’s just another version control system. But it takes some getting used to.

And two days ago i kinda got stuck in rebase hell. And had to take some time to figure this all out without doing any damage. Which resulted in another problem. There simply is no revert command like in subversion. But git is pretty smart about this kinda things. So getting the branch full of failed merges back to it’s original state can easily be achieved with two commands and some concentration.

First check the reflog for a point where to start from

$ git reflog

From the output pick the point where to revert back to. Which looks something like HEAD{2}. And run

$ git reset –hard HEAD{2}

So back to square one. My main problem was that i had not kept my branch up to date with the remote repository. Which you can do with the pull command while on the master branch. Or with the rebase command while working on a local branch. Rebase is git’s alternative way of bringing changes together. So the idea behind it is that when your local branch is up to date. The final merge will become as straight forward as possible.

I finally managed to get my changes merged in to master. But did not feel very confident about the whole process. So I need to come up with a steady work flow. And stick to it. To not waste time and run into these rebase disasters.

This is what i have so far. And seems to be a solid routine. Start with a nice new checkout of the project at hand. And branch it for the changes to be done.

$ git clone git://some.repository.url:repos.git
$ git branch dev-branch

After working on the newly created branch for a while. Some changes are bound to be ready to be pulled into master. Keeping an eye on the build logs or commit messages should work fine. When this happens it’s time to bring those changes into the dev-branch. After pulling them into master.

$ git checkout master
$ git pull
$ git checkout dev-branch

If there is a need to rebase the branch with for instance master. This is the moment. This might cause non-fast-forward issues. But i have not completely figured out why i run into these issues every now and then. A way to solve this might be to use the –force switch when pushing to remote. But i am not a big fan of forcing things like this.

$ git rebase

If everything is fine some more work can be done on the dev branch. Until a new change in master is ready to be pulled in. In which case it’s rinse and repeat the previous part. When the changeset is ready to be merged back into master. Switch to master bring it up up o date with a pull. And merge the changes from the dev-branch.

$ git checkout master
$ git pull
$ git push dev-branch

Again when all is fine all changes will be available in master. If something goes wrong during git-rebase and / or merging. Git will kindly state so. And some manual merging with git’s mergetool will have to be done. But that’s something for another day.

comments powered by Disqus