长寿（远程）功能分支上的git rebase [英] git rebase on long-lived (remote) feature branches

问题描述

背景：我们使用github作为我们的项目，并且我在我们自己的主存储库上工作。我们使用rebase而不是merge来避免大的合并提交。

情景：我想工作的方式如下所示：

1. 实施新功能时，请创建叉子主人的本地分支，然后在其中进行更改。我和组中的其他人进行了许多小的提交，因此几乎总是会有多个提交影响分支上的同一文件。


2. 将本地分支推送到我的分支，远程复制我正在工作的内容（如果我的笔记本电脑死亡或丢失，我不想让所有更改都丢失，我在每天结束时尝试这样做）。


3. 如果完成该功能需要很长时间，我偶尔会在叉子的主设备上进行重新绑定，以确保没有可能会破坏我的功能的更改。这通常工作正常。


4. 为了让分支的远程副本保持最新状态，我将本地分支推到rebase后面。

问题：第4步是我遇到问题的地方。我几乎总是必须处理非快速转发的提交并使用git push --force。

我曾看过

Git：如何维护永久并行分支

>

并没有找到让我的工作流程工作的方法。在git工作流上进行谷歌搜索通常返回的结果是，假设您都在本地分支上工作，并且不在github上保留远程副本（例如 http://nvie.com/posts/a-successful-git-branching-model/ ）。

我对Git比较陌生，所以我想知道我是否在这里失去了一些东西。我希望能够在没有--force的情况下执行第4步。一个替代的工作流程，仍然允许我使用rebase而不是merge，并保留我的本地分支的远程副本，这也是非常有用的。 解决方案

git push --force 是处理rebase和远程分支时的一个事实，因为 git push 没有它就不会做非快进的推动。 git中的大部分内容都假设历史只附加到，没有编辑过，并且rebase会打破这个假设，所以你必须做一些非常不可思议的事情才能实现它。

我们过去使用的rebase工作流程与您描述的工作流程非常相似，但最终在一段时间后最终切换回合并工作流程。重新分配给你一个很好的，漂亮的，线性的历史，但有许多缺点，例如需要 --force ，在合并之前失去了查看分支状态的能力master，等等。

正如Amber提到的，rebase使得与同一分支上的其他人一起工作非常困难 - 在 git push之前 - -force ing，你必须查看远程分支的状态以查看是否有其他人先推送到它，并且 pull --rebase 中，然后 git push --force 。即使这有一个竞争条件 - 如果有人在你之前推动 push --force ，他们的改变将被你的改写。

Background: We use github for our project and I work on my own fork of our main repository. We use rebase instead of merge to avoid large merge commits.

Scenario: The way I want to work is like this:

1. When implementing a new feature, create a local branch of my fork's master and put in my changes there. I and others in the group make many small commits, so there will almost always be multiple commits that affect the same file on the branch.
2. Push the local branch to my fork so I have a remote copy of what I am working on (I don't want to have all my changes lost if my laptop dies or is lost. I try to do this at the end of each day).
3. If it takes a long time to finish the feature, I occasionally rebase on my fork's master to make sure that there has been no changes that could break my feature. This usually works ok.
4. To keep the remote copy of the branch up to date, I push my local branch to that after the rebase.

Problem: Step 4 is where I get the problems. I almost always have to deal with non-fast-forwarded commits and use git push --force.

I've looked at

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

and haven't found a way to make my workflow work. Doing a google search on git workflows mostly returns results that assume that you all work on local branches and don't keep a remote copy on github (e.g. http://nvie.com/posts/a-successful-git-branching-model/).

I'm relatively new to Git, so I'd like to know if I am missing something here. I'd like to be able to do step 4 without a --force. An alternate workflow that still allows me to use rebase instead of merge and keep a remote copy of my local branch would also be very useful.

解决方案

git push --force is a fact of life when dealing with rebase and remote branches, because git push won't do a non-fast-forward push without it. Most things in git assume that history is only appended to, never edited, and rebase breaks that assumption, so you have to do some pretty wonky things to make it work.

We used to use a rebase workflow very similar to the one you describe, but eventually switched back to a merge workflow after a while. Rebasing gives you a nice, pretty, linear history, but has many drawbacks, such as requiring --force, losing the ability to see the state of a branch before you merge in master, et cetera.

As Amber mentions, rebase makes it very difficult to work with other people on the same branch -- before git push --forceing, you have to look at the status of the remote branch to see if someone else has pushed to it first, and pull --rebase that in, then git push --force. Even this has a race condition - if someone else pushes just before you push --force, their changes will get overwritten by yours.

这篇关于长寿（远程）功能分支上的git rebase的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！