Git Workflows

Subversion has been the most pointless project ever started... Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right. – Linus Torvalds

As awesome developers, we all use source control of some kind. (You do, don't you?)

Here at Redmart, we use Git. We love that it is decentralized. What this means is that every developer on your team has a copy of the repository on their local machine. The era of keeping backups of your source folder is over. You can easily reestablish your repository in an event that your repo server is destroyed.

Git is also a tool to help you write cleaner code, roll out features faster, and make your entire development team more efficient. I will touch on a couple of intangible benefits that Git helps us in these areas.

Improve Code Quality (via Pull Requests)

Code Reviews

Pull requests are mechanisms that help a developer notify team members that they have completed a feature, and are ready for the code to be reviewed and merged into the master branch.

It is a dedicated forum for members to discuss the proposed feature, highlight any issues should they find problems with the changes, and even tweak the feature by pushing follow-up commits.

You get the benefit of improved code quality from the collective wisdom and skills of the team. All these can be done through Github's intuitive web interface!

Shared Knowledge

As the team gets bigger, and as individual team members start working on separate features by themselves, or if a new developer joins the team, the benefits of pull requests will become more apparent.

One of the benefits is shared knowledge of the code base. Junior developers in the team benefit from reading the pull requests of senior developers, and can learn the conventions and best practices, in addition to the benefits of code reviews by seniors. Other team members can also be in the loop of the progress of other features that are done in parallel to their own.

It also aids the team in being cross-functional. They will be able to take over a feature develop if the usual developer is unavailable for whatever reasons.

Team Ownership

When team members participate in code reviews and have their feedbacks and code contributions get accepted and merged in with the code base, a sense of ownership will also gradually increase. All members of the team are working towards the common goal of quality code. The effect of which is shipping faster.

A side effect of this is the relief that your team members have your back, and the dreaded guilt of that missed bug is somewhat lessened. :)

Our Workflow

Since Redmart has several development teams, the flow listed here is more general than prescriptive. The important thing is that each team is comfortable with their flow so that they are efficient.

The general flow (features):

  1. Pull to update local develop. There should be no merge commits because ideally we should not be working directly in develop
  2. Check out feature branch, (optional) with a story id (Trello card number) and a short descriptive title, so it is easily traceable:
    git checkout -b qw10-add-something
  3. Do work in feature branch, committing early and often
  4. Rebase frequently to incorporate upstream changes (un-pushed branch only)
  5. Interactive rebase (squash) commits (un-pushed branch only)
  6. Push feature branch upstream
  7. Create pull request for review
  8. Makes changes according to feedbacks, if any, and push changes upstream. Pull request will reflect updates.
  9. Once branch is pushed, use merge to preserve history.

We also make use of Travis for continuous integration, since Git has integration for various CI tools. Once the feature is completed and merged via Github, the feature branch can be deleted.

Git Flow by Vincent Driessen
Pro Git by Scott Chacon