时间戳

首页 > 解决方案 > 在将我的分支与本地仓库中的 Master 合并，然后在 Github 中推送到远程源

git - 在将我的分支与本地仓库中的 Master 合并，然后在 Github 中推送到远程源

问题描述

我想知道对此的最佳实践是什么我从远程 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”？

标签： gitgithubbitbucket

解决方案

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

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

让我引用文档中的一些部分，这些部分可能有助于弄清楚它们的行为方式：

合并

假设存在以下历史并且当前分支是“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 rebase

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

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

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

git rebase master git rebase master 主题将是：

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

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

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

我目前通常遵循的约定是 a git pulland then commits，当我准备好将更改合并到一个分支时，我会执行 a git rebaseand a pull request，最终merges在接受时将分支放在一起。当你做一个 git rebase 时，你会得到一个非常线性的历史。

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

推荐阅读