问题描述
我是Git新手，正在寻找您的建议.
I'm rather a Git newbie and I'm looking for your advice.
在我为之工作的公司中，我们有一个工作流程"，其中我们的项目有一个单独的Git存储库，其中有两个分支:master和prod.所有开发人员都在master分支上工作.如果完成了票证(从开发人员的角度来看)，我们将推送至回购协议.如果所有测试都通过，我们将发布.
In the company I work for we have a "workflow" where we have a single Git repo for our project with 2 branches: master and prod. All devs work on the master branch. If a ticket is done (from the dev perspective), we push to the repo. If all tests are passed, we make a release.
问题在于，在大多数情况下，业务人员发出的请求听起来像是:请释放票证A或A&& B".
The issue is that in most cases, the request from business guys sounds like: "please release ticket A or A && B".
在大多数情况下，我最终都会做类似的事情
In most cases, I end up doing something like
git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a
如您所见，这不是一个完美的解决方案，而且我印象深刻，这是解决问题的完美方法，尤其是当变更A取决于变更B和C时.
As you can see this is not a perfect solution, and I'm under a huge impression this is a perfect way to nowhere especially when change A depends on changes B and C.
如果有更多开发人员在同一个分支上工作，并且流程类似于我上面所述，您有任何建议如何处理按需发布?欢迎提出所有建议.
Do you have any suggestions how to handle releases on demand if more devs works on the same branch and the flow looks like I described above? All suggestions are welcome.
不幸的是，我无法更改业务流程，它必须保持原样.
I cannot change business processes and it will have to stay as it is - unfortunately.
推荐答案
我们使用了像您这样的工作流程两年，最近又放弃了它.我们发现了四个问题，随着使用时间的延长，每个问题都会被夸大.这是一个惊人的时间浪费，需要我们(虽然很小)的发布人员进行几乎全时的工作才能进行管理.如果您还没有，这就是几个月后要达到的目标:
We used a workflow like yours for two years and recently abandoned it. We found four problems with it, each of which becomes exaggerated the longer you use the workflow. It was a staggering waste of time, requiring nearly full time effort by our (admittedly small) release staff to manage. Here's what you're going to hit in a few months, if you haven't already:
-
您的
master和prod分支不共享提交历史记录，这意味着它们不能轻松地彼此合并.这在您的工作流程版本中尤其明显，因为您正在选择--no-commit标志，然后重新提交文件.从某种意义上讲，您是在同一组代码上维护两个不同的git存储库.听起来很容易，直到您点击...
Your
masterandprodbranches don't share commit history, meaning they can't be easily merged into one another. This would be especially evident in your version of this workflow, as you're cherry-picking with the--no-commitflag, and then recommitting the files. You are, in a sense, maintaining two distinct git repositories over the same set of code. This sounds manageable until you hit...
由于master和prod具有不同的历史记录，但是prod是master更改的子集，因此分支会随着时间而变化.有时，新功能会被废弃.有时，业务人员会更改优先级.有时，一个主意似乎很棒，直到您完成40次提交并意识到它会破坏一切.将在master分支中引入无法在prod上再现的错误，并且其中一些错误将是根本看不到prod的代码工件.没有持续的维护，master的完整性会下降.这很烦人，令人沮丧，并且阻碍了实际工作的完成.更糟糕的是...
Because master and prod have different histories, but prod is a subset of master's changes, your branches will diverge over time. Sometimes new features get scrapped. Sometimes the business guys will change the priorities. Sometimes an idea seems great until you get 40 commits in and realize it breaks everything. Bugs will be introduced in the master branch that aren't reproducible on prod, and some of them will be artifacts of code that never sees prod at all. Without constant upkeep, master's integrity degrades. It's annoying, frustrating, and prevents real work from getting done. Even worse...
您最终将解决prod中不存在的master中的合并冲突.当您选择这些提交到prod时，您很少有机会在选择樱桃的过程中引入错误.您的master代码几乎是您的prod代码 ，但是微小的差异可能会导致意外的后果.如果您的开发人员对空格不特别小心，或者不喜欢实验"，那么问题就会被夸大.如果Genius Developer Susie(确实很聪明，但倾向于将旧文件重构为更易读)检查了一堆空白更改以及一两个合法的代码修正，您将把生产分支置于一个奇怪的灰色在master之前的状态和之前的状态之间建立状态.
You'll end up fixing merge conflicts in master that don't exist in prod. When you cherry-pick these commits over to prod, you stand a small chance of introducing bugs during the cherry-picking process. Your master code is almost your prod code, but the small differences could create Unintended Consequences. The problem is exaggerated if your developers aren't particularly careful about whitespace or like to 'experiment'. If Genius Developer Susie (who really is quite bright but tends to refactor legacy files to be more readable) checks in a bunch of whitespace changes along with a legitimate code fix or two, you're going to put your production branch in a weird gray state between what it was before and what it is on master.
最后，如果将-1-，-2-和-3-组合在一起，则会遇到我们遇到的最严重的问题:编写，测试和发布紧急修复程序和功能很困难.遇到危机时，您刚刚在应用程序中引入了安全漏洞； bizdev刚刚为一个中型国家的GDP签署了MoneyBags McEnterprise，而他们所需要的只是COB的一套全新工具-您需要修复prod，因为这是必须的，但您不能这样做.不容易.您的所有开发人员都在本地运行master.他们可以通过切换分支来运行prod，但是您的测试框架已硬连接到master的代码，并且将阻塞prod的所有新部分.没关系，您可以将其写在prod上，然后将其重新拾取回master，对吗?嗯并非没有碰到合并冲突和分歧文件.如何将功能分支到prod并将其完全合并到master中呢?哦，是的，他们不共享历史记录...
Finally, if you combine -1-, -2-, and -3-, you hit the worst problem we encountered: It's difficult to compose, test, and release emergency fixes and features. When it's a crisis -- you just introduced a security hole in your application; bizdev just signed MoneyBags McEnterprise for the GDP of a mid-sized nation and all they need is a brand new suite of tools by COB -- you need to fix prod because that's what has to work, but you can't. Not easily. All your devs are running master locally. They can run prod by switching branches, but your test framework is hardwired to master's code and it's going to choke all over the new parts of prod. That's okay, you can just write it on prod and cherry-pick it back over to master, right? Hmmmm. Not without hitting merge conflicts and divergent files. How about feature branching prod and just outright merging it into master? Oh yeah, they don't share history...
我们可能对这些问题没有足够认真的考虑.我向您保证，有人在进行提交和历史记录方面要非常谨慎，以使这项工作有效，您可能会在其他答案中听到他们的意见.一样，此工作流在我们使用的两个yeras上浪费了很多时间.我们围绕一些关键思想重新设计了工作流程:
It's possible we simply didn't think hard enough about these problems. Someone out there, I promise you, is careful enough about commits and history to make this work, and you might hear from them in other answers. All the same, this workflow wasted buckets of time over the two yeras we used it. We reformulated our workflow around a few key ideas:
首先，git中的分支既便宜又简单，因此我们将其用于每种功能或情况.我们开发了一种命名方案，开发人员可以将特定案例的分支(由我们的问题跟踪系统提供的案例编号)推送到一个可共享的位置.我们使用 gitorious 为每个开发人员提供一个个人的远程存储库，但是没有理由您不能将它们推向市场"功能和案例共享到origin.它需要一些组织和跟踪，但要比上述问题所需的跟踪和跟踪少得多.
First, branches in git are cheap and easy, so we use them for every feature or case. We developed a naming scheme whereby developers push case-specific branches (case numbers provided by our issue tracking system) to a sharable place. We use gitorious to give each developer a personal remote repository, but there's no reason you couldn't push these "in flight" features and cases to a shared origin. It requires some organization and tracking, but much less then that required by the problems described above.
第二，这些功能分支应被切断production，而不是master.除非某个功能或修补程序依赖于另一个正在运行的变更集，否则它应基于显示问题或需要该功能的最上游分支.对于我们来说，始终是production.
Second, these feature branches should be cut off production, not master. Unless a feature or fix depends on another change set that is "in flight", it should be based on the most upstream branch that shows the problem or requires the feature. For us, that's always production.
第三，master或我们所谓的主要开发集成分支，仅仅是在生产之上合并的运行中"功能分支的集合.它用于进行集成测试并更早地识别特征分支之间的合并冲突和依赖性.它不是我们新代码所基于的东西.我们会在每个发行版中对其进行重置，并自动跟踪和合并飞行中的主题".我们还将为质量检查部门维护一个单独的next分支，该分支将停止生产，并且仅包含在下一版本中将要推出的功能分支.
Third, master, or whatever we're calling our main development integration branch, is simply a collection of "in flight" feature branches merged on top of production. It exists for integration testing and to identify merge conflicts and dependencies between feature branches earlier. It is not something upon which we base new code. We reset it with every release, and automated the tracking and merging of "in flight topics". We also maintain a separate next branch for the QA department, which is cut off production and contains only those feature branches that are going out in the next release.
这是我们根据 git项目本身.它是分布式的，对我们来说是一个巨大的范式转变.它可能对您有用，但如果不行，我仍然建议您寻求其他工作流程.您当前的版本会随着时间的流逝而退化，以至于您最终可能会花很多时间来破坏版本控制.
It's a workflow we adapted from the git project itself. It's distributed and quite a paradigm shift for us. It might work for you, but if it doesn't, I would still recommend seeking another workflow. Your current one will degrade over time, to the point where you could end up fighting the version control as much as you fight the code.
这篇关于最佳(您认为)GIT工作流，用于按需发布的情况(大多数情况下，一次发送1-2张票)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！