这种场景下该采用怎么样的git分支管理策略？

Question

目前开发的项目采用git作为版本管理工具，

平时开发有两个分支，develop和master

在develop上开发，

在master发布正式版本。

目前有这样一种情况：

有一个设计好的功能，由于种种原因，在develop分支上开发完成后不能正常使用，

需要使用另一个补救性的设计方案临时代替，此代替方案需要上线，发布到master里面

当原功能成熟后，再删除这个补救方法，切换回原有的功能

请问我该使用哪种git分支策略？

Answer 1

Recommend the merge request method in Gitlab flow
The master and develop branches are not allowed to be pushed directly
master = production
develop = next release
When there are new requirements, create a requirement branch feature/aaa
Create a merge request after development is completed
Merge feature/aaa 到 develop branch after code review
Merged when online develop 分支到 master
Release master branch

For the poster’s problem, you can do this
Create a new branch feature/bbb based on feature/aaa. After completing the remediation work, merge it into develop, feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, master and then go online
Continue the development of feature/aaa and finally merge it into develop, feature/aaa 的开发工作，最后合并到 develop, master

Answer 2

You can refer to git workflow

roughly branches from master分支checkout一个hotfixes分支。在hotfixes把补救的写好，然后分别merge到master和develop。此时就可以删除这个hotfixes.

Then go online from develop分支开发完善你的功能，最后把develop分支merge到master.

Maybe there is a better way, just for reference

Answer 3

develop（未开发新功能）-> develop（已开发新功能，新功能不可用）-> develop（继续完善到可用）
                 └───> fix（补救）                                 ╲
                           └───> master（记得在~1版本打 tag 哦）      ╲ merge
           master（tag）<────────────────────────────┘               ↘
                 └───────────────────────────────────────────────> master

Answer 4

Please help the poster solve this problem first.

The poster’s branch strategy does not require special processing. It can be handled very well according to the normal process and combined with the functions of git:

• First, continue to submit remedial code after the commit completed on develop to ensure that the features of develop can be released and used normally. The "remedial solution" mentioned by the poster here is actually part of feature development and is not considered a bugfix.
• After that, you can enter the release process after the test passes. If the original branch strategy of the original poster includes a release branch, you can create a release branch after the previous step, and develop will continue to accept new feature submissions. The design plan and temporary remedies this time will receive bugfixes in the release.
• The above is actually a normal development and release process. What about subsequent design development and deletion of remedial functions? In fact, subsequent development can actually be regarded as improvements or new features, just normal development. You can revert the original remediation commit (git revert command) at any node during this improvement process as needed.
• revert After the remediation and "original design" are implemented, it can be released according to the normal release process.

According to my understanding, the "original functions" and "remedial solutions" mentioned by the poster are normal code submissions. What the poster is confused about is how to deal with the problem that the temporary remedy solution will eventually be discarded (rolled back), so using the git revert command mentioned above should satisfy the poster's expectations. This not only ensures that all operations on the code base can be recorded in the trunk (master, develop), but also avoids problems such as complex branch models.

---

Also, I don’t know if the branching strategy used by the poster follows the workflow mentioned by @rsj217. If develop is the main development branch for all developers, I think it is better for develop to submit unfinished features directly without accepting them. In daily development work, especially in the case of parallel development of multiple features/branches, multiple feature branches can avoid interference with each other.
Back to the original poster's question, this unusable design can continue to be developed and should not be merged into develop. Based on this branch, checkout a development branch for remedial features. After testing is completed, merge it into develop to enter the release process. The following merge and revert suggestions are still necessary. Do not violate the process and do special processing unless you have to, and this will retain all code commit operations.

Answer 5

It is recommended to refer to the git workflow master master branch develop is used for development release is used to release new versions hotfix is ​​used to fix online bugs and other emergency operations

Answer 6

Let’s say your remedy branch is develop1. After going online, develop1 and master will be merged together to become a new master. After the original functional branch develop is mature and stable, merge it into a new master (it is very likely to conflict), and merge develop1’s branch into a new master. Delete that part and the test will go online without any problem. It's a bit troublesome, and maybe a little stupid, but every time git merges, a new point is generated forward. If you want to wait for the development to stabilize and roll back the master, if there are other releases in the middle, will you lose something soon?
Maybe there is a better way, just for reference

Answer 7

If you have difficulty reading A successful Git branching model, you can read Juven Xu’s translation of A successful Git branching model

Answer 8

Using git-flow will help you. You can use simple commands to help you create and complete branches. And there are standardized release, hotfix, and feature workflows