Git中的合并，存储和重新绑定有什么概念上的区别？ [英] What are the conceptual differences between Merging, Stashing and Rebasing in Git?

问题描述

我一直在使用主分支大量合并。但最近对于我的情况下的功能开发来说，合并对于项目历史来说似乎很复杂。我遇到了Rebasing，它解决了我的问题。我还遇到了重新贷款的黄金法则解决问题。

我也曾经使用过Stashing，但它工作起来，但我觉得同样的事情也可以通过合并来实现。

虽然我使用这些命令，但我觉得如果有人能够解释关于这三个命令的概念上突出的事实/规则，这将有助于我更清楚地理解。谢谢。

解决方案

存储是非常不同的，因为它基本上为您的更改留出了更改。如果你处于某种事情的中间，并且你必须跳转到别的东西并切换分支，那么这很有用。

合并和重新分配最终达到同样的效果 - 分成一个分支。

• 重新激活给出了一个可以说是更清晰的历史记录，并且内联解决了冲突。


• 通过合并，冲突在合并提交中解决。


$ b

不同的是解决内联冲突有效地使得冲突从未发生过，因为你再次编辑文件以合并导致冲突的变更。





可以是当您稍后回顾变更时很有用。



正如你所暗示的，重写历史使得与特定分支上的其他人合作变得困难或不可能。





---





当从gitg等工具查看图形或视觉表示时，从长期特征分支进行的一系列合并可能很难遵循。



使用底版，可以更直观地看到更改。当你使用像git-bisect这样的工具来查找错误的原始提交时，它也可以提供帮助，因为分支机构可以更直接地遍历。





选择要去哪个因为它取决于几件事情。





就我个人而言，如果我在一个短暂的功能分支上，我经常会重新绑定和重新绑定。





---





有些情况下您可能没有选择进行重新分配 - 如果您从分支开始错误的观点。例如，您可能已检出特定功能并开始处理其他事情。在其基于的功能之前可能需要其他东西进行合并和部署。在这一点上，将您的更改重新分配到不同的分支将允许您获得独立于其他分支的功能。





---





当您将重新设计的分支合并回主设备时，即使历史记录是线性的，仍然是合并。你可能会在git中看到一条消息，告诉你它做了一个快进合并。这意味着它只是将参考主移到了新的位置。你可以告诉git不要这样做，然后用git merge命令中的 - no-ff 标志创建合并提交。





线性历史记录：

$ p $ * HEAD，master，your_branch：最后一次提交
|
*
|
*
|
*
|
*
|
*以前的主人：其中主人是您重新发售时


使用no-ff合并提交：

  * HEAD：将分支your_branch合并到master 
 | \ 
 | * your_branch分支中的最后一个提交
 | | 
 | * 
 | | 
 | * 
 | | 
 | * 
 | / 
 *以前的主人：您分支的起点
  




I have been using Merging heavily on master branch. But recently for a feature development in my situation merging seemed complicated for the project history. I came across Rebasing which solves my problem. I also came across the golden rule of rebasing while solving the problem.

I also used Stashing at times, it worked, but I feel like the same thing could have been achieved with merging as well.

Although I use these commands, I feel like if someone can explain the conceptually outstanding facts/rule about these three commands it would help me to get a clearer understanding. Thanks.

解决方案

Stashing is very different, in that it essentially sets aside your changes for your later. Useful if you're in the middle of something and you have to jump onto something else and switch branches.

Merging and rebasing achieve the same thing in the end - combining changes into one branch.

• Rebasing gives an arguably "cleaner" history and conflicts are resolved inline.
• With merging, conflicts are resolved in the merge commit.
• A rebased branch is still merged back to master when it's complete.

The difference is that resolving the conflict inline effectively makes it as though the conflict never happened, because you're editing the file again to incorporate the change that caused the conflict.

That can be useful when you're looking back at the changes later.

The caveat, as you alluded to, is that rewriting history makes it hard or impossible to collaborate with others on that particular branch.

---

A series of merges from a long-standing feature branch can be quite hard to follow when looking at the graphs or visual representations from tools like gitg.

With rebases, it's much easier to follow the changes visually. It can also help when you're using tools like git-bisect to find the origin commit of bugs, as the branches are more straightforward to traverse.

Choosing which to go for depends on a few things.

Personally, I rebase and rebase often if I'm on a short-lived feature branch that I'm working on alone. Otherwise it's a merge.

---

There is a situation where you might have no choice to rebase - if you started your branch from the wrong point. For example, you may have had a particular feature checked out and began working on something else. That something else might be required to be merged and deployed before the feature it's based on. At this point, rebasing your changes onto a different branch will allow you to get that feature released independent of the other.

---

When you are merging a rebased branch back into master, that is still a merge, even if the history is linear. You may see a message in git telling you it did a "fast forward" merge. That means it merely moved the reference "master" to its new position. You can tell git not do this, and create a merge commit anyway, with the --no-ff flag on the git merge command.

Linear history:

* HEAD, master, your_branch: your last commit
|
*
|
*
|
*
|
*
|
* previous master: where master was when you rebased

rebased history with a no-ff merge commit:

* HEAD: merge branch your_branch into master
| \
|  * your_branch the last commit in your branch
|  |
|  * 
|  |
|  *
|  |
|  *
|/
* previous master: the starting point of your branch

这篇关于Git中的合并，存储和重新绑定有什么概念上的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！