GIT重建一个合作的分支？ [英] GIT Rebase a Branch that is collaborated on?

问题描述

阅读完本文之后，将rebase从主分支收集到我的功能分支是有道理的：
Git工作流和重新合并vs合并问题

 克隆远程仓库
 git checkout -b my_new_feature 
 ..工作并提交一些东西
 git rebase master 
 ..工作并提交一些东西
 git rebase master 
 ..finish特性
 git checkout master 
 git merge my_new_feature 
  

如果功能分支在我的机器上是本地的，并且我可以根据自己的喜好重写历史记录，这很好。

但是如果我与功能分支上的其他人协作，该怎么办？ 。现在我们的功能分支被保存在远程仓库中，我们如何从主分支获取最新的变化到我们的功能分支？

所以我们合并？或者是否有另一种灵活的GIT方法来做到这一点？

预先感谢！

解决方案如果你一个人工作，rebase什么也不做。你没有提交任何新的东西。

你的合并将是一个快速合并，你可以通过完全不检查它来完成。

  git push。 HEAD：master 
  

无论您是否在与某人合作，将主人的工作合并到您的功能中分支是一个不好的做法。它被称为反向合并。不好的原因是你现在没有一份原子能工作。大师的历史现在与您的功能纠缠在一起，使用这个功能，比如重新绑定，在许多情况下不可能。

你需要考虑你的分支策略和什么你想实现。这是我的：

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

你可以看到每个分支从同一个地方开始。你有一个单独的集成分支和发布候选分支，以混合和匹配你想要的功能，同时不会污染他们。

至于与同事合作一个功能，特征的大小（工作的粒度）。如果它很大，您可以将上述过程应用到特性本身，而不是分支每个任务。

如果它是一个小功能，您可以在该分支上合并或重新绑定 - 它无关紧要。在这一点上，这取决于团队对此感到满意。

After reading this article, it makes sense to rebase to gather changes from the main branch on to my feature branch: Git workflow and rebase vs merge questions

clone the remote repo
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

This works great if the feature branch is local to my machine and I can rewrite history as I please.

But what if I collaborate with someone else on the feature branch. How do we get the latest changes from the main branch into our feature branch now that our feature branch is held in the remote repository?

So we do merge? Or is there another slick GIT method to do this?

Thanks in advance!

解决方案

If you are working alone the rebases do nothing. You did not commit anything new to master.

Your merge will be a fast forward merge and you could do it by not checking it out at all with

git push . HEAD:master

Whether you are working with someone or not, merging work that is in master into your feature branch is a bad practice. It is called a back-merge. The reason that it is bad is that you now do not have an atomic piece of work. the history of master is now entangled with your feature making working with this feature, such as rebasing, impossible in many situations.

You need to think about your branching strategy and what you want to achieve. Here is mine:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

You can see that each branch starts from the same place. You have a separate integration branch and release candidate branch to mix and match the features you want while not contaminating them.

As for collaborating on one feature with a colleague, it depends on how large a feature is (the granularity of your work). If it's large, you can apply the process above to the feature itself and branch per task instead.

If it's a small feature you can merge or rebase on that branch - it won't matter much. At this point it comes down to what the team is comfortable with.

这篇关于GIT重建一个合作的分支？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！