如何使用由2个或更多用户更新的Git提取文件

Question

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

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

Answer 1

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

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

要保存未提交的文件，您可以执行以下操作：先使用jQuery('body').on('change','#ClasificarIvaToggle',function(){ if(jQuery(this).is(":checked")) { jQuery(this).parents("#ToggleClasificarIVA").find("#CodigoActividadDropdown").show(); } else { jQuery(this).parents("#ToggleClasificarIVA").find("#CodigoActividadDropdown").hide(); } }); 命令，然后依次使用git stash和git pull。如果您的内容有任何冲突，现在有机会对其进行编辑：）

有关隐藏的更多信息，请参见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 有关。

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

要记住的事情是：Git存储 commits ，并且每个commits存储每个文件。一旦您（或任何人）进行了提交，关于该提交的任何内容都将无法更改。因此，只要您仍进行任何一项特定的提交，就如同您进行一次提交时一样，您仍然拥有文件的全部。所有提交始终都是100％完全只读。大多数提交会永久保留在您的存储库中。

（摆脱提交有点困难，但绝对不是不可能。不必担心“坏”的提交会占用很多空间。每个冻结的快照都是永久性的文件被压缩（通常是高度压缩），因此通常比原始文件和占用更少的空间，因为它们被永久冻结，Git可以并且确实重复使用它们是自动进行的。也就是说，假设您连续进行100次提交，每次仅更改一个文件。每次可以是同一文件，也可以每次不同。如果您愿意，可以来回更改它-假设这100个提交中的每个文件中有500个文件，由于您的 next 提交中只有一个文件不同，因此它会重用上一次提交的499个文件！ ，如果您更改文件 back ，则新文件与旧提交中的旧副本相同，并且Git会自动重新使用旧副本。）

每个提交都有一个丑陋的哈希ID，该ID对于该特定提交是唯一的。该哈希ID的魔力在于，不仅 that 提交是唯一的，而且宇宙中的每个Git 都会同意 that 提交获取 that 哈希ID。 ¹ 因此，两个Git可以很容易地说出它们是否具有相同的提交：它们只是查看彼此的哈希ID。 （实际上，获取提交也需要获取您没有的任何文件，但是可以快速检查是否已经拥有。）

请记住，这是答案：

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

• git fetch命令让您的Git调用其他人的Git，并询问他们是否有Git应该获得的提交。他们给您这些提交，现在您有了他们的提交 plus 他们的提交。这对您的任何提交均不执行任何操作，因此始终完全安全。

• git merge命令不太安全，但是非常安全！首先检查以确保您已完成您的工作。如果不是，它将抱怨并让您提交它。一旦拥有，所有全部的文件（从提交它们时的状态开始）都将在新文件中永久冻结提交。

• git merge操作通过查找更改来起作用。您和您的朋友/同事从一些 common 提交开始-某些提交具有相同的哈希ID，您和他们之前通过共享获得了该哈希ID。然后，您对某些文件进行了一些更改，并创建了一个新快照，以永久保存新更改（以整个文件的形式），并且他们也进行了一些更改并创建了一个新快照，以保存它们的更改。永远改变。合并将您开始的合并基础提交与您自己的最新提交进行比较，并分别与他的最新提交进行比较。

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

如果您和他们更改了相同文件的相同行，您将得到Git所说的合并冲突。在这种情况下，Git会让您一团糟，您必须手动进行清理，也许借助 merge工具进行清理。但是，如果Git认为自己能够合并您的更改，则Git会继续并提交生成的合并更改快照，作为 merge commit 。该合并提交会记住您自己的前一个提交和的最后一个提交的哈希ID，以便Git知道执行合并的是哪两个提交，并可以向您显示合并产生的历史记录。

某些人可能会建议您在git stash之前使用git pull，而不要自己提交。您可以执行此操作，但我不建议这样做。原因很简单：git stash push ² 所做的只是进行一些不在 any 分支上的提交。这使git pull更加容易，因为现在git pull进行获取并合并步骤时，您没有合并的提交，而是使用分支-但是之后，您需要使用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新手时，建议您避免使用它

---

¹ 从技术上讲，只要您从未将这两个Git存储库彼此引入，两个不同的Git存储库就可以重新使用哈希ID。有关更多信息，请参见How does the newly found SHA-1 collision affect Git?

² 在旧版本的Git中，现在拼写为git stash push的内容是git stash save。新的拼写push修复了选项中的一些小问题，并允许了一些新功能，还有助于解释为什么pop与push相对。我对git stash pop的问题-除了我一开始就非常反对使用git stash的总体异议外，?是-如果 Git 认为Git会降低存储量应用步骤进展顺利。有时，即使Git认为很好，应用步骤也很糟糕，或者您应用了错误的存储，不放弃存储会很好。

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

Answer 4

** You can manage this by different ways such as **

1. 通过创建一个公共分支，每个人都可以推送更新，接下来，您应该在开始工作和合并文件之前每次都拉动该分支

2. ，您通常可以获取文件并与包含最新更新的底部分支（底部分支名称是最后更新的分支）合并