A tale of two git workflows

By Greg Turnquist

Greg is a member of the Spring team, an author of several books on Spring Boot, conference speaker, and the lead for Spring Data JPA.

git

January 16, 2014

My company has gone full on with using github as the place to host our code. It’s great! I love git and I love github. And lately, in the past couple of months, I have taken on using hub, and git + hub tool.

So what’s the difference in workflow? The standard approach suggested by github is fork-a-repo. In a nutshell, you fork the repo, clone it to your box, and add a remote to the “official” project named “upstream”. The problem I ran into all the time that was annoying was that I had to keep updating my own master branch to keep it in sync with the official project. Sometimes I would accidentally forget that my own master branch wasn’t up-to-date and have to back up to do that extra bookkeeping.

But then came hub. That tool has a different workflow that is superb. You create a fork of the official project, but that is not the one you clone to your work machine. Instead, you clone the official project and then add a remote to your own fork. Create a new branch, push it to your fork, and submit a pull request back to the official repo.

By taking away the need to sync my own repo, it has lifted this burden of remembering that step. Instead, I simply perform periodic “git pull”s against the official repo, and things stay up-to-date.

The tradeoff? Visit my own fork, and you won’t see an up-to-date master branch there. But so what? I don’t build anything against my own master branch. Instead, I’m more interesting in all the contributions going into the official master branch.

The confusion? Why does github (the producer of both of these workflows) suggest two flows? It’s confusing. I have already run into a co-worker that uses the classic one vs. hub’s. I had to chat him through an issue when it was time to deploy and I didn’t have the proper commit rights.

NOTE: It has come to my attention that “git pull-request” has been deprecated. That is simply because github might be deprecating the ability to convert issues into pull requests. But after I found the issue on the repo, it turns out that if github indeed removes that feature, hub will simply replace it with another command to issue a new pull request from the command line.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *