我有一个远程仓库，我已经将其拉取并从中创建了一个分支。我想让新的分支与主分支的更改保持同步。我考虑以下工作流程，这是否合理，或者有更好的方法来实现？
初始分支和检出：
git checkout master
git pull
git checkout -b my_branch
在我的分支中做一些工作，然后定期执行：
git checkout master
git pull
git checkout my_branch
git merge master --no-ff
按需重复执行步骤 2，并定期推送到远程分支my_branch。
然后当准备好合并回去时：
git checkout master
git merge my_branch --no-ff
听起来可以吗？
git fetch
git checkout -b my_branch origin/master
2.
git fetch
git merge origin/master
git fetch 命令会更新你的远程分支，如果你不打算在某个分支上进行工作，通常情况下是没有必要在本地保留这个分支的副本的。
在运行 git config --global merge.ff false 后，你可以省略 --no-ff 参数。
git help config 命令的解释如下：
merge.ff
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to false,
this variable tells Git to create an extra merge commit in such a
case (equivalent to giving the --no-ff option from the command
line). When set to only, only such fast-forward merges are allowed
(equivalent to giving the --ff-only option from the command line).
请注意，git pull只是git fetch和git merge的组合。
通常你只需要使用git pull --rebase，它本质上是git fetch和git rebase的结合，可以创建更清晰的提交历史记录。
你是否有进行“定期推送”的原因？如果没有其他人在同一分支上工作，完全可以在完成一切工作后再进行推送。
git pull --rebase而不是git pull。git merge master --no-ff，而是使用git rebase master。但是，如果该功能分支在开发过程中需要与同事共享，则最好定期将主分支合并到功能分支中。
git pull --rebase的内容，但如果我在（比如说）my_branch中调用它时会发生什么还不是100％确定。在这种情况下，该命令从my_branch远程拉取，然后重新基于...哪个分支？我想不是主分支，因为我没有在命令中提到它。所以它必须重新基于my_branch，这对我来说听起来有点奇怪，因为我总是将两个单独的分支进行重新基于。但我认为这是可能的，现在我想了想，为什么不呢？ - larryqgit pull和git pull --rebase都能与配置的上游分支合作（详见git branch -vv）。通常，本地分支“my_branch”将跟踪远程分支“origin/my_branch”。但在第一次推送之前，跟踪“origin/master”也是可以的。git pull --rebase仅获取上游分支的当前版本，将您的分支重置为该版本，并回放您所做的所有提交。因此，您会得到相同的更改，仅基于上游分支的当前版本。 - michasgit tag old_state; git pull --rebase; gitk HEAD old_state命令来查看 rebase 的工作情况。假设你已经进行了一些本地提交，并且上游有新的提交，那么你应该能够看到基于旧版本上游的原始提交以及基于当前版本上游的 rebase 提交。 - michas