The Git Workflow at Elibom

Recently, I had to choose a git workflow for our nascent development team at elibom.com (I was a solo developer before). Git is so flexible that there are multiple options you can choose from. That’s why I decided to write this post, describing the workflow that we are currently using, largely based on this other post from reinh.com which I really encourage you to read.

We use a centralized workflow with a private repository at Github and we all have push access to it. There are two important rules though:

1. No one is allowed to push to the master branch directly.
2. There is only one integrator that merges changes into the master branch.

1. Creating a branch

Whenever you need to work on a new feature or issue, the first step is to update the master branch and create a new one.

git checkout master
git pull
git checkout -b issue-xx-brief-description

At this point you are ready to start hacking. Notice that the name of the branch has the number of the issue you are working on and a brief description to easily identify it.

2. Working on the branch

I always encourage the team to commit often. This has multiple advantages and you can always reorder and change your commits before pushing them to the remote repository. I usually squash them in one or two commits when I’m done.

Before pushing your branch to the remote repository always run the following two commands:

git fetch origin
git rebase origin/master

These commands apply your changes on top of the remote master branch allowing the integrator to make a clean merge of your branch into master (i.e. without having to solve any conflict)¹.

3. Pushing and initiating the pull request

To push a branch to the remote repository run the following command²:

git push -u origin <name_of_branch>

Now we need to ask the integrator to merge our branch. We do this by opening a pull request³ in Github. We found a problem here because Github creates a new issue for each pull request and we are already using Github Issues. What we really want is to attach our pull request to an existing issue.

Fortunately, there is a tool call hub that you can use to create a pull request and attach it to a Github issue using a single command:

hub pull-request -i <issue_number>

Our pull request is now ready to be merged by the integrator, who can do some code review at this point, further discuss the issue and even ask for some changes to the code⁴.

Caveats

There are some caveats that you should be aware of:

- If there are multiple pull requests opened that conflict with each other, the integrator will have to solve them. The other option is to merge one and ask the other developer to solve them⁵.

- Never do a rebase if you have already pushed a branch. First delete the remote branch with the following command and then push again.

git push --delete origin <name_of_branch>

This workflow has worked really well for us and I hope it helps other teams deciding on their git workflow.

¹ If there are conflicts with the master branch, you will have to solve them at this point.

² The -u flag tells git to start tracking the branch.

³ Git comes with a pull-request command but it’s different from the one of Github.

⁴ Both the developer and the integrator can push more commits to the branch which will become part of the pull request.

⁵ He/she will have to delete the remote branch, rebase and then push again.