I published a Git tutorial a long time ago. If you don't know how to use Git, you can find a tutorial collection in the menu at the bottom of the official account, which has an index of Git tutorials.
Today we will not talk about basic usage, but how should Git be used? We know that compared to Svn, the best part of Git lies in its branches. Branches are very flexible, but if there is a lack of a usage routine, it will be messy, especially in team collaboration, how to play Git branches?
We don't invent any wheels, nor do we design any new processes. This article mainly introduces three common workflows: Git Flow, GitHub Flow and GitLab Flow. After the introduction, let's talk about Songge's experience.
1. Git Flow
Let's look at Git Flow first.
Git Flow is the earliest and most widely used workflow.
In Git Flow, there are two long-lived branches that won't be deleted: master and develop .
Among these two branches, master is mainly used to release stable new versions to the outside world. This branch always maintains a state where the software can run normally. Since this state is to be maintained, developers are not allowed to modify the code of the master branch directly. and commits, after the development work of other branches has progressed to the extent that it can be released, it will be merged with the master branch, and this merge will only be carried out at the time of release, and the Git tag of the version number will be attached to the release.
develop is used to store our latest development code. This branch is the code center branch in our development process. This branch does not allow developers to directly modify and submit. Programmers need to create a new feature branch with the develop branch as the starting point, and develop new functions or code revisions in the feature branch, that is to say, the develop branch maintains the latest code in the development process, so that programmers can create feature branches for their own work. .
Note that when developing merge, do not use fast-farward merge. It is recommended to add the --no-ffparameter , so that there will be merge records on the master. Regarding the difference between the two, you can parameter Song Ge's previous Git tutorial, which will not be repeated here.
In addition to these two permanent branches, there are also three temporary branches: feature branches, hotfixes, and release branches. Let's look separately:
feature branches
This is a feature branch, also called a feature branch. When you need to develop a new feature, you can create a new feature-xxx branch and develop new features in it. This is also the base of our daily work. Merged into the develop branch, as shown below:
hotfixes branches
The name of this branch is used to fix bugs. When our project goes online and finds that there are bugs that need to be fixed, we will pull a branch named fixbug-xxx from the Master, and then fix the bugs. The code is merged into the Master and Develop branches, and then the hotfix branch is deleted, as shown below:
release branches
This is the branch that was pulled when the version was released. When all our functions are completed and we are ready to merge the code into the master, we will pull a release-xxx branch from the develop. This branch generally handles some submissions before the release. And the repair of small bugs after the customer experience (the bugs can also be merged into develop after the bug is fixed), do not develop functions in this, after the pre-release, merge the branch into develop and master, and then delete the release, as shown below :
That's probably what it means.
What Song Ge uses in his work is actually a workflow similar to Git Flow. Why is it similar? Our project mainly guarantees the three branches of master, develop and release. On this basis, the others are optional.
2. GitHub Flow
GitHub Flow is much easier than Git Flow. GitHub Flow is also the workflow used on GitHub. If you want to participate in an open source project on GitHub, you may wish to take a look at GitHub Flow.
The official GitHub Flow process is as follows:
Its process is as follows:
- When you need to develop new features or fix bugs, pull a new branch from master.
- After the development of the new branch is completed, or when you encounter difficulties and cannot continue to develop, you can initiate a pr (Pull Request).
- pr not only submits code, but also allows other colleagues to review your code. In the process, you can continue to submit pr.
- Eventually your pr is accepted and merged into master.
Although the GitHub workflow is very simple to use, his problem is also obvious, that is, there is no solution to the problems in common work scenarios.
3. GitLab Flow
GitLab Flow combines the advantages of Git Flow and GitHub Flow. It does not have so many branches that are easy to confuse newbies like Git Flow, and it can adapt to different development environments.
The biggest principle of GitLab Flow is called upstream first, which is translated as "upstream first" in Chinese: that is, there is only one main branch master, which is the upstream of all other branches. Only the code changes adopted by the upstream branch can be applied to other branches.
For "continuous release" projects, we can create different environment branches in addition to the master branch. For example, the development branch is master, the pre-release branch is pre-production, and the production branch is production.
Here the development branch is the upstream of the pre-release branch, and the pre-release branch is the upstream of the production branch. Changes in the code must be made by 上游development 下游. For example, if there is a bug in the production environment, then a new function branch needs to be created, first merge it into master, confirm that there is no problem, then cherry-pick to pre-production, there is no problem in this step, and then enter production, as shown below:
Only in emergencies, it is allowed to skip upstream and merge directly to the downstream branch.
When there is a stable version that needs to be released, we will pull a new branch from the master. As a branch when the version is released, do not develop new functions on these branches, only when fixing bugs
For "released" projects, the recommended practice is to pull a branch from the master branch for each stable version, such as 2-3-stable, 2-4-stable, and so on.
In the future, the code will only be allowed to merge into these branches if the bug is fixed, and the minor version number should be updated at this time.
4. Summary
Well, these are the three common Git play processes. In fact, we don’t have to be so rigid in our own development. We can combine our own projects. Songge’s project, the three branches of master, develop and release are fixed. These three branches The role of Git Flow is also the same as that of Git Flow introduced earlier. On this basis, there are basically no restrictions on others, and they are relatively free.
References:
- https://www.cnblogs.com/sloong/p/5868292.html
- https://medium.com/@lf2lf2111/%E4%B8%89%E7%A8%AE%E7%89%88%E6%8E%A7%E6%B5%81%E7%A8%8B-29c82f5d4469
- https://cloud.tencent.com/developer/article/1646937