Git工作流最佳实践 [英] Git Workflow Best practices

问题描述

愚蠢的问题和对待我完全是版本控制的新手。

我是Git的新手（我之前使用过Subversion，但只是基础知识）我理解Git及其分支命令的基础知识，我有一个想象的情况这需要你的建议。

假设我的软件目前处于v1.2，稳定并发布。

 
我的软件
 v1.0 
 v1.1 
 v1.1.1 
 v1.2 < - 当前，可编辑和已发布
 
 
 
 
场景：
 
 
我有两个开发者John和Eric。
 
 
 
 
 John负责客户报告的错误修复。
 
 
 Eric负责新功能，对它们进行实验并找出扭曲。
 
 
 
 
现在是1月份。 
 
 
 
 John正在研究基于v1.2版本的大量错误修复。每天他都需要将代码提交回存储库（GitHub），软件可能无法编译，具体取决于他的状态。 
 
 
 Eric正在尝试使用基本功能（如添加WYSIWYG编辑器）以及差异/版本控制等高级功能来实现这一新的维基功能，同时他还需要将其代码提交回根据他所在的位置，软件库可能无法编译。  
 
 
目标
 
 
 
 
 
在任何时候，我都可以提出一个稳定的，可编译的v1.2发布
 
 
 2月，我希望v1.3能够推出所有John的bug修复程序，并根据Eric是否完成（至少已完成基本功能），释放以及。 
 
 
使用GIT，工作流程是什么？ 
 
 
 
如果我正确理解GIT，那么Eric和John都应该创建自己的分支，并且在2月份，让他们合并与主人合作的东西吗？ b 
 
谢谢 
 
解决方案
我会在主资源库中设置两个集成分支：
 
 $ b 
 
 
 master：新功能的集成分支（由Eric维护）
 
 
 1.2-稳定：修补程序（由John维护）
 
 
请注意，这些分支仅用于集成目的，即用于合并已完成的工作，所谓的功能分支。应该在功能分支中完成开发和错误修复。在此工作流程中，集成分支中的代码始终有效。
 
 
 
这两个开发人员都应该为他们要完成的每项任务设置一个功能分支。在你的情况下，Eric会有一个叫做wysiwyg的分支，它开始于主分支的顶端。当功能准备好进入开发主线时，Eric可以简单地将wysiwyg分支合并到master中。 
 
 
 John也是如此。例如，如果John必须解决两个问题（例如issue1和issue2），他应该有分支fix-issue1和fix-issue2。这些分支应该从1.2稳定分支的末端开始。解决了其中一个问题后，问题1，约翰可以将分支修复问题1合并回1.2稳定。如果主控和1.2稳定分支中的代码没有太多分歧，那么Eric可能偶尔会将分支1.2-stable合并到主控中，以便将累积的修复合并到下一版本的产品中。  
 
 
当发布1.3时，Eric应确保1.2-稳定分支和就绪功能分支中的累积修复已全部合并到主控中。然后他可以简单地标记v1.3并创建一个1.3稳定的新分支。 
Stupid question and treat me as completely a newbie to version control. 

I'm new to Git (I've used subversion before, but just the basics) I understand the basics of Git and its branching commands, I have an imaginary situation that need your advice.

Suppose my software currently is at v1.2, stable and released.
My Software
       v1.0
       v1.1
       v1.1.1
       v1.2 <- Current, Compilable and Released


Scenario:

I have two developers, John and Eric.


John is responsible for bug fixes reported by clients.
Eric is responsible for new features, experiment with them and work out the kinks.


It's January right now.  

John is working on lots of bug fixes based on the v1.2 release. Every day he's required to commit his code back to the repository (GitHub), software might not compile depending on his status.   

Eric is experimenting this new wiki feature from basic features like add a WYSIWYG editor, to advanced features like diffing/version control, again, he's required to commit his code back to the repository, software might not compile either depending on where he's at. 

Goal


At any time, I can pull out a stable, compilable v1.2 release
February, I want v1.3 to be pushed out with all John's bug fixes and depending on if Eric is done (at least have the basic feature done), release that as well. 
With GIT, what is the workflow? 

If I understand GIT correctly, both Eric and John should create their own branch and in Feb, have them merge what works with the master?

Thanks
解决方案
I would set up two integration branches in the main repository:

master: integration branch for new features (maintained by Eric)
1.2-stable: integration branch for bug-fixes (maintained by John)
Please note that these branches should only be used for integration purposes, i.e. for merging finished work from other, so-called feature branches. Development and bug-fixing should be done in the feature branches. In this workflow the code in the integration branches always works.

Both developers should have one feature branch for each task they are trying to accomplish. In your case Eric would have a branch called wysiwyg that starts at the tip of the master branch. When the feature is ready to enter the mainline of development Eric can simply merge the wysiwyg branch into master.

The same applies to John. If, for example, John has to fix two issues (say, issue1 and issue2) he should have branches fix-issue1 and fix-issue2. These branches should start from the tip of the 1.2-stable branch. After fixing one of the problems, say issue1, John can merge branch fix-issue1 back into 1.2-stable. If the codes in master and 1.2-stable branches haven't diverged too much then it would probably be a good idea for Eric to occasionally merge branch 1.2-stable into master in order to incorporate the accumulated fixes to the next release of the product.

When it is time to release 1.3 Eric should make sure that the accumulated fixes in 1.2-stable branch and ready feature branches have all been merged into master. Then he can simply tag v1.3 and create a new branch 1.3-stable.

                        
这篇关于Git工作流最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！