我对Git拉动感到困惑

Question

假设您正在与其他人一起从事项目。你们俩都有项目的更新版本。有一个名为“ example.cpp”的文件。你们两个都同时处理同一个文件，并在本地系统上进行了多项更改。你们其中一位将更改推送到git。现在，当另一方进行更改时，这不会覆盖您在系统上该文件中所做的一切吗？

我基本上一直在制作git目录的另一个副本，并在那里做我的工作，因为我不知道git pull对目前为止我所做的工作会做什么。我需要澄清一下。谢谢。

Answer 1

git pull与远程存储库同步以进行任何更改。

https://guide.freecodecamp.org/miscellaneous/git-pull-vs-git-fetch/

保存未提交文件的操作是先使用git stash命令，然后使用git pull然后使用git stash pop。如果您的内容有任何冲突，现在就有机会对其进行编辑：）

有关隐藏的更多信息，请参见https://git-scm.com/docs/git-stash

Answer 2

因此，您应该合并它。这是正常情况。如果您是git初学者，请使用GitExtensions或SourceTree（对于初学者来说更好）或TortoiseGit之类的东西。

系统将为您解决此冲突。它将打开分成2-3个部分的窗口。您将看到一个分支和另一个分支的更改。对于每次冲突，您都应该选择将哪些代码保存为结果。在最下面的结果文件中。

一些理论，如果您会感兴趣的话。您的分支有2个实例（例如，我将使用分支名称“ master”）：

1. master（您的分支的本地版本）
2. origin \ master（存储在服务中的分支版本）。

如果有人将代码推送到母版，则origin \ master将不同于您的母版，您应该将其合并

但是当两个人在一个分支机构中工作时，这是不好的做法。当您拉分支并开始合并时，您可能会覆盖您的更改（由于缺乏经验）而丢失。

[如果您是初学者，请在单独的分支中工作，并将其推\拉而不合并。并在需要时创建合并提交以掌握。它将使您有可能回滚。如果发生错误，您可以取消更改并将分支重置为服务器版本。

Answer 3

这有点棘手，直到您意识到Git实际上与文件无关。 Git关于commits。

提交存储个文件。在每次提交中，Git都会存储文件的[[all的完整副本。那不是全部提交，文件是其数据，并且提交也包含metadata，例如有关提交者的信息（名称和电子邮件地址），时间（日期和时间戳） ，以及原因（他们提交时写的日志消息）。甚至还有更多，但是我们不会在这个答案中找到。

要记住的事情是：Git存储

commits

，并且每个提交都存储every文件。一旦您（或任何人）进行了提交，关于该提交的任何内容都无法更改。因此，只要您仍然进行任何特定的提交，就仍然具有all个文件，就像它们进行一次提交时一样。所有提交始终都是100％完全只读。大多数提交将永久保留在您的存储库中。（要摆脱提交会有些困难，但绝对不是不可能。不必担心“坏”的提交会占用很多空间。每个文件的冻结快照都是永久冻结的压缩后（通常是高度压缩），因此占用的空间通常比原始文件

和

小得多，因为它们会被永久冻结，因此Git可以并且会自动re-use使用它们。您可以连续进行100次提交，每次仅更改一个文件，每次可以是同一文件，也可以每次不同。您可以根据需要来回更改它-没关系。假设这100个提交中的每个文件中有500个文件，由于您的next提交中只有一个文件不同，因此它会重用上一次提交中的499个文件！ >，新文件与旧提交中的旧副本相同，Git会自动重新使用旧副本。）每个提交都有一个丑陋的哈希ID，该ID对于该特定提交是唯一的。此哈希ID的神奇之处在于，它不仅是that提交唯一的，而且

Universe中的每个Git

都将同意that提交获得that哈希ID 。 1因此，两个Git可以很容易地知道它们是否具有相同的提交：它们只是查看彼此的哈希ID。 （实际上，getting提交也需要获取您没有的任何文件，但是可以快速检查是否已经拥有它。）牢记这一点，这是答案：

首先，我们应该注意：git pull表示
• 运行git fetch，然后（如果可行）运行第二个Git命令，通常是git merge。

git fetch命令让您的Git调用其他人的Git，并要求他们提供Git应该获得的，您没有的任何提交。他们给您这些提交，现在您有了您的提交

plus

他们的提交。这对您的任何提交均不执行任何操作，因此始终完全安全。

git merge命令不太安全，但是非常安全！首先检查以确保您已完成

your

工作。如果不是，它将抱怨并让您提交它。一旦拥有，从提交时的状态开始，所有文件的[[all在所有新提交中都会永久冻结。] >

git merge操作通过查找更改来工作。您和您的朋友/同事从一些common

提交开始-某些提交具有相同的哈希ID，您和他们之前通过共享获得了该哈希ID。然后，您对某些文件进行了一些更改，并创建了一个新快照，该快照以新的整个文件的形式永久保存了更改；

they

也进行了一些更改，并创建了一个永久保存其更改的新快照。合并将

合并基础提交（您俩都开始使用）与您自己的最新提交进行比较，并分别与他的最新提交进行比较。

比较任何两个提交会告诉您在这两个提交中什么是different。因此，现在Git知道您所做的更改以及更改。合并操作combines进行这些更改，并将合并的更改应用于基本版本的快照。

如果您和他们更改了same文件的same

行，您将得到Git所说的

合并冲突

。在这种情况下，Git会让您一团糟，您必须手动进行清理，也许借助merge tool进行清理。但是，如果Git认为自己能够合并您的更改，则Git将继续并提交生成的合并更改快照，作为merge commit。该合并提交会记住您自己的前一个提交的最后一个提交的哈希ID，以便Git知道执行合并的是哪两个提交，并可以向您显示结果的两个“分支”从此合并。某些人可能建议您在git stash之前使用git pull，而不要自己提交。您可以执行此操作，但是我不建议这样做。原因很简单：git stash push 2所做的只是进行一些不在[[any分支上的提交。这使git pull变得更容易，因为现在git pull进行获取并合并步骤时，您没有合并的提交了-它使用branch上的提交进行合并-但随后您将需要使用git stash apply或git stash pop来进行隐藏。

您可能会忘记立即执行此操作，并先进行一些尚未提交的更改，然后记住git stash apply / git stash pop步骤。此操作使用git stash push的提交来运行git merge的更不安全得多版本。如果这里的情况很糟，那么很难恢复您更改但未提交的内容。因此，通过使用git stash，您只是推迟了仍然需要执行的合并。

一旦您了解很多有关合并和其他Git操作的知识，您可以更安全地使用git stash push，git stash apply和git stash drop，但是当您是Git新手时，我建议您避免使用它。1从技术上讲，只要您从未将这两个Git存储库彼此引入，两个不同的Git存储库就可以重新使用哈希ID。有关更多信息，请参见How does the newly found SHA-1 collision affect Git?

2

现在的拼写为git stash push在旧版本的Git中拼写为git stash save。新的拼写push修复了选项中的一些小问题，并允许了一些新功能，还有助于解释为什么pop与push相对。我对git stash pop所遇到的问题（好吧，除了我总体上反对首先使用git stash的总体异议外），如果

Git

认为应用步骤进展顺利，Git将会放弃藏匿处。有时候，即使Git认为很好，应用步骤也很糟糕，或者您应用了错误的存储，并且

---

not删除存储会很好。

（（如果您藏匿很多藏匿处，您会发现有时很难区分它们。过了一会儿，您不知道出于什么原因而保留了哪些藏匿物。诚然commits can have the same problem，但至少在这里，您有更多的机会稍后再解决。）