Git Workflow

GitHub Flow

1. At GitHub, we do not use git-flow. We use, and always have used, a much simpler Git workflow.
2. The main issue is that we deploy all the time
3. We don’t really have “releases” because we deploy to production every day - often several times a day

So, what is GitHub Flow?

 1. Anything in the master branch is deployable
 2. To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
 3. Commit to that branch locally and regularly push your work to the same named branch on the server
 4. When you need feedback or help, or you think the branch is ready for merging, open a pull request
 5. After someone else has reviewed and signed off on the feature, you can merge it into master
 6. Once it is merged and pushed to 'master', you can and should deploy immediately

That is the entire flow. It is very simple, very effective and works for fairly large teams. I think that most development teams - groups that work on the same logical code at the same time which could produce conflicts - are around this size or smaller. Especially those that are progressive enough to be doing rapid and consistent deployments.

1. Anything in the master branch is deployable

   a. This is basically the only hard rule of the system.

   b. The master branch is stable and it is always, always safe to deploy from it or create new branches off of it

   c. If you push something to master that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything.

2. Create descriptive branches off of master

   a. This is nice because when we go to the GitHub branch list page we can easily see what branches have been worked on recently and roughly how much work they have on them.

3. Push to named branches constantly

   a. lets everyone see, by looking at the GitHub Branch List page, what everyone else is working on so they can inspect them and see if they want to help with something

4. Open a pull request at any time

   a. We use the Pull Requests to review the code long before we actually want to merge it into master for deployment

   b. If you are stuck in the progress of your feature or branch and need help or advice, or if you are a developer and need a designer to review your work (or vice versa), or even if you have little or no code but some screenshot comps or general ideas, you open a pull request. You can cc people in the GitHub system by adding in a @username, so if you want the review or feedback of specific people, you simply cc them in the PR message (as you saw Josh do above).

5. Merge only after pull request review

   a. We don’t simply do work directly on master or work on a topic branch and merge it in when we think it’s done - we try to get signoff from someone else in the company

6. Deploy immediately after review

   a. Finally, your work is done and merged into the master branch. This means that even if you don’t deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don’t want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it’s merged and people also tend to push their own changes.