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

问题描述

愚蠢的问题，把我当作完全是版本控制的新手.

我是 Git 新手(我以前使用过 subversion，但只是基础知识)我了解 Git 及其分支命令的基础知识，我有一个想象的情况需要你的建议.

假设我的软件目前是 v1.2，稳定且已发布.

<上一页>我的软件v1.0v1.1v1.1.1v1.2 <- 当前、可编译和已发布

场景:

我有两个开发人员，John 和 Eric.

• John 负责修复客户报告的错误.
• Eric 负责新功能的开发、试验和解决问题.

现在是一月.

John 正在基于 v1.2 版本修复大量错误.每天他都需要将代码提交回存储库 (GitHub)，根据他的状态，软件可能无法编译.

Eric 正在试验这个新的 wiki 功能，从添加 WYSIWYG 编辑器等基本功能到差异/版本控制等高级功能，再次，他需要将代码提交回存储库，软件可能无法编译，具体取决于他所在的位置在.

目标

1. 在任何时候，我都可以推出稳定、可编译的 v1.2 版本
2. 2 月，我希望推出 v1.3，其中包含 John 的所有错误修复，并且取决于 Eric 是否完成(至少完成了基本功能)，同时发布它.

对于 GIT，工作流程是什么?

如果我对 GIT 的理解正确，Eric 和 John 都应该创建自己的分支，并在 2 月让他们合并与 master 合作的分支?

谢谢

解决方案

我会在主存储库中设置两个集成分支:

1. master:新功能的集成分支(由 Eric 维护)
2. 1.2-stable:错误修复的集成分支(由 John 维护)

请注意，这些分支只能用于集成目的，即用于合并来自其他所谓的功能分支的已完成工作.开发和错误修复应该在功能分支中完成.在此工作流程中，集成分支中的代码始终有效.

两位开发人员都应该为他们尝试完成的每项任务拥有一个功能分支.在您的情况下，Eric 将有一个名为 wysiwyg 的分支，该分支从 master 分支的顶端开始.当功能准备好进入开发主线时，Eric 可以简单地将所见即所得的分支合并到 master 中.

这同样适用于约翰.例如，如果 John 必须修复两个问题(例如 issue1 和 issue2)，他应该有分支 fix-issue1 和 fix-issue2.这些分支应该从 1.2-stable 分支的尖端开始.在修复其中一个问题后，比如 issue1，John 可以将分支 fix-issue1 合并回 1.2-stable.如果 master 和 1.2-stable 分支中的代码没有太大差异，那么 Eric 偶尔将分支 1.2-stable 合并到 master 中可能是个好主意，以便将累积的修复合并到产品的下一个版本中.

当发布 1.3 时，Eric 应该确保 1.2-stable 分支和准备好的功能分支中的累积修复都已合并到 master 中.然后他可以简单地标记 v1.3 并创建一个新的分支 1.3-stable.

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

1. At any time, I can pull out a stable, compilable v1.2 release
2. 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:

1. master: integration branch for new features (maintained by Eric)
2. 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屋！