Git merge-如果我合并一个旧分支，旧的问题会合并到master吗？

时间：2016-12-20 10:20:31

标签： git version-control merge git-branch git-diff

我使用Git作为我开发的版本控制，并且它相对较新。

在开始这个项目的工作之后不久，我创建了一个名为updateCards的分支来解决项目中的特定错误。

但是，在处理此问题时，在我将更改推送到服务器之前，还提出了其他一些需要更多紧急注意的错误。因此，我将更改提交到updateCards，然后针对其他每个更紧迫的错误切换到新分支。

我已经解决了这些其他错误，将我为它们创建的分支合并到master中，并将我的更改推送到每个服务器的服务器。

我现在想回到旧的updateCards分支，将其与master＆amp;推送到服务器。当我从updateCards分支查看项目时，我可以看到该分支创建的错误已经解决，所以我很高兴我准备将它推送到服务器。

但是，我不确定的是，如果我在创建master后对服务器上的updateCards进行了其他一些更改，那么我将updateCards合并到{ {1}}现在，我是否会合并master中现有的任何旧错误，但现在已在updateCards中解决回master，因为这些错误已修复的文件on master与master上的那些文件有什么不同？或者，Git会发现updateCards对这些文件的更改比master上的更改更新，因此不会合并这些更改吗？

我运行了updateCards，这显示了两个分支之间差异的输出：

git diff master..updateCards

但我不确定如何解释此输出...这些行以diff --git a/buying/templates/buying/update_card_numbers.html b/buying/templates/buying/update_card_numbers.html index 6cc5938..5f6a8f3 100644 --- a/buying/templates/buying/update_card_numbers.html +++ b/buying/templates/buying/update_card_numbers.html @@ -25,8 +25,8 @@ <table class="left"> <thead> <tr> - <th>Cardholder</th> <th>card no</th> + <th>Cardholder</th> </tr> </thead> diff --git a/buying/views.py b/buying/views.py index 08d2fd6..c777020 100644 --- a/buying/views.py +++ b/buying/views.py @@ -1555,6 +1555,8 @@ def update_card_numbers(request): cardholder = data['id'] cardholder.card_no = data['card_no'] cardholder.save() + #cardholder.card_no.save() + #data['travis_card_no'].save() print cardholder, cardholder.card_no HttpResponseRedirect(reverse('buying:update_card_numbers')) diff --git a/costing/templates/pdf2_base.html b/costing/templates/pdf2_base.html index 3826a98..c139068 100644 --- a/costing/templates/pdf2_base.html +++ b/costing/templates/pdf2_base.html @@ -83,8 +83,6 @@ <td> <span class="project-name">{{project.project_name|upper}}</span> </td> - <!--ERF(07/12/2016 @ 1615) Display today's date in the header --> - <td> {% date_to_display %}</td> </tr> </table> </div> diff --git a/costing/views.py b/costing/views.py index 902f9ff..f8a3f77 100644 --- a/costing/views.py +++ b/costing/views.py @@ -2438,9 +2438,6 @@ def pdf2_master(request, project_id): """ Save to the current budget (no version number), as versions not used once deposit is received """ budget = get_current_budget(project_id) - #ERF(07/12/2016 @ 1615) Create a date variable to displays today's date on the PDF when it's generated - date_to_display = datetime.now() - if not budget: Budget.objects.create(project=project, current_marker=1) 开头，-中存在但updateCards中没有，以及以master开头的+以及master中不存在的内容，反之亦然？

如果我运行updateCards？

，哪些更改将被复制到哪个方向

2 个答案:

答案 0 :(得分：0)

您永远无法预料到来自一个差异的合并

要查看合并将执行的操作，您需要两个差异。 1

您还需要找到合并基础（或让Git为您完成）。这是因为合并是关于组合变化，并将两个民族结合起来。变化，我们必须找到他们都开始的共同点。那个起点让我们（或Git）能够弄清楚我们做了什么＆＃34;和＆＃34;他们做了什么＆＃34;。

然后，您可以运行两个差异：git diff merge-base tip1和git diff merge-base tip2。进行合并 - 这是＆＃34;合并＆＃34;作为一个动词 - 然后将这两个差异组合成一个适用于合并基础的大变化。

等效地，您可以将其视为：在第二个差异中找到第一个差异中已经存在的东西，并将它们添加到应用第一个差异的结果，即 {{ 1}} 的。这假设您要将新合并作为扩展 tip1 的提交。

例如，如果您在分支机构tip1上并且您正在分支main中进行合并，那么 fix 就是commit-ID {{ 1}}解析为， tip1 是提交ID main解析的任何内容。一旦合并（作为动词）完成，您将进行新的合并提交 - 这是＆＃34;合并＆＃34;作为形容词tip2，以便fix现在命名您刚刚创建的新合并提交。新合并的内容（＆＃34;合并＆＃34;作为名词，意思是＆＃34;合并提交＆＃34;）是由合并为动词的过程产生的，它结合了两个差异。 / p>

1 在一些相当罕见的复杂案例中，您需要两个以上，但我们会在这里忽略它们。

如果这令人困惑，我不确定其余的会有所帮助。但最后还是奖励：快速运行main以获得所需的两个差异。 ： - ）

解释

由于您是Git的新手，我们来定义一些项目。他们可能已经足够熟悉了，但有特定的定义是很好的。

树是一组文件。您使用的树是您的工作树（也拼写工作树，工作树等）。您的工作树可能包含未提交的文件：这些文件是未跟踪的文件。你可以让Git＆＃34;忽略＆＃34; （停止抱怨）其中一些未跟踪的文件，当您使用main或git diff等时，也不会自动添加它们以进行跟踪和提交。 （未经跟踪的文件对于差异和合并并不重要，我只是提及它们的完整性。）

提交是一个永久的，不可更改的树快照，带有一些同样永久的，同样不可更改的元数据：某人的姓名和电子邮件地址，时间戳，一条日志消息，以及一个父母的概念＆＃34; commit-or，对于merge commit，两个父级。 2

要进行新的提交，您可以使用Git的索引，这也称为＆＃34;暂存区域＆＃34;和＃34;缓存＆＃34;。它基本上是您构建 next 提交的地方。它开始包含当前提交，并使用git add .更新其中的文件或将新文件放入其中;然后git add -A将索引转换为新的快照树，添加提交元数据 - 添加您的姓名和电子邮件，＆＃34;现在＆＃34;作为时间戳和您的日志消息。

每个提交都有一个唯一的哈希ID，例如git add。它们对于人类来说太大而且丑陋，所以我们要么缩短它们，要么给它们起名字。名称有很多形式，但关键是他们总是最终解析为哈希ID。这些是真正的名字＆＃34;。

总有 3 当前提交，您可以使用名称git commit命名。通常，d5c49eb32e898663a8e2c396739d831733e945c2实际上包含分支名称而不是原始提交哈希ID，并且分支名称包含实际的哈希ID。

任何新提交的父是您运行HEAD时 当前的提交。也就是说，新提交的父级是HEAD 是，然后git commit接受新提交的新ID。即使对于新的合并提交也是如此，即使他们必须至少有两个父母。第一个＆＃34;主要＆＃34;父母来自HEAD;其他人来自你合并的任何东西。

这就是Git如何形成真正的分支。分支名称是ephemeral，只要您愿意保留它们就会持久。 提交是永久性且不变的，每个提交都记录其父（或父项）...因此我们可以通过向后工作将提交字符串串起来，从最新提交开始

2 从技术上讲，两个或更多。具有三个或更多父项的合并提交称为章鱼合并。但是，他们不会做任何与常规合并无关的事情。

此外，提交还附加了两个 name-email-timestamp三元组： author 和 committer 。对于你自己提交的提交，没有太大的区别，但是对于那些得到重组或合并或通过电子邮件发送为补丁或其他内容的提交，这些单独的＃34;谁写了这个提交，以及何时＃34;来自＆＃34;谁真正将它放入回购，以及＆＃34;。

3 此规则有一个例外。显然，在一个新的，空的存储库中，根本没有提交，因此不能成为＆＃34;当前提交＆＃34;。 Git将此概括为不一致地称为 orphan分支或未出生的分支的东西，其中HEAD包含分支的名称，但分支名称本身也是如此在其他地方都不存在。在此状态下进行新提交实际上创建分支名称。新提交是 root 提交：一个没有父项。在那之后，这个奇怪的边缘状态得到解决，新的提交像往常一样得到父提交。

Git向后绘制图表;找到合并基础

这一切意味着Git（和我们）应该在＆＃34;最新提交＆＃34;中使用分支名称绘制我们的图表。结束，指向每个分支的提示提交。当我水平绘制它时，我这样做：

HEAD

此处，名称HEAD指向o <- o <-- master 分支上的第二个和最后一个（＆＃34; tip＆＃34;）提交。该提交指向第一次提交。当然，第一次提交没有先前的提交，因此它是 root 提交，我们可以在这里停止。

内部向后箭头在大多数情况下几乎没有价值，所以我只是将这些图形绘制为：

master

如前所述，较新的提交位于右侧，因此master和o--o--*--o--o <-- master \ o--o--o <-- fix - 分支名称 -point指向其对应分支的提示图片片段。

现在，在这种情况下，我用master标记了一个特定的提交。当我们从两个提示开始并向后工作时，这是最近的常见提交。也就是说，它是Git工作的第一个 - 在两个分支上提交。 （在图论中，它是有向图中两个顶点的最低公共祖先，虽然在这里，Git的弧也是通常的样式。）

无论如何，这个＆＃34;最近的共享提交＆＃34;是合并基础的实际定义。在一些复杂的图形中，可能有多个合并基础，但在像这样的简单的fork-and-rejoin情况下，只有一个合并基础。

如果你有一个很好的清晰的图形绘图，找到合并基础（或基础）很容易。复杂或凌乱的图表使其更加困难。但是，Git有一个命令来查找特定提交的合并库：

fix

这样做是将*解析为其提交（git merge-base master fix 的提示），将master解析为其提交（master的提示），然后遍历找到合并基础所需的图表。

（如果有多个合并基础，它会选择一个并打印出来。要查看所有，请添加fix。通常只有一个。

查看合并基础差异的快速方法

假设您希望在合并fix和--all时看到git merge将要合并的更改。你可以这样做：

master

但side有一种内置的方法可以自动找到合并基础，使用三个点来分隔分支名称：

$ git merge-base --all master fix
face0ff1234567...                   # some big ugly hash
$ git diff face0ff master           # see what we changed
$ git diff face0ff fix              # see what they changed

这取决于合并基础搜索过程是对称的事实：git diff和$ git diff fix...master # see what we did $ git diff master...fix # see what they did 的合并基础是相同的提交，作为{{的合并基础1}}和master。所以无论我们以哪种方式翻转双方，我们都得到相同的基础。然后Git将该基数与此fix或fix表达式的 right 上指定的提交进行比较。

值得注意的是，此master语法也适用于fix...master。但在这种情况下，它意味着与master...fix不同的东西。通常A...B表示：查找从git log可到达的每个提交，并且每个提交都可以从git diff到达，然后从两者 {中删除每个提交{1}} 和 A...B。也就是说，这会产生对称差异（在集理论术语中）。但是A只能查看两个提交，而不是整个集合;所以它窃取这种语法意味着不同的东西，这对B有用。

答案 1 :(得分：0)

根据您的git diff输出，可以在master分支中合并updateCards。两个分支（+ for updateCards and – for master）比较的文件如下：

updateCards分支更新文件，

update_card_numbers.html

views.py添加update_card_numbers（请求）函数

主分支更新文件，

pdf2_base.html
views.py添加一些新行

实际上，他们修改了不同的地方。您可以合并这两个分支，而不会影响updatedCards分支上的已修复错误以及已合并到master中的新分支。

您可以在真正合并之前执行git merge updateCards --no-commit。它将显示哪些文件存在冲突，然后您可以使用git merge --abort停止。当您运行git merge updateCards时，会有冲突文件，只保存您要保留的内容，然后对每个冲突文件和git add filename使用git commit。

相关问题
最新问题