"git commit"和"git push"有什么区别？

Question

在我正在经历的Git教程中,git commit用于存储您所做的更改.

什么git push用于那么？

Answer 1

基本上git commit" 记录对存储库的更改 ",同时git push" 更新远程引用以及关联对象 ".因此,第一个用于与本地存储库连接,而后一个用于与远程存储库交互.

这是来自Oliver Steele的精彩图片,它解释了git模型和命令:

了解更多关于git push和git pull对GitReady.com(我称之为第一的文章)

Answer 2

commit:向本地存储库添加更改

push:将最后一次提交传输到远程服务器

Answer 3

好吧,基本上git commit会将您的更改放入您的本地仓库,而git push会将您的更改发送到远程位置.

Answer 4

git push用于将您在本地存储库上完成的提交添加到远程存储库中 - git pull它允许人们进行协作.

Answer 5

由于git是一个分布式版本控制系统,不同之处在于commit会将更改提交到本地存储库,而push会将更改推送到远程repo.

Answer 6

提交:{快照| 变更集| 历史记录| 版本| 存储库的"另存为"}.的Git仓库=系列(树)提交(加上一些额外的东西).

本地存储库:计算机上的存储库.

远程存储库:服务器上的存储库(例如Github.com).

git commit:将新提交(最后提交 + 分阶段修改)添加到本地存储库.

/.git,git push:将本地存储库与其关联的 远程存储库同步.git pull- 将更改从本地应用到远程,push- 将更改从远程应用到本地.

Answer 7

git commit将更改记录到本地存储库.

git push 更新的远程与本地更改存储库.

Answer 8

需要注意的三件事：

1）工作目录 -----包含我们的代码文件的文件夹

2）本地存储库 ------这在我们的系统内部。当我们第一次执行COMMIT命令时，将创建此本地存储库。在工作目录所在的位置，
创建Checkit（.git）文件。
之后，一旦我们提交，它将把我们在工作目录文件中所做的更改存储到本地存储库（.git）

3）远程存储库 -----它位于我们系统的外部，就像在世界上任何地方的服务器上一样。像github。当我们执行PUSH命令时，本地存储库中的代码将存储到此远程存储库中

Answer 9

Git 工作原理的常识性解释

我已经使用 Git 多年了，但奇怪的是，这里或网上似乎没有人能够用简单的术语解释Git push、pull、commit、 或 是pull requests如何工作的。那么，下面就简单的解释一下。我希望它能更清楚地解释事情。它帮助了我！

Git 工作原理的简单总结

在 Git 中，您总是先在本地计算机上创建代码，然后将代码保存到计算机上 Git 的“本地存储库”(repo) 中。完成后，您可以将更改上传到 Git 的共享“远程存储库”，以便其他人可以访问您的代码更改。您还可以将更改从“远程存储库”下载到“本地存储库”，以便您的代码与其他开发人员的更改保持同步。然后你重新开始这个过程。

通过这种方式，Git 允许您与其他人远程共享本地项目代码，同时保存这些代码更改的版本，以防出现问题而您必须重做一些错误的代码。这就是 Git 工作原理及其使用周期的简单解释。

更多 Git 详细信息

第一步始终是在本地计算机上编写代码，忽略不以任何方式参与保存或测试代码的 Git。当您将本地代码保存在计算机上时，它不会像您想象的那样默认保存在 Git 中。您必须执行称为“提交”的第二步。（顺便说一句，尚未提交的已保存代码称为“暂存”代码。）

A与保存本地代码更改相同，但保存在“Git world”commit中。这让人们感到困惑。但当我看到“commit”这个词时，我将其视为“Git Save”。这是一个额外的步骤，因为您已经保存了一次代码更改，现在必须将它们作为提交第二次保存在 Git 系统中，否则它们不会成为本地 Git 存储库系统的一部分。我认为“提交”是一些人认为Git 设计不佳的原因之一。它只是不直观。

Apush在您完成所有代码保存并将代码提交到本地 Git 存储库后完成。Push 命令将本地存储库更改（仅提交）发送到远程存储库，以便更新它。当它执行此操作时，它会将 100% 的更改完全写入远程存储库，以便两者保持同步，或者两者之间的代码 100% 匹配。将此视为“远程 Git 保存”。它会用您计算机上本地的代码覆盖远程存储库上的代码。起初这对我来说毫无意义。这不会删除远程其他开发人员所做的更改吗？如果远程与您的更改冲突或者您在本地存储库中没有首先需要的远程更改，该怎么办？一开始这让我很困惑，因为没有人能在网上解释这是否与“合并”、“提交”、“拉取请求”等相同。事实证明，这只在一种条件下有效。否则它会阻止你的推动并失败！

仅当您是唯一更改远程存储库的人并且除了您在本地添加的提交之外，两个代码库相同时，“推送”才有效。否则，其他用户在该遥控器上所做的任何更改都将取消您的推送。因此，可以将其视为push与本地代表相同的副本的“私有远程重写”。但我们知道许多开发人员会像您一样通过推送将更改推送到远程副本，对吧？因此，在这种设计下，推送将会失败，并且每个人的本地副本与远程副本都会不断不同步。

正如我所提到的，只有在进行更改之前远程存储库处于与本地存储库完全相同的状态时，才允许此推送（不会在远程存储库上被阻止）。换句话说，只有当您推送提交本地更改时，push如果远程存储库尚未被任何其他开发人员修改，您只能将本地更改推送到远程项目并完全覆盖它。这是 Git 令人困惑的一个奇怪的方面。如果您的本地代码副本由于已更改而以任何方式与远程存储库不同步，则推送将失败，您将被迫执行或pull“rebase”，这是“更新本地存储库”的一个花哨词首先使用远程复制”。如果您的推送被阻止，然后您执行 a pull，它会复制远程代码并将其代码更改“合并”到您的本地副本中。再次同步后，您仍然可以通过推送来推送提交，因为它们在拉取或合并后应该仍然存在。

这在大多数情况下都可以完美工作，除非代码更改与您在同一代码区域中对其他开发人员所做的提交或代码更改发生冲突。在这种罕见的情况下，您必须先在本地解决冲突，然后才能继续执行其他操作，因为您可能会意外删除其他开发人员对您自己的更改。这就是pull requests（见下文）比推送更有帮助的地方，因为前者强制代码所有者或管理员首先在远程副本上手动解决主要代码更改，然后才允许任何代码更改远程存储库。

有趣的是，“拉”与“推”的作用相同，但在这种情况下，会将最新远程项目的副本拉到本地 git 系统，然后将这些更改“合并”到您自己的副本中，而不是像“推”可以。当然，这会再次同步您的远程和本地副本，减去您设置为再次使用“推送”在远程存储库上更新的新提交。

一旦您通过 a 将本地副本同步到远程副本pull，您现在可以执行 apush并将您的commits更改再次发送回远程副本，并安全地覆盖它，因为您知道您已将您的更改与所有其他人所做的更改合并开发商。

push使用本地副本的提交或更改写入远程副本后，远程副本将与本地副本完全匹配。因为它们都匹配，所以您在本地进行的任何额外提交或保存都可以再次远程推送，而无需拉取 - 只要没有开发人员像您一样更改了远程。如果是这种情况，Git 将始终在推送时提醒您。你不能搞砸了。您可以执行“强制”推送、“变基”和其他技巧，但这并不重要。但是，一旦其他开发人员推送他们的更改，您就会再次失去同步，并且必须在推送之前先再次拉取。

这种提交-拉-推是 Git 开发的真正节奏，没有人告诉你并假设你理解。大多数没有。它只是不直观或不符合逻辑。

当然，您可以“强制”推送并重写所有内容。但在您尝试之前该系统会提醒您。当一名开发人员更新他们拥有的一个远程存储库中的一个分支时，这种拉取和推送系统总是效果更好。一旦有新人添加或更改遥控器中的任何内容，它就会失败。这就是导致推送和拉取警报和失败的原因，直到每个人再次与遥控器同步。完成后，开发人员有权推送更改，因为他们的代码再次与遥控器匹配。pull request但是，当分支和代码有大量更改或合并到远程存储库时，最好使用 Git命令。

最后，值得注意的是，在对软件进行更改之前，几乎总是鼓励使用 Git 进行开发的人员首先创建新的本地和远程存储库分支。在这种情况下，push和pull就非常有意义，因为代码更改几乎总是由单个开发人员在软件的独立分支上完成，而不会与其他开发人员的更改发生冲突。这就解释了为什么一名开发人员在自己的分支上工作是很常见的，在这种情况下，并且push工作pull完美，可以快速推送/拉取更改，永远不会导致代码冲突，并允许一名开发人员存储其最终本地更改的副本在远程仓库分支上，他使用pull request下面描述的系统推动稍后合并到主分支中。

奇怪的拉取请求

Git 谜题的最后一部分。从远程存储库将本地存储库代码拉入其中的角度来看， Apull request是“拉” 。但这是一个请求，最初不会物理地提取任何内容或更改任何内容，也不会推送或合并任何代码。这只是您从本地存储库发送到远程存储库以审查代码的请求，如果他们批准，请将您的代码拉入他们的远程副本。

在 a 中pull request，您要求远程存储库管理员或所有者上传您的代码更改或提交，检查您的本地存储库提交更改，然后在获得批准后将您的代码更改合并到远程存储库中。当他们批准您审阅的本地存储库提交或更改时，他们会拉取您的本地存储库代码或分支并将其合并到远程存储库分支中。

远程存储库的管理员或所有者控制远程存储库中正在准备生产的关键顶级代码分支。他们不喜欢在不对代码质量进行一定控制的情况下将代码更改合并到这些较大的分支中。当您执行此操作时，pull request您将提醒管理员或远程存储库所有者，您作为本地开发人员有一些已完成的代码分支，并希望他们手动将本地存储库代码拉入远程存储库代码。这与从本地到远程存储库相同push，但在这种情况下需要由顶级远程存储库所有者从相反的方向完成。它还需要首先进行手动代码审查并批准远程存储库所有者的更改。

注意：在两个远程存储库分支之间合并代码更为常见pull request，并且通常会影响远程服务器或设备上必须合并到主远程分支中的已完成代码分支，而不仅仅是本地提交更改。再说一次，不直观，但你就知道了！

如果您有同步和合并代码的 Git 命令，为什么还需要拉取push请求pull？pull requests在很多人正在拉动和推送巨大更改到已完成的分支并合并到主要远程存储库分支的情况下，比推送效果更好，并且大量代码可能会发生冲突，或者添加的代码必须先进行测试或代码审查，然后才能进行主要版本或代码库更新。Push对于只有一两个开发人员正在工作和共享的孤立的较小分支，“拉”效果更好。pull在本地和远程存储库之间进行push编码比将复杂的远程存储库更改的大量分支合并到远程存储库的主分支中要容易得多。

所以记住...

使用“推送”更新您本地和远程控制的小型分支。

使用“拉取请求”让远程存储库人员将较小的分支合并到远程服务器上较大的分支中。

所以我喜欢将其视为pull requests主推送和本地push推送。我希望 Git 人员能够为这些进程起一个更符合逻辑、更容易理解的名称。它根本不直观！

事实证明，这pull request也是添加一层代码安全性的一种方法，在将大量代码合并到关键的顶级远程分支或合并项目中的分支时，首先需要获得管理员或团队成员的许可。因此，它要求团队成员批准大批量的本地存储库代码更改并首先提交，然后再将其拉入重要的远程存储库分支。

这可以首先通过代码审查和批准来保护关键分支的代码更新。但它也允许许多团队更新远程存储库，以在测试、批准等之前暂停更重要分支上的代码更改和合并。这就是为什么开发人员私有的小代码分支只是简单地拉动和推送更改，但这些分支的较大合并通常会被拉取请求阻止推送。这是更典型的使用推送完成的分支，然后将其合并到 Git 树上的更大分支。

即使我已经使用 Git 多年，也要花上好几个小时的研究才能弄清楚这一点，因为网上没有文档解释这种差异。

所以......在处理您自己的代码更改或分配给您的项目部分时，请始终使用提交-拉动-推送例程。首先拉下存储库，以确保您的本地存储库具有其他开发人员对其所做的所有最新更改。如果您愿意，可以在拉取之前和之后提交或保存所有本地更改...这并不重要。如果存在冲突，请尝试在本地解决。然后，只有到那时，才可以使用本地代码进行推送以覆盖远程副本。然后，您的本地和远程存储库在Git 世界中 100% 同步！

最后，当您的本地和远程分支完成后，向您的 git 管理员发送拉取请求，并让他们处理已完成的远程存储库分支的合并。

Answer 10

只想添加以下几点:

在您提交之前,Yon无法推送,因为我们使用git push将本地分支上的提交推送到远程存储库.

该git push命令有两个参数:

远程名称,例如,origin 分支名称,例如,master

例如:

git push  <REMOTENAME> <BRANCHNAME> 
git push  origin       master

Answer 11

一个非常粗略的类比：如果我们将其git commit与保存编辑过的文件进行比较，那么git push就是将该文件复制到另一个位置。

请不要将这个类比脱离上下文——提交和推送并不完全像保存编辑过的文件并复制它。也就是说，为了比较，它应该成立。