在 Github 中推送到远程源之前，将我的分支与本地仓库中的 Master 合并

Question

我想知道最好的做法是什么我有一个来自远程 bitbucket 回购的克隆回购，我已经从回购中创建了一个分支，我在特定文件夹中创建了一个.json 文件。 在我对我的文件感到满意并想推送到 origin 分支之后，我应该先在我的本地 master 中做一个“git merge branch”，然后再在我的分支中做“git push origin/branch”吗？ 期待任何帮助。 我还被告知，在推送到原始分支之前，我应该通过在分支上执行“git rebase master”所以我应该在完成本地 repo 分支中的文件处理后执行“git rebase master”，然后首先执行“git pull origin/branch”然后执行“git rebase master”？

Answer 1

Rebase 和 Merging 是将两个或多个开发历史组合在一起的两种不同方式。 您选择的技术基本上归结为您希望分支组合时的外观或您的偏好。 （当我说你时，这可能包括在同一代码库上工作的其他人）。

要选择一个，最好的开始是文档，这是git merge和git rebase的文档。

让我引用文档中的一些部分，这些部分可能有助于澄清关于它们如何表现的想法：

---

GIT 合并

假设存在以下历史并且当前分支是“master”：

  A---B---C topic
 /
D---E---F---G master

然后“git merge topic”将重播在主题分支上所做的更改，因为它从主分支（即 E）开始，直到它当前的提交（C）在主分支之上，并将结果与名称一起记录在新的提交中两个父提交和来自用户的描述更改的日志消息。

  A---B---C topic
 /         \
D---E---F---G---H master

---

GIT 重置

假设存在以下历史并且当前分支是“主题”：

      A---B---C topic
     /
D---E---F---G master

从这一点来看，以下任一命令的结果：

git 变基大师 git 变基大师主题将是：

              A'--B'--C' topic
             /
D---E---F---G master

---

注意分支合并后的样子。 Git merge 会将多个提交序列组合成一个统一的历史记录，其中 git rebase 会在另一个基础上重新应用更改。

现在，当您克隆一个存储库并提交更改时，您的本地分支与远程分支不同。 当您准备好将新更改推送到远程分支时，远程分支可能包含与本地分支不同的历史记录。 这就是为什么您希望在将本地更改推送到远程之前更新本地分支以反映在远程分支中所做的更改。 为此，您可以使用git fetch或git pull ，具体取决于您要完成的任务。 默认情况下，当您执行git pull取时，它将执行git fetch ，然后执行git merge 。 如果您查看文档，您会找到更改此默认行为的方法。 正如我无法告诉您在书架上对书籍进行排序的唯一方法是按字母顺序对它们进行排序一样，我也无法直接告诉您您的流程应该是什么。 如果您尝试将分歧的引用推送到一个分支，您将面临冲突，您必须先解决冲突，然后操作才能继续进行。

我目前通常遵循的约定是git pull然后commits ，当我准备好将更改合并到分支时，我会执行git rebase和pull request ，最终在接受时将分支merges在一起。 当你执行 git 变基时，你会得到一个非常线性的历史记录。

以前，当我想要合并两个分支时，我在使用远程更新历史记录后在本地执行git merge ，然后使用git push更新远程分支。