The biggest difference between using Git, and other version control systems, is that Git is a distributed system, and in each copy of the repository, there is a full amount of code, so conflicts are common in collaboration. Let’s look at three Git development models.
git flow
git flow is part of the first generation of the git development process. It is divided into two branches, develop
and master
, where all development is branched on develop
and then periodically merged into master
. The master
represents the production ready
code. The main problem with this model is that the code needs to be constantly merged from the develop
branch to master
, so it is easy to miss.
- checkout from
develop
when new features need to be developed, merge back todevelop
when development is complete - When a release is needed, checkout from
develop
and merge therelease-*
branch back to thedevelop
andmaster
branches respectively when the feature is stable. - When hotfix is needed, checkout from
master
. When the fix is complete, merge thehotfix-*
branch back to thedevelop
andmaster
branches.
github flow
Github proposes the github flow, which simplifies the above situation. When you need to do anything, you checkout from master
, do development, then commit PR, and finally merge it into master
for release.
This model is particularly suitable for continuous deployment, because we assume that master
is always the latest production ready
code.
gitlab flow
Gitlab proposes their own flow. gitlab proposes two models.
Continuous Delivery Model
We branch by environment. For example, we usually have three environments: a development environment, a staging environment, and a prod environment.
When the code is ready, we checkout from master
, deploy to staging
, and when a hotfix is needed, we fix it in master
and then cherry-pick
it to the corresponding branch. When we release, we tag the corresponding commits.
Version release model
For example, for iOS applications, we usually have to do release operations, so the process suggests that when we want to do a release, we checkout from msater
and cherry-pick
to the corresponding release branch when there is a hotfix.
squash
As mentioned above, we often need to pick or revert, and both of these operations can only operate on one commit at a time, and in PR we usually have more than one commit. I suggest turning on the squash merge
option in Github, which will merge multiple commits in PR into one, so that when we need to do cherry-pick
or revert
, the operation will be very convenient.
Summary
In this article we introduced three git workflows, looked at how they each work, and finally we introduced squash so we can do cherry-pick
and revert
more easily.