git rebase和git push:非快进,为什么要使用？

我有一个应该可供其他贡献者使用的分支,并且应该始终与主人保持同步.

不幸的是,每当我做'git rebase'然后尝试推动时,它会导致'非快速前进'信息和推动堕胎.推动这里的唯一方法是使用--force.这是否意味着如果我的分支公开并且其他人正在研究它,我应该使用'git merge'而不是rebased？

1> gahooa..：

---

关于git如何工作的一些注释(非技术性的):

当你进行rebase时,git会接受有问题的提交,并在干净的历史记录中"重新发送"它们.这是为了防止历史显示:

Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg

在变基之后,它可能看起来像这样(或类似):

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

问题在于,您尝试推送的新提交不是您要推送的分支机构提示的后代.

现在,你知道提交中的信息是相同的,但git负责的不仅是覆盖那些提交(上例中的bbbb-gggg).

---

共享回购模型

如果您使用的是共享存储库,那么这样的事情可能会让人感到困惑.让我解释一下原因.假设另一位开发人员拉下了分支机构,他们在他们的分支中提交了aaaa - > gggg.然后他们做出提交iiii

同时,你重新加入并强制推送,导致树看起来像这样:

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

当其他开发人员试图推送时,他会收到"非快进"消息.当他进行合并时,两个历史都被重新连接在一起,你最终会陷入混乱

像这样的东西(凌乱):

Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge 
Commit SHA1: aaaa -> hhhh   -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg -> iiii    -> jjjj

换句话说,如果其他人正在拉动和推动,那么你最好坚持使用git merge,或者在rebase之后避免推动(并且只会改变你的工作).

---

公开可见的存储库模型

也许你正在使用一种不同的(更加轻微的)模型,你只希望人们能够从你的回购中获取.在这种情况下,git push --force并不是太糟糕,因为那时他们可以处理跟上它的问题.在向您提供修补程序之前,他们可以将更改重新设置为您的更改.它可以防止你的仓库搞砸了.

但是,对您来说可能有更好的方法. git push --mirror

来自http://www.kernel.org/pub/software/scm/git/docs/git-push.html

而不是将每个引用命名为push,指定将$ GIT_DIR/refs /(包括但不限于refs/heads /,refs/remotes /和refs/tags /)下的所有引用镜像到远程存储库.新创建的本地引用将被推送到远程端,本地更新的引​​用将在远程端强制更新,并且已删除的引用将从远程端删除.如果设置了配置选项remote..mirror,则这是缺省值.

---

关于git的一个好处是它非常灵活,允许许多不同类型的工作流程.但它的真正优势在于它是一个分布式模型,所以我相信通过这种方式使用它可以获得最大的投资回报率.

---

呃,实际上,合并创建了合并提交,缺乏必要的澄清.相反,它很棒`git fetch,git rebase origin/master`,解决与主(集中)分支的所有本地冲突,然后推送只向前移动的纯提交.`git pull --rebase`有类似的工作流程.这是一个强大的选项,但你必须要小心它,因为从错误的东西重新定位可以重写已经在origin/master中的提交.例如,除非他们首先在当前的origin/master上重新定位,否则不要重新绑定其他分支.

---

我喜欢解释为什么会有问题,推动一个重新分支.但我不确定 - 镜像实现了什么.阅读描述 - "指定*所有引用*将被镜像" - 困扰我.我不希望*所有refs*镜像,只有一个分支.:)命名一个分支只镜像那个？我从git docs中不清楚这一点.