定期更新仓库主分支的重要性

遇到的问题

在sot分支上拉取新的PR时，上次已经合入的commit居然又被视为新commit，导致提交记录非常冗杂。

解决方法、注意事项

是的，当你在 GitHub 上提交 PR（Pull Request）时，通常会是基于你自己 Fork 的仓库的 develop 分支计算的，而不是目标仓库的 develop 分支。这是因为在你的 Fork 仓库中，develop 分支的状态可能和目标仓库的 develop 分支不同步。

具体流程

1. Fork 仓库：你在 GitHub 上 Fork 了一个仓库，这样你就有了一个自己的仓库副本。这个 Fork 仓库与目标仓库有相同的结构和历史记录，但它是独立的。

2. 本地开发：你在本地克隆了自己的 Fork 仓库，并在上面进行开发。在本地开发时，所有的更改都是基于你 Fork 仓库的状态。

3. 同步主仓库的更新（可选但推荐）：如果主仓库（目标仓库）有新的更改（例如 develop 分支有更新），你可以在本地将主仓库的 develop 分支拉取到你的 Fork 仓库，以确保你的分支是基于最新的代码。这一步可以避免在 PR 时产生冲突或包含无关的提交。

4. 创建 PR：当你在自己的 Fork 仓库完成更改后，你可以在 GitHub 上提交 PR，将你的分支（例如 feature-branch）合并到目标仓库的 develop 分支。这时，GitHub 会基于你 Fork 仓库的分支创建差异，比较你的更改和目标仓库的 develop 分支。

注意事项

• 定期同步目标仓库的 develop 分支：为了确保你的更改是基于最新的代码，建议定期将目标仓库的 develop 分支同步到你的 Fork 仓库的 develop 分支。你可以通过 git remote add upstream <目标仓库的 URL> 添加目标仓库的远程引用，然后用 git fetch upstream 和 git merge 或 git rebase 来保持同步。

• 避免冲突：在创建 PR 之前，将目标仓库的 develop 分支同步到你的分支可以减少冲突的可能性。如果你的分支落后太多，可能会在 PR 时引发合并冲突。

通过这种方式，你可以确保你的代码是基于目标仓库的最新代码，并且你的 PR 更容易被接受和合并。

勤merge，勤同步

这种情况通常是由于 分支未正确同步 或 提交历史不一致 导致的。即使在你的 my_feature_branch 上的更改已经合并到 develop，如果历史记录不一致，Git 仍然可能将这些更改视为新的提交，并在新 PR 中显示它们。具体原因包括以下几点：

1. 未正确同步到最新的 develop

如果在你的本地仓库中，develop 分支并不是最新的远程 develop 版本，那么 Git 会在 my_feature_branch 中视这些提交为新的更改。你可以通过以下方式来确认并解决这个问题：

# 确保 develop 是最新的
git checkout develop
git pull origin develop

# 在 feature 分支中合并最新的 develop
git checkout my_feature_branch
git merge develop

2. 不同的提交历史（重复提交）

有时候，重复的提交历史会导致同样的代码被 Git 认为是新的更改。这可能发生在以下情况中：

• 手动复制了代码：如果在 my_feature_branch 中手动复制了 develop 的代码内容，而不是通过合并 develop 分支，这些提交会在新 PR 中重复出现。

• 错误的 rebase 或 merge 操作：如果使用了不合适的 rebase 或 merge 方式，导致提交历史在 my_feature_branch 中产生了重复的提交 ID，这也会导致相同的更改被认为是新的提交。

3. 未正确使用 cherry-pick 或 rebase

如果你在 develop 分支中 cherry-pick 或 rebase 了 my_feature_branch 的提交，那么这些提交的哈希值会发生变化。即使内容相同，Git 也会将它们视为新的提交，因为它们的哈希不同。因此，建议在合并特性分支时直接使用 merge，而不是 cherry-pick 或 rebase，以避免产生重复提交。

解决方法

1. 确认本地 develop 是最新的：

   git checkout develop
   git pull origin develop
   

2. 将最新的 develop 合并到 my_feature_branch：

   git checkout my_feature_branch
   git merge develop
   

3. 检查 PR 中的提交历史：在提交 PR 前，确保 my_feature_branch 中的提交历史没有重复的提交或无关的更改。

4. 如果已经提交了重复 PR，可以重新创建分支：

   • 创建一个新的分支，基于最新的 develop，并 cherry-pick 你想要的提交。
   • 重新提交 PR，确保没有不必要的提交。

通过以上步骤，可以确保 PR 的提交历史清晰，不会包含已经合并到 develop 中的重复提交。