关于出现Merge remote-tracking branch ‘origin/develop‘ into develop这种commit记录的原因

引子：关于原文链接，可参考https://stackoverflow.com/questions/6406762/why-am-i-merging-remote-tracking-branch-origin-develop-into-develop，点赞最多的回答果真是比较精品的

问题：

合并分支时出现了merge remote-tracking branch 'xxx' into xxxx

转义过来就是 xxxx合并了远程跟踪分支xxx

原因：

试想，我们平时碰到最多的情况就是合并xxx分支到xx分支，即使两个分支是同为版本分支，或者一个版本分支，一个测试分支，也未曾碰到多余的remote-tracking字样，但是有种情况：

git pull is probably creating the commit. If you make a local commit and then run git pull after someone else pushes a commit up to the repository, Git downloads the other developer's commit and then merges it into your local branch.

译：使用git pull有可能出现这样的提交。如果你创建了本地提交，并且在他人提交到仓库之后运行了git pull，那么git 会拉取其他开发者的提交记录并且合并进你的本地分支。

事实上这里，我也并不是很懂，仔细思考了一下，我发现了盲点，我这么讲（与译文内容描述的或许存在不一样的地方，望批评指正！）

我了解到：分支存在两种类型： tracking branches / remote tracking branches

区别在于：tracking branches或许就是我们本地从远端克隆下来的分支，而remote tracking branches，从其命名上即可发现，是远端跟踪分支，那，我们关于commit记录出现多余的remote字段，不就可以发现些什么了嘛？那是因为我们直接在本地分支上就合并了远端分支的引用记录（我们常说的origin/master之类的），当然，这与译文描述的没啥区别，但这里, 我发现了个不同点：

前者是pull oriign xxx，后者是直接merge origin/xxx，即使后者fetch了之后，仍然记录不同

唯一的猜测就是，git本身以此来区分用户是直接合并本地远程还是使用git pull来合并的了。

好了，先点到即止。下方开始翻译其所说的内容 ↓

How to avoid these merge commits in the future（如何避免将来合并这些提交记录呢？）

避免未来出现这种情况，你应该使用git pull --rebase，但是rebase也有其不好的地方，总而言之我建议避免使用pull。

我支持你使用这样的规则来替代上述做法：

# download the latest commits （更新本地远程所有分支commit记录）
git remote update -p# update the local branch （更新本地分支）
git merge --ff-only @{u}# if the above fails with a complaint that the local branch has
# diverged: （如果上述报错说本地分支出现冲突，这样解决）
git rebase -p @{u}

Explanation（解答）

git remote update -p 会下载远程所有记录并且会更新远程跟踪分支（例如: origin/master），此操作并不涉及你的工作区文件，索引以及本地分支。-p 参数会修剪远程已删除的分支。因此，如果origin仓库的foo分支已经被删除了，git remote update -p 就会删除你的origin/foo引用。

git merge --ff-only @{u} 会告诉git合并远程分支（@{u}这个参数）到本地分支，仅当本地分支可以快进到远程分支的记录处（最新记录处）（换而言之，如果其和远程分支并没有冲突）

git rebase -p @{u} 有效的将你已生成的但未提交的记录移动到要推送的分支的顶部，此操作将排除你正竭力避免的创建愚蠢的记录的必要，这保证了开发历史的线性，并且能更简单的回滚。-p 选项告诉git保持合并信息。这会阻止git线性化正在被重构的记录信息。这是非常重要的，例如，如果你将功能分支合并到master分支，没有带上-p选项，那么未来分支上的每一个记录都会作为使用git rebase所形成的线性化记录的一部分被复制到master分支上，这将会使得开发记录非常难回滚/复盘，而不是更简单。

注意：git rebase 或许不会如你所愿的达到目的，那么最好推代码前回顾下。例如：

git log --graph --oneline --decorate --date-order --color --boundary @{u}..

我更欣赏使用上述操作而不是git pull --rebase 是由于以下原因：

其一是：它允许你在修改历史记录并合并它们时看到那些合并进来的远端的记录

其二：它也允许你通过对git rebase使用-p选项(--preserve-merges)以防你想要合并一个有意的合并请求（例如：想要合并进入master的一个已经推送的功能分支）

Shorthand: git up instead of git pull（简写：git up 而不是 git pull）

为了使上述操作更简单，我建议创建一个别名up来做：

git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

现在你想要让你的分支进行更新，所有需要做的仅仅只是运行 git up 而不是 git pull 如果你获取到了一个错误，那就是因为你的本地分支已经和远程分支有所冲突，这就是暗示你，要去 rebase 了

Why not git pull --rebase? （为什么不使用 git pull --rebase）

运行 git pull --rebase 与运行 git fetch 然后 git rebase 是一样的。它会尝试快进到最新的远程分支记录处，但是如果行不通的话，它会重构你的本地记录到新的分支记录上去。通常来说，这是ok的，但是要小心：

1. Rebase 是一个比较高级的主题，在做此操作之前你需要理解其含义再下手。

2. git pull --rebase 在合并记录之前是不会给你检查他们的机会的。它依赖于那些改变了远端的操作，更可能的是rebase会是一个糟糕的操作 -- 一个 rebase --onto, merge, reset , 或者 push -f 都可能比一个单独的 rebase 要合适。

3.将 --preserve-merges 传递给 rebase操作就目前而言是不行的，因此任何一个带有目的性的功能分支的合并都将被线性化（记录呈一条直线），且记录上也将重新出现那些功能分支的记录（所有的，因此导致了重复）。

"Fixing" an existing merge commit created by git pull（解决由git pull创建的已存在的merge记录）

如果你目前还未推送一个通过 git pull 之后创建的合并记录，你就能把这个合并记录重构出来，假设你现在还未做一个带有目的性的合并（例如：将一个已推送到远程的功能分支合并进入你的本地分支），接下来应该这样做：

git rebase @{u}

上述操作会告诉git从 HEAD指向（当前记录，应该也是最新记录）中选出所有可达的且非合并的记录，移除 @{u} 中可达的记录(这是“远端分支”的缩写，例如：origin/master, 如果当前指向是master的话)， ps: 这里个人理解的是，找到head指向的本地分支和@{u}共同的分支点，然后分别可达的这一串记录（原文描述为reacheable，但是并没有特指从哪里到哪里) 并将选中的记录移到此刻分支的头部..

待续（剩下的翻译内容似乎作者写的有问题）

补于2021年5月9日23:51:34

再言之，git rebase意指变基操作，但我更欣赏重构这个词，如我在A分支，执行了rebase操作，那么rebase后的分支就代表了我即将变动过去的分支，如：

git checkout A

git rebase B (回溯A当前分支记录到与B共同的祖先节点，并保存这些记录，然后重构到B分支上，且是在B当前最新分支记录上再新增这些记录）

ps:此时如果有冲突，就解决冲突,该add就add，然后commit，再git rebase --continue，直到无冲突

完~(有错误之处，望指正~）