我们经常从主分支(master)分支出来,开始在大的功能分支上工作。这些功能分支通常会被工作了几天甚至几周之后才与主分支合并(尽管最佳实践指导我们需要尽可能频繁地进行合并,但实际情况可能不同)。
因此,我们尽可能地使用"git pull --rebase origin master"命令来保持与主分支的同步。然而,在某些情况下,我们可能会遇到以下情况:
1. 从主分支(master)分支出来,创建一个名为"feature/new-branch"的新分支。 2. 在"feature/new-branch"中进行更改,并提交更改。 3. 运行"git pull --rebase origin master"命令,将提交放在主分支上面。修复任何冲突,并运行"git add ."和"git rebase --continue"命令。 4. 继续在"feature/new-branch"中进行更改,并提交更改。 5. 再次运行"git pull --rebase origin master"命令。
但是,在第5步中,我们需要解决与第3步相同的冲突。这可能会很麻烦。
这是否是正确的最佳实践git流程?如果不是,我们还可以做些什么来使过程更有效率?
因此,我们尽可能地使用"git pull --rebase origin master"命令来保持与主分支的同步。然而,在某些情况下,我们可能会遇到以下情况:
1. 从主分支(master)分支出来,创建一个名为"feature/new-branch"的新分支。 2. 在"feature/new-branch"中进行更改,并提交更改。 3. 运行"git pull --rebase origin master"命令,将提交放在主分支上面。修复任何冲突,并运行"git add ."和"git rebase --continue"命令。 4. 继续在"feature/new-branch"中进行更改,并提交更改。 5. 再次运行"git pull --rebase origin master"命令。
但是,在第5步中,我们需要解决与第3步相同的冲突。这可能会很麻烦。
这是否是正确的最佳实践git流程?如果不是,我们还可以做些什么来使过程更有效率?
git rerere
下的答案中提到的第一个链接。 - VonC