When working with Git on a distributed team it’s important to follow a process that working code accessible to everyone on the team. The simplest workflow that I’ve found to make this work is the feature branch workflow. The basic idea of this workflow is to always keep the master code branch production ready. When you start to work on anything (feature, bug, spike, task, etc) you create a new branch, do your work in the branch, and then issue a pull request to have your branch’s code merged back in to the master branch (thus making it ready for production deployment).
A side benefit of using pull requests is that it creates an opportunity to incorporate code reviews into your SDLC process. Below are the steps to make it all work. I’m using BitBucket in this example but it works the same for GitHub.
Create a new branch off of the master branch to hold the new work that you are about to do. Make sure you use a meaningful branch name.
git checkout -b add-email-create master
This creates a new branch named add-email-create off of the master branch. The -b parameter will create the branch if it doesn’t already exist.
Now, implement your code as you normally would. Code … add/modify/delete … commit.
At certain points, and before it’s time for a code review you can push your branch’s code to the central repository
git push -u origin add-email-create
This will push the add-email-create branch’s code to the central repository. The
-u flag adds it as a remote tracking branch. After setting up the tracking branch, you can call
git push without any parameters to push your code.
Once you’re ready for a code review, you commit/push the latest changes in the branch to the central repository so that other team members can view it
Now you’re ready to create a pull request. From bitbucket you can view the branch and select “Create Pull Request” from the menu.
Once you select “Create Pull Request” you can edit the notification message, description, recipients, etc.
You and your team can comment on any line(s) of code that need to be discussed as part of the code review. Any additions/changes can be made and checked in against the feature branch and those changes will be included for review/discussion in the code review.
Once the changes are reviewed and ready for deployment they can be merged back into the master branch by clicking the “Merge” button in the Bitbucket UI.
Now that the feature branch code has been merged with the master branch, each developer should update their local copies of the master branch by running
git checkout master
Now whatever automated build/deploy/test/package/etc process that is triggered by a commit to the master branch kicks off.
After the feature branch has been merged into the master branch you can delete it from your local workstation with
git branch -d <branch name>
That’s it. Now pick the next feature/bug/task from your project and repeat the process.