如何安排从master分支到我的Feature分支的合并，并在我的Feature分支上提交自己的工作? [英] How shall I arrange merge from the master branch into my feature branch and commit of my own work on my feature branch?

问题描述

当尝试使功能分支与master分支保持最新时，我不得不不时将master分支合并到我的Feature分支中.

When trying to keep my feature branch up to date with the master branch, I have to merge the master branch to my feature branch from time to time.

如果这样的合并成功，是否会在功能分支上创建新的提交，是否正确?

Is it correct that if such a merge succeeds, it will create a new commit on the feature branch?

如果这样的合并失败，我将必须手动解决合并冲突.在这种情况下，进行包含这两者的提交是个好主意吗?

If such a merge fails, I will have to manually resolve the merge conflict. In such a case, is it a good idea to make a commit which includes both

• 我为解决合并冲突所做的更改
• 以及我在功能分支上所做的一些工作?

还是应该将为解决合并冲突而进行的更改与功能分支上的工作分开进行不同的提交? 以后在

Or shall I make separate the changes I make for resolving a merge conflict and the work on the feature branch into different commits? Does it make a difference for later on

• 当我创建将功能分支合并到master分支的拉取请求时，其他人的代码回顾了我在功能分支上的工作
• 我自我提醒自己在功能分支上的工作
• 我想念的其他事情?

通常，我应该如何安排从master分支到我的功能分支的合并，并在我的功能分支上提交自己的工作?

Generally, how shall I arrange merge from the master branch into my feature branch and commit of my own work on my feature branch?

推荐答案

从master到功​​能分支的合并通常会通常生成新的提交以用于合并.您可以为该规则设计一个例外，但是或多或少仅在feature分支尚未进行任何提交的情况下.如果要完全确定创建提交，可以将其与no-ff选项合并.

It is true that a merge from master to a feature branch will usually produce a new commit for the merge. You could contrive an exception to this rule, but more or less only if the feature branch doesn't have any commits on it yet. If you want to make absolutely sure a commit is created, you could merge with the no-ff option.

我的建议是将尽可能少的更改放入合并提交中.有几个相关的原因.

My advice is to put as few changes as possible into merge commits. There are a few related reasons.

首先，合并应该代表两条工作线的融合.合并提交消息通常类似于将主数据库合并到some_feature中"；如果您要做其他工作，则需要提交消息，其中列出了您所做的不相关的事情，并且有可能(甚至有可能)在以后有人寻找您的更改时会丢失此类消息.

First, the merge is supposed to represent the confluence of two lines of work. The merge commit message is usually something like "merged master into some_feature"; if you do additional work you'll need a commit message that lists the unrelated things you did, and it's possible - maybe even likely - that such messages will be missed when someone's looking for your change later.

因此，合并提交的默认日志输出不包含补丁.您可以得到一个，但它是3(或更多)方式的补丁，很难阅读.因此，如果您希望能够轻松检查您的更改，请不要将其添加到合并中.

For that matter, default log output for a merge commit doesn't include a patch. You can get one, but it's a 3-(or-more)-way patch which is much harder to read. So if you want to be able to easily examine your changes, don't tack them on to a merge.

下一步:在路上，您可能会想知道哪些更改引入了错误.通常，过于复杂的提交会执行过多的操作，这会降低帮助您缩小范围的工具的有效性(例如bisect). 从大师那里合并使我的功能分支中断"的解决方案可能与我添加到我的功能中的最新作品使我的功能分支中断"的解决方案大不相同.

Next: Down the road you might care to know what change introduced a bug. In general having overly-complex commits that do too many things will reduce the effectiveness of tools that help you narrow this down (like bisect). And "merging from master broke my feature branch" likely has a very different resolution than "the latest work I added to my feature broke my feature branch".

在某些情况下，git类还假设合并只是一个合并.我主要考虑的是重新设置操作，并且很少或永远不会出现通过像这样的合并来重新设置操作的想法.但是，如果您这样做了，并且合并中包含不相关的更改，那么您将遇到不必要的问题.

There also are situations in which git kind of assumes that a merge is just a merge. I'm thinking mostly of rebase operations, and it may rarely or never come up that you would rebase through a merge like this. But if you do, and if the merge contains unrelated changes, you'll have unnecessary problems.

偶尔也需要手动重做"合并；再说一次，如果您在合并中包含无关的工作，这将更加困难.

It also happens occasionally that you have to manually "redo" a merge; and again, this is harder if you included unrelated work in the merge.

这篇关于如何安排从master分支到我的Feature分支的合并，并在我的Feature分支上提交自己的工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！