在我提问之前，我想知道我对某些Git概念的理解是否正确，请随时纠正我：
以下是我的问题：
当git命令（任何可以向分支添加提交的git命令）将新提交添加到分支时，
问题：
git命令总是将分支名称向前移动到指向 新提交？
或者是否有git命令，它们将新的提交添加到分支中 不要移动分支名称，因此需要我运行一些 移动它的附加git命令？
何时
问题：
是否有必要另外更新HEAD？
我的猜测不是，因为HEAD已经指出当前分支的名称， 当前分支的名称已经更新为指向新的 提示当前分支的提交，并移动当前分支 name并没有改变HEAD指向当前的事实 分支机构的名称。因此，如果没有对HEAD进行额外更改，一切看起来都很好。
工作目录是否已更新为与分支的新提示提交相同？
或者可以工作目录 仍然与分支的上一个提示提交相同，并且在 为了检查当前分支的新提示提交到 工作目录，我需要运行一些额外的git命令吗？
以下是具体git命令（git push和git pull）的两个案例/示例，这让我想到并提出上述两个部分＆＃39; 任意git命令的问题，可以将提交添加到分支或当前分支：
git push 将新提交添加到远程分支上
库。
现在假设
问题：
在远程存储库中，git push是否将分支名称移动到指向新的提示提交？
或者远程存储库的用户是否必须运行一些额外的git命令来移动它？
在远程存储库中，git push是否将工作目录更新为与新提示提交相同？
即。在远程存储库中，是当前分支的更新版本（git
push）（＆＃34;当前＆＃34;在git push之前）仍然是
git push之后的当前分支？ （注意当前的定义
我在帖子开头给出的分支：＆＃34;当前分支是
定义为检出工作目录的分支。＆＃34;）
我的猜测不是，如果我从版本控制中正确理解的话 Geli by Loeliger 2ed说：
回想一下，git push命令不会检出文件中的文件 接收存储库。它只是从源传输对象 存储库到接收存储库，然后更新 接收端的相应引用。
在裸存储库中，这种行为是可以预期的， 因为没有可以更新的工作目录 签出文件。非常好。但是，在一个发展中 作为推送操作的接收者的存储库，稍后可以 对使用开发存储库的任何人造成混淆。
推送操作可以更新存储库状态，包括HEAD 承诺。也就是说，即使远程端的开发人员已经完成了 什么都没有，分支引用和HEAD可能会改变，变得不同步 带有签出的文件和索引。
正积极在存储库中工作的开发人员 异步推送发生不会看到推动。但随后 该开发人员的提交将发生在意外的HEAD上，创建一个 奇怪的历史。强制推送将失去对方的推送提交 开发商。该存储库中的开发人员也可能找到自己 无法将她的历史记录与上游存储库或 下游克隆因为它们不再像前面那样简单快速 他们应该是。她不会知道原因：存储库已经默默无闻 从她的下面变了出来。猫和狗将一起生活。 这会很糟糕。
在 git pull 命令中，合并步骤将新获取的远程跟踪分支合并到当前分支中。如果我是正确的，git pull的合并步骤也会使分支的banch名称前进到指向分支上的新顶级提交。
问题：
在本地存储库中，git pull是否将工作目录更新为与新提取的提示提交相同？
即。在本地存储库中，当前分支的更新版本（git pull）（＆＃34;当前＆＃34;在git pull之前）仍然是git pull之后的当前分支？ （注意我在帖子开头给出的当前分支的定义：＆＃34;当前分支被定义为签出到工作目录的分支。＆＃34;）
我在Does git pull check out the current branch after its merge/rebase step?询问了git pull的问题。
根据我的理解，Joseph的回复意味着git pull将新提取的提示检出到本地存储库的工作目录中，并且我不需要运行其他git命令来检查它出。
torek的回复很棒，但在我理解之前会有一段时间。
答案 0 :(得分：3)
<强> 1。 git命令是否始终将分支名称向前移动以指向新提交？
是的，无论何时在分支中进行提交，都会将其移动到最新的提交。
<强> 2。是否有必要另外更新HEAD？
否{1998}引用当前分支顶端的提交，如果您要对此签出分支提交新更改，则HEAD再次指向最新提交。
第3。工作目录是否已更新为与分支的新提示提交相同？
是的，当您执行新提交时，工作目录会更新，如果在HEAD中提交新的更改后，您将结帐到较旧的branch A，则工作目录指向较旧的分支B有自己的最新提交。
<强> 4。在远程存储库中，branch B是否将分支名称移动到指向新的提示？
是的，如果我们从我们的本地存储库git push执行git push到也有一个指向branch A的工作目录的远程存储库，它会将其移动到最新的提交。用户无需运行任何其他命令。
如果您将代码从branch A（本地存储库）推送到具有branch B工作存储库的branch B（远程存储库），它会将branch A移动到最新提交，但工作目录仍指向远程存储库中的branch B。它只更新你推送新提交的分支的代码，没有结账。
<强> 5。在本地存储库中，branch A是否将新提取的提示提交到工作目录中？
没有git pull不会检查新提取的提示提交，它会将远程分支提交合并到工作目录中的当前分支。
您可以将代码从git pull提取到branch B，将branch A提交合并到branch B提交，但它不会将当前分支更改为B.
<强> 6。当前分支的更新版本（branch A）（＆＃34;当前＆＃34;在git pull之前）仍然是git pull之后的当前分支吗？
是的，即使在git pull之后，当前分支仍然保持不变，如上所述，因为它只是合并了提交。
答案 1 :(得分：2)
您对Git的理解存在一些问题我将尝试清理：
首先，提交不会添加到分支。提交是在存储库中创建的，通常指向父级，然后可以更新分支以指向新的提交。
git命令是否总是将分支名称向前移动以指向新提交？
有一些方法可以在不影响任何分支的情况下创建提交;如果您使用的是分离的HEAD，则在提交后也没有更新任何分支。
除非你是一个独立的HEAD（Git会在你输入它时警告你），你不必过于担心以后必须手动更新分支。用于创建（或重新创建）提交的常用命令是git commit，git merge和git rebase（除了从其他地方获取现有提交之外），它们都会影响当前分支
是否有必要另外更新HEAD？
同样，除非您处于分离的HEAD，否则HEAD将始终是另一个分支或引用的相对引用。所以一旦更新，HEAD也会隐式更新。如果你是一个独立的HEAD，那么Git会在你创建提交时直接更新HEAD。
工作目录是否已更新为与分支的新提示提交相同？
工作目录与提交或分支完全分开。是的，当您git checkout切换分支或其他直接影响工作目录的提交时，工作目录将更新，但特别是提交将不会修改工作目录。通常，您将工作目录中的更改添加到索引，然后从索引创建提交。所以工作目录保持在你提交之前留下的任何状态。从理论上讲，工作目录可能与您刚刚提交的内容完全不同。
git push将新提交添加到远程存储库上的分支。
不，git push将与远程目录通信，然后将现有的提交传输给它。
在远程存储库中，git push是否将分支名称移动到指向新的提示？
当您推送到远程存储库的签出分支时，通常会收到警告，Git将不允许您这样做。但Git永远不会更新远程存储库的工作目录;它不能那样做。你只能通过在远程存储库本身上运行的钩子来做到这一点。
更好的做法是推送到裸存储库，然后有一个钩子，用工作目录（在同一台机器上）更新另一个存储库。
如果我是正确的，git pull的合并步骤也会将分支的banch名称提升为指向分支上的新顶级提交。
合并更新分支，是的。
在本地存储库中，git是否会将新提取的提示提交检出到工作目录中？
Git会尝试这样做，但如果由于未经修改的更改而发现冲突，它将不会这样做并在签出任何内容之前中止。