Git工作流程：重新发布已发布/共享分支 [英] Git Workflows: Rebasing Published/Shared Branches

问题描述

我们的团队热心地采用了rebase工作流程，但我们可能会有点失望，这就是这个问题的关键：您是法官。

<现在，使用pull --rebase对我来说是不容易的。但是，我们也有大量的功能分支可供多人使用。定期地，我们想要引入主人正在发生的变化。传统的智慧会让我们合并，因为它是一个共享的分支。然而，在我们的基调上，我们决定重新设计这些分支机构。当然这需要大家的合作。工作流程如下所示：

1）rebaser与每个人协调以确保他们全部签入并推送到功能分支，然后要求他们2）rebaser将特性分支重定位到master，删除远程特性分支（git push origin：功能），然后推送新的，重新发布的功能分支（git push origin feature）

3）rebaser让每个人都抓取，更新他们的功能分支，然后删除他们局部特征分支（git分支-D特征），然后创建一个新的局部特征分支来跟踪远程特征分支。然后每个人都得到全部清除。

这个工作流程正在工作，部分原因是我们是一个小团队，而且工作中断很小。但是，我担心我们正在学习可怜的Git习惯（重新分配一个共享分支），或者工作流程不能很好地扩展。

另一方面，我们的仓库历史很可爱。

你认为Git的大师是什么？我们是在玩火，还是摇摆合理的工作流？
$ b 更新：

自从我最初提出这个问题已经两年了，从那时起我的工作流程就发生了变化。我们仍然经常做 git pull --rebase ，所以没有改变。这是常识，它可以防止所有不美观，迷惑的迷你合并。 （我们保持大部分时间同步，所以几乎没有任何成本， git pull --rebase ）。

除此之外然而，偶尔英勇的纠正错误的行动，我们已经结束了我们的蜕变疯狂。大部分时间合并都很有意义。然而，肆意合并是有问题的，并且对两年前我所关心的混淆，混乱的历史有所贡献。

我们的解决方案有几个组件：

• 主分支是pristine。主题分支被合并，完成后，主题分支将被撤销。换句话说，合并主题分支意味着该工作已准备好进行生产，现在已成为主分支的一部分。看看我们的版本历史记录，这很清楚发生了什么事情：主题分支合并到master中，就是这样。




• 我们在必要时使用一次性集成分支。例如，如果我们有主题分支A，B和C，并且它们都不准备集成到主控中，但我们需要一起测试它们，我们只创建一个QA分支（通常是主分支），然后合并A，B和C英寸。在某些时候，QA分支被删除或重新使用。重点是它并不打算以任何方式永久存在，并且它没有与主分支相同的限制（您可以根据需要多次合并主题分支）。如果历史记录过于混乱，您可以删除QA分支并重新开始（我们发现这种方法非常自然）。




• 合并时， 总是使用 git merge --no-ff 。这与我们两年前对线性提交历史的迷恋产生了巨大的逆转，值得评论。既然我们已经放松了一个线性提交历史记录，并且看到合并是好的和有用的，我们已经开始关注主要分支是实际分支关闭主控，而不仅仅是一系列最终成为主人的提交。 git merge --no-ff 确保始终存在合并提交，即使没有必要也是如此。

>对于提交消息和分支我们有一个很好理解的约定，更重要的是，它交叉引用了我们的问题跟踪系统。我们的问题跟踪系统使用数字问题编号，对于任何功能（或缺陷），我们都有一个问题编号（例如1234）。如果你正在处理这个问题，你可以创建一个分支 _1234 ，并开始每个提交消息，并且使用_ 1234：doing blah blah。它看起来有点过于执着，但它确实对我们有用，并且显着减少/消除了混淆。 使用git包装来鼓励工作流程粘连。这是我们目前正在开展的工作，但我们意识到完全有必要防止简单易懂的错误，比如分离错误的东西（当开发者创建了一次性主题分支时，我们最近发生了一场完全灾难QA分支：该主题分支被批准投入使用，它被合并到...以及未被批准上线的一批换入者被吸入）。我们的git包装器需要确认，只要你做一些不寻常的事情（比如创建一个除了master以外的分支，创建一个不叫_NNNN的分支，做一个不以_NNNN开头的提交等等）。有时候，我们确实需要做这些事情，所以包装并不会阻止它，但它确实会让人们不小心做不该做的事。

解决方案

这听起来像过于复杂，并且不能很好地扩展。如果将 master 定期合并到你的特性分支中，然后当它合并回到master时，那么然后可以首先执行rebase（移除不必要的中间合并）并将其合并回master（大概用 - no-ff 来产生合并提交）。这只需要一个人处理rebase，而且他们不需要进行任何协调，因为没有人需要强制更新任何东西（因为大概在分支被合并后将被删除，而不是保留在重写状态）。您也可以决定完全跳过rebase，只保留中间合并，这样可以更准确地反映您的开发工作流程，并消除产生实际未建立的提交的风险。

Our team at work has enthusiastically adopted a rebase workflow, but we might have gotten a little carried away, which is the point of this question: you be the judge.

Using pull --rebase is a no-brainer to me now. However, we also have large feature branches that multiple people work on. Periodically, we want to bring in changes that are happening on master. Conventional wisdom would have us merge since it's a shared branch. However, in our rebase-obsession, we've decided to rebase those branches. Of course that requires everyone's cooperation. The workflow goes something like this:

1) The rebaser coordinates with everyone to make sure they're all checked-in and pushed on the feature branch, then asks them to do no more work on that branch until they get the all clear.

2) The rebaser rebases the feature branch onto master, deletes the remote feature branch (git push origin :feature), and then pushes the new, rebased feature branch (git push origin feature)

3) The rebaser has everyone fetch, which updates their feature branch, then delete their local feature branch (git branch -D feature), then create a new local feature branch that tracks the remote feature branch. Everyone then gets the all-clear.

This workflow is working, partially because we're a small group, and the work interruptions are small. However, I worry that we're learning poor Git habits (rebasing a shared branch), or that the workflow won't scale well.

On the upside, our repository history is lovely.

What do you think, Git gurus? Are we playing with fire, or rocking a reasonable workflow?

UPDATE:

It's two years since I originally asked the question, and my has our workflow changed since then. We still routinely do git pull --rebase, so that hasn't changed. It's common sense, and it prevents all the unsightly, confusing mini-merges. (We keep mostly in sync, so there's little cost to git pull --rebase).

Other than that, however, and the occasional heroic action to correct a mistake, we are over our rebase madness. Merging makes sense most of the time. However, wanton merging is problematic, and does contribute to the confusing, chaotic history I was concerned about two years ago.

Our solution has several components:

• The master branch is "pristine". Topic branches get merged in, and once they do, the topic branch is retired. In other words, merging a topic branch in signifies that that work is ready for production, and is now part of the master branch. Looking at our version history, it's very clear what's happening: topic branches getting merged into master, and that's that.

• We use disposable integration branches when necessary. For example, if we have topic branches A, B, and C, and none of them are ready for integration into master, but we need to test them together, we just create a QA branch (usually off of master), and then merge A, B, and C in. At some point, the QA branch is deleted or re-used. The point is that it's not intended to be permanent in any way, and it doesn't have the same restrictions as the master branch (you can merge in your topic branches as many times as you want). If the history gets too confusing, you can just delete the QA branch and start fresh (an approach we have found to be very natural).

• When merging, always use git merge --no-ff. This is such a tremendous reversal from our "linear commit history" obsession from two years ago that it deserves comment. Now that we've relaxed about a linear commit history, and seen that merges are good and useful, we've started to rely on topic branches being actual branches off of master, not just a series of commits that eventually becomes one with master. git merge --no-ff ensures there's always a merge commit, even when it's not necessary.

• We have a well-understood convention for commit messages and branches and, more importantly, it cross-references our issue-tracking system. Our issue tracking system uses numeric issue numbers, and for any feature (or defect), we have an issue number (1234, for example). If you're working on that issue, you would create a branch _1234 and start every commit message with "_1234: doing blah blah". It may seem a little obsessive, but it has really worked well for us, and significantly reduced/eliminated confusion.

• Use a git wrapper to encourage workflow adhesion. This is something we're currently working on, but we've realized is entirely necessary to prevent simple and understandable mistakes, like branching off of the wrong thing (we recently had a complete disaster when a developer created a topic branch off of a disposable QA branch: that topic branch was approved to go live, it was merged in...and a bunch of changers that weren't approved to go live were sucked in). Our git wrapper will require confirmation whenever you do something unusual (like creating a branch off of anything but master, creating a branch not named _NNNN, making a commit that doesn't start with _NNNN, etc.). Occasionally, we do need to do these things, so the wrapper doesn't prevent it, but it does keep people from accidentally doing something they shouldn't.

解决方案

This sounds like it's overly complicated and won't scale well. It's probably a heck of a lot simpler just to merge master into your feature branch periodically, and then when it comes time to merge back into master, then you can do the rebase first (to remove the intermediate unnecessary merge) and merge back into master (presumably with --no-ff to produce a merge commit). This only requires one person deal with the rebase, and they don't have to do any coordination because nobody else needs to force-update anything (because, presumably, the branch is going to be deleted after it's merged, rather than kept around in a rewritten state). You may also decide to skip the rebase entirely and just leave the intermediate merges in place, which would more accurately reflect your development workflow and remove the risk of producing commits that don't actually build.

这篇关于Git工作流程：重新发布已发布/共享分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！