我想推送我的本地文件,并将它们放在远程仓库上,而不必处理合并冲突.我只是希望我的本地版本优先于远程版本.

我怎么能用Git做到这一点？

长话短说...

据我所知,术语"分支"(用Git的说法)可能指的是相关但不同的东西:

1. 提交的非符号引用/指针,
2. 这种参考的名称(例如"主人"),
3. 存储库的提交DAG的子图由这样的引用所指向的提交中可到达的所有提交组成.

但是,我已经看到这个术语过去常常是指三种可能的用法以外的东西(下面有更多细节).在Git上下文中,我的列表中缺少的"分支"一词是否还有其他有效和明确的用法？

更多细节

使用Git大约一年后,我正在为CS学生准备一个简短的教程.我真的想要确定Git术语,以避免任何混淆.

当然,我现在已经使用Git分支了一段时间; 我很习惯使用它们并且发现Git分支模型很棒.但是,我仍然发现术语"分支"有问题且含糊不清,因为它似乎至少引用了两个不同的东西,具体取决于它所使用的上下文...有时甚至在同一个教程/手册中.

用法1:branch =指向提交的指针/引用

Pro Git书(3.1中 - 分支是什么),在显示下图后,

继续将分支定义为

只是一个指向其中一个提交的轻量级可移动指针.

据我所知,这也是Git手册页中"分支"的含义.

我对这个定义非常满意.我认为分支只是指向DAG中特定提交的引用,而分支的"提示提交"是该引用指向的提交.到现在为止还挺好.可是等等...

用法2:branch = DAG的子图

该Atlassian的Git的教程介绍分支如下:

分支代表独立的发展路线.

我猜他们的意思是一串提交.让我改进一下这个想法......唯一对我有意义的解释是术语"分支"也可以指存储库的提交DAG的子图,该提交DAG由所考虑的提示提交可到达的所有提交组成.

但是,Pro Git书籍也包含以下图表(参见3.4 - 分支工作流程),

这似乎与我的解释相矛盾,因为它似乎暗示只有提交C2- C5(不C1)属于develop分支,并且只提交C6- C7(不是C1- C5)属于topic分支.

我发现这种用法含糊不清,因为如果我在那个阶段绘制DAG,而不知道分支引用在过去指向的位置,并且没有任何假设三个分支之间的任何层次结构,我会得到的是

我还发现其他Git学习资源中的一些图表令人困惑.特别考虑以下内容(取自Lynda.com的介绍视频- Git Essential Training):

这里,尖端master是实际 534de(和HEAD指向master),但图中的"主"标签的位置是非常误导.在这种情况下,该标签应该描述的是我不清楚的......

编辑:我已经 …

阅读git rebase和git merge-base人文档:

在使用git checkout -b topic origin/master创建的主题分支之后,远程跟踪分支origin/master的历史记录可能已经倒带和重建,从而导致了这种形状的历史记录:

                        o---B1
                       /
       ---o---o---B2--o---o---o---B (origin/master)
               \
                B3
                 \
                  Derived (topic)

Run Code Online (Sandbox Code Playgroud)

origin/master用于指向提交B3,B2,B1,现在它指向B,当origin/master位于B3时,您的主题分支在它上面启动.此模式使用origin/master的reflog来查找B3作为分叉点,以便可以通过以下方式在更新的origin/master之上重新定位主题:

$ fork_point=$(git merge-base --fork-point origin/master topic)
$ git rebase --onto origin/master $fork_point topic

Run Code Online (Sandbox Code Playgroud)

$fork_point将(如果我理解正确的话)是提交对象B3,因此提交B3..topic将被重新绑定到origin/master分支.

Q1为什么省略B3提交有用？topic分支的提交建立在B3提交之上,因此省略它意味着它的修改将在origin/master分支的故事中丢失.衍合的B3提交与该topic分支会导致一个更清洁的历史,是不是？

Q2有人可以链接/简要描述--fork-pointgit工作流中该选项的实际用例吗？

我遇到了一个我不理解结果的场景。

我的团队正在开发一个带有提交的功能分支：

A--B--C

一位同事推送了两个新提交：

A--B--C--D--E

我，没有意识到其他人正在将代码推送到这个分支，我强制推送了一个修改后的提交：

A--B--C'

在我意识到我的错误后，我建议他尝试（在他的仓库中，D 和 E 仍然存在）：

git pull -r
git push

我的想法是他的两次提交（D，E）不再出现​​在分支的历史记录中，因此，在 pull 时，git 会尝试将它们合并到历史记录中。我的期望是 D 和 E 会在 C' 之上重新建立，但这并没有发生。相反（释义）：

$ git pull -r
+ commit...commit branch -> origin/branch (forced update)
$ git push
Everything up-to-date

D和E不见了。我想也许他对他的 repo 做了一些其他的操作，所以它可能处于某种未知状态，所以我们在 reflog 中找到了 E 的哈希值，并做git reset --hard <E>了几次再试（主要是因为我很好奇为什么它没有像我预期的那样消失）并得到相同的结果。

我确定我误解了一些东西，但我不确定是什么。为什么不将git pull -r“新”提交 D 和 E（即我无意中从历史记录中删除的那些）重新设置在 C' 之上？

正如一些人指出的那样：C 也应该包含在我的期望中。我没有考虑那个，但我明白为什么，这是有道理的。

我的期望是“新”提交（现在更新为 C、D、E；即使它有效，也不会是我想要的）会被重新定位，但它们不是，我不明白为什么。

@matt 关于之前推送的提交的评论很有趣。如果有人可以详细说明该机制，这似乎是一个潜在的答案。

我正在努力更好地理解git-rebase背后的魔力.今天我对以下行为感到非常惊喜,我没想到.

TLDR:我重新设置了一个共享分支,导致所有提交sha1都发生了变化.尽管如此,派生分支能够准确地识别出其原始提交被"别名"为具有不同sha1的新提交.rebase并没有造成任何混乱.

细节

拿一个主分支: M1

将它分支到branch-X,添加一些额外的提交:M1-A1-B1-C1.记下git-log输出.

将branch-X分支到branch-Y,添加了一个额外的提交:M1-A1-B1-C1-D1.记下git-log输出.

将新提交添加到主分支的提示: M1-M2

将branch-X重新引导到更新后的master : M1-M2-A2-B2-C2. 请注意,A2-B2-C2都具有与A1-B1-C1相同的消息,内容和作者日期.但是,它们具有完全不同的sha1值以及提交日期.根据这篇文章,SHA1不同的原因是因为提交的父级已经改变.

将branch-Y重新引导到更新的分支-X上.结果:M1-M2-A2-B2-C2-D2.

值得注意的是,仅应用D1提交(并且变为D2).分支-Y中的A1-B1-C1提交被git-rebase完全忽略.您可以在输出日志中看到这一点.

这很棒,但git-rebase如何知道忽略A1-B1-C1？git-rebase如何知道A2-B2-C2与A1-B1-C1相同,因此可以安全地忽略？我一直认为git使用sha1标识符跟踪提交,但是尽管上面的提交有不同的sha1s,git仍然知道它们是链接在一起的.它是如何做到的？鉴于上述行为,何时修改共享分支真的很危险？

使用git 2.11,git rebase文档说:

如果提供了--onto选项,则当前分支将重置为<upstream>或<newbase>.这与git reset --hard(或)具有完全相同的效果.ORIG_HEAD设置为在重置之前指向分支的尖端.

我理解它upstream并且newbase指向相同的"基本引用",这意味着下面的两个rebase语法是等价的:

git rebase ABC
git rebase --onto ABC

这是我设置的演示.让我们假设当前分支是FeatureABC与远程分支完全同步.

#---create two identical branches, behind current branch by 5 commits
(FeatureABC) git branch Demo1-Rebase-ABC      HEAD~4
(FeatureABC) git branch Demo2-Rebase-onto-ABC HEAD~4

#---Make a new commit in branch Demo1
git checkout Demo1-Rebase-ABC
echo "Demo of: git rebase FeatureABC Demo1-Rebase-ABC" > ./Demo1_BogusFile.txt
git add ./Demo1_BogusFile.txt
git commit -m "Create file Demo1_BogusFile.txt"

git rebase FeatureABC

首先,倒带头重播你的工作
...应用:创建文件Demo1_BogusFile.txt

git log --oneline -3 …