A progressive git workflow

When you are new to Git, you may be presented with the dizzy branching workflow of Git, which is often a picture of Figure 1. In this article, I will interchangeably use the term git flow, git workflow, and git branching model.

In my opinion, this branching model is way too complicated for a Git newbie. In this article, I’m going to present a progressive git workflow that fits from a repo of a solo developer, to a repo with a couple of developers and many pull requests, to a repo of a really commercial product.

dev and master

The simplest git flow is only one branch, master. Every repository starts with this form. The initial tens of commits are quite often directly committed to master. It’s not advised to rebase master even if you are the only contributor of the repository. Everyone can clone and fork the repo and rebasing disrupts all clones except yours. In my practice, I rebase commits in master if they are committed or pushed within a few hours.

The dev branch appears when you are not confident of some commits. This dev branch may show up unconsciously. For instance, you were trying to experiment something and created a branch; you commit more and more changes to the branch and you never find a chance to merge it to master. The branch ends up with having a dozen or two dozen commits of different topics or miscellaneous changes. At this time, this branch becomes the de facto dev branch.

dev is safe to rebase. When you are confident with a commit in dev, you can rebase/re-order this commit to be the first commit in dev so that master can advance one commit.

dev, master, and pull requests

Pull requests can only be created when you have a dev branch or something other than master. Let’s say you create PR from dev. In dev you would have a couple of commits of the same topic. Either you already have continuous integration in mind (you want to use GitHub Actions) or you want to add these commits as a single unit to master and keep the history of these single commits (not squashing them up).

dev, master, pull requests, and staging

Pull requests must be vetted before merged and thus takes time. Sometimes I wrote up code and I got up the next day and read the code, and found something unearthly. But self-review is not really code review.

参考资料

1. Vincent Driessen. A successful Git branching model. . 2010-01-05 [2021-06-13].↑