如何使用rebase保持git子/特性分支与主分支同步

有一个名为develop的主分支。并且一个分支（feature_branch_1）起源于开发分支。我正在对feature_branch_1进行更改。假设我将在feature_branch_1上工作两周。而每一天，我需要我的feature_branch_1同步增长与发展分支的变化（develop分公司将不得不他人犯下的变化，我需要有这些变化，让我feature_branch_1将不会从develop分支有太大偏离，我知道在develop分支正在发生的事情为好）如何使用rebase保持git子/特性分支与主分支同步

我试图用git rebase develop详情如下目的，

git checkout develop 
git pull 
git checkout feature_branch_1 
git rebase develop

起初它很好，但是当我做更多的改动feature_branch_1垫底将引入更多冲突。（它说我自己的提交相互冲突，它的可能意味着我的两个提交在同一个文件中修改了同一行，并且Git不知道要应用哪个更改）并且解决这个问题的方法非常多困难且耗时。

上午我做错了使用变基？我怎样才能让我的feature_branch_1同步增长与develop分支总是（至少需要被同步了过去24小时内最新的变化）

注：我检查等相关问题的SO也。根本没有使用rebase，我们可以做到这一点。如下图所示，

git checkout develop 
git pull 
git checkout feature_branch_1 
git merge develop

，并在此之后，

git push origin/feature_branch_1

我能做到这一点的每一天，让我的同步与developfeature_branch_1。 有没有办法与rebase做到这一点没有我自己的提交互相冲突？

来源

2017-02-02 prime

简短的回答是否定的，你无法避免这个时rebasing。长久的回答是，是的，你可以通过使用'git merge'而不是rebase来避免这种情况。然而，粗略地说，''''''''''''''''''''''''''''''''''和''''''''''无论您选择使用哪种工作流程， –

@TimBiegeleisen那么使用rebase进行同步的目的可能不是一个好主意。 – prime

一点都不，实际上我更喜欢重新合并，原因很多。但是，同步会在技术上更复杂一点，你必须善于重新分配资金。 –

是的，你是正确的使用它。冲突文件数量取决于相关提交的变化。如果develop和feature_branch_1都更改了很多文件，则可能会有更多冲突。还有另一种方式做同样的事情：

git checkout feature_branch_1 
git pull origin develop --rebase

这会让你的feature_branch_1基于最新develop分支。

如果您的feature_branch_1在与develop分支的最后一次同步之后有许多提交，您可以在此时间同步之前压缩这些提交，以便提交历史更清晰。

要使用rebase或合并它取决于您是否需要为主项目贡献。 rebase只是让你在最新的开发分支上工作，合并可以使我们的工作成为主要项目的一部分。

来源

2017-02-02 11:03:56