在 Git 中从 master 更新分支

要将远程 master 分支中的提交纳入功能分支，请先切换到功能分支，获取远程更新，然后合并或变基 origin/master。这些命令会更新当前检出的分支；它们不会更新 master 本身，也不会自动推送任何内容。

合并会保留功能分支已有的提交；如果两条分支的历史已经分歧，Git 会通过合并提交记录这次整合。变基会将功能分支的提交重新应用到已获取的 master 提交之上，因此会生成新的提交标识。若其他人也在使用该功能分支，通常应选择合并；对于尚未发布的工作，变基通常更简单。

前置准备：确认当前分支并获取更新

在仓库中确认当前检出的是功能分支。如果需要切换分支，请将 feature 替换为你的分支名称：

运行下面的本地练习示例，观察功能分支如何接收来自已获取的远程 master 分支的提交。示例会创建临时仓库，并在结束时将其删除：

本节中的代码以及显示的标签或输出仍为英文。

set -eu
root="$(mktemp -d)"
trap 'rm -rf "$root"' EXIT

git init -q "$root/seed"
cd "$root/seed"
git switch -q -c master
git config user.name Example
git config user.email example@example.com
printf 'base\n' > shared.txt
git add shared.txt
git commit -q -m 'Add base file'

git init -q --bare "$root/origin.git"
git remote add origin "$root/origin.git"
git push -q -u origin master

git clone -q "$root/origin.git" "$root/work"
cd "$root/work"
git config user.name Example
git config user.email example@example.com
git switch -q -c feature
git switch -q master
printf 'master update\n' > master.txt
git add master.txt
git commit -q -m 'Update on master'
git push -q origin master
git switch -q feature
git fetch -q origin
git merge -q --no-edit origin/master
printf 'Feature branch updated from origin/master.\n'

Feature branch updated from origin/master.

脚本会检出 feature、获取 origin 的更新，并合并 origin/master。在自己的仓库中，可以用 git branch --show-current 确认当前分支；如有需要，运行 git switch feature，然后执行 git fetch origin。

使用合并更新功能分支

检出功能分支并获取更新后，将远程跟踪分支合并到当前分支：

核心命令是 git merge origin/master。

此操作会纳入可从 origin/master 到达的提交，同时保留功能分支现有提交的标识。如果两条分支的历史已经分歧，Git 会在合并完成后创建一个合并提交；如果一条分支只是包含另一条分支，Git 则可能直接快进。无论哪种情况，都不会推送到远程仓库。检查合并后的历史和工作区；确认分支可以共享后，再单独推送。

如果队友可能已经基于该功能分支开展工作，合并是实用的选择，因为它不会改写已有提交。合并后的历史可能包含合并提交，用来记录两条开发线汇合的位置。

使用变基更新功能分支

若要让功能分支的提交排在已获取的 master 提交之后，请在检出功能分支时运行：

对应的命令是 git rebase origin/master。

变基会将功能分支的每个提交重新应用到 origin/master 之上。即使提交所包含的改动相同，新提交也会有新的标识，因为其父级历史已经改变。这样可以形成更线性的历史，但也会改写分支历史。变基通常适用于尚未发布，或尚未被其他人用作开发基础的工作。

变基成功后仍不会自动推送。如果该功能分支已存在于远程仓库，变基后更新远程分支可能需要替换其旧提交历史。操作前请先与使用该分支的人协调，并使用 --force-with-lease，不要使用不带保护的强制推送。该选项会检查远程分支是否仍指向本地 Git 预期的位置，从而降低覆盖队友期间推送内容的风险；但它不能替代事先协调。

如何选择合并或变基

如果功能分支由多人共用、需要保留已发布分支的历史，或希望明确记录整合点，请选择合并。合并不会改变现有提交的标识，但可能会在提交图中添加合并提交。

如果功能分支上的工作是私有的或尚未发布，而且你希望历史保持线性，可以选择变基。变基会改变重新应用的提交标识；除非团队已就如何处理改写后的历史达成一致，否则应避免变基那些协作者可能已经获取的提交。项目也可能规定必须使用其中一种方法；请遵循项目约定。

无论选择哪种方式，都应先获取更新，以便操作使用最新的 origin/master，并确认当前检出的是预期的功能分支。如果获取更新后 master 又有新提交，请再次获取更新，再将其整合进来。

解决冲突并推送更改

当两条分支上的改动相互重叠时，Git 可能会暂停合并或变基。它会在工作区中标记冲突文件，但不会自动将所有冲突合并成正确结果。打开每个标记的文件，选择或编辑所需内容，删除冲突标记，并暂存已解决的文件。继续操作前，请检查差异。

合并时，如果 Git 尚未创建合并提交，请运行 git commit 完成操作。若要放弃正在进行的合并并恢复到合并前的状态，请使用 git merge --abort。

变基时，暂存每个已解决的文件，然后运行 git rebase --continue 继续。Git 可能会在处理另一个提交时再次暂停；如有需要，重复解决冲突并继续。若要放弃正在进行的变基，请使用 git rebase --abort。不要用合并命令继续变基，也不要反过来混用。

任一操作完成后，先检查 git status 并查看提交，再推送。通过合并更新的分支通常可以用 git push origin feature 推送（将 feature 替换为实际分支名称）。如果你变基的分支已推送到 origin，请先协调，再运行 git push --force-with-lease origin feature 更新它。如果租约检查拒绝了推送，请获取更新并检查远程更改，不要强行覆盖。对于私有功能分支，创建远程副本时正常推送即可。