例如,我有这样的历史
A -> B -> C -> F -> G ---------- feature
\
D -> E -------- master
在整个历史过程中,我有一个文件a.txt,其中包含第一行,比如"sometext“。在提交G时,我决定删除"sometext“,并保留第一行为空。然后我把这两个分支合并。形成一个新的提交,第一行为空白。因此,E包含"sometext“行,G不包含。因此,这是被合并的分支之间的区别。git如何决定在合并提交中包含哪些内容?是因为G是在E之后制造
我有一个主干道,不久前我从这里分叉出一个开发部门。到目前为止,我一直在开发部门工作。同时,在主分支中添加了较新的提交。现在,我想从main到dev分支进行更改。特别是,我希望在主分支中更新更改的基础上重新设置开发分支中的更改。以下是我所采取的步骤:
git checkout main
git checkout dev
git rebase main
在我完成冲突解决步骤之后,两个分支的提交似乎混合了。它应该如何工作吗?我当时的印象是,主分支的所有更新提交都将位于底部,开发分支的提交将位于它们的顶部。我是不是误会了什么?
这是一个有点学术/深奥的问题,因为我知道用提交散列命名分支不是一个好主意。然而,我很好奇。 似乎如果我在哈希X之后命名一个分支,然后执行git checkout X,git会更喜欢分支名称。幸运的是,它会对此发出警告。 $ git checkout f878084412c04542e297cb5c52b0fb6f6a2b2870
warning: refname 'f878084412c04542e297cb5c52b0fb6f6a2b2870' is ambiguous.
Git normally never creates a ref that ends with 40
我必须设置关键字替换与Git。根据和的建议以及的提示,我用bash编写了一个.git_filters/keywords-smudge.sh和一个.git_filters/keywords-clean.sh作为过滤器:
keywords-smudge.sh
#!/usr/bin/bash
# Replace the keywords after the checkout.
# This script is executed in streaming mode:
# keywords-smudge.sh file.c < file.c
set -e
# Capture the argu