如果您想象在GitHub的存储库中维护一个日志文件，那么就更容易理解Git命令add和commit的使用。

对于我来说，一个典型的项目日志文件可能是这样的:

---------------- Day 1 --------------------
Message: Completed Task A
Index of files changed: File1, File2

Message: Completed Task B
Index of files changed: File2, File3
-------------------------------------------

---------------- Day 2 --------------------
Message: Corrected typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on

我的一天通常以git pull请求开始，以git push请求结束。所以一天记录里的每件事都与他们之间发生的事情相对应。每天，我都要完成一个或多个逻辑任务，这些任务需要修改一些文件。在该任务期间编辑的文件列在一个索引中。

每个子任务(这里的任务A和任务B)都是单独的提交。git add命令将文件添加到“已更改文件索引”列表中。这个过程也称为暂存，在现实中记录更改的文件和执行的更改。git commit命令记录/完成更改和相应的索引列表，以及一个自定义消息，以供以后引用。

请记住，您仍然只更改存储库的本地副本，而不是GitHub上的副本。在此之后，只有当你执行git推送时，才能将所有这些记录的更改以及每次提交的索引文件记录到主存储库(GitHub)上。

作为一个例子，为了获得那个虚构日志文件中的第二个条目，我将做:

git pull

# Make changes to File3 and File4
git add File3 File4

# Verify changes, run tests etc..
git commit -m 'Corrected typos'
git push

简而言之，git add和git commit让您可以将对主存储库的更改分解为系统的逻辑子更改。正如其他的回答和评论所指出的，它们当然还有更多的用途。然而，这是最常见的用法之一，也是Git作为多阶段修订控制系统的驱动原则，而不像其他流行的版本控制系统(如SVN)。

Git push用于将您在本地存储库上完成的提交添加到远程存储库中。与git一起，它允许人们进行协作。

基本上，Git commit会把你的更改放到本地存储库中，而Git push会把你的更改发送到远程位置。

Git如何工作的常识解释

我已经使用Git很多年了，但奇怪的是，这里或网上似乎没有人能用简单的术语解释Git的推送、拉取、提交或拉取请求是如何工作的。所以，下面是一个简单的解释。我希望它能更清楚地解释事情。它帮助了我!

git如何工作的简单总结

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

通过这种方式，Git允许您与他人远程共享本地项目代码，同时保存这些代码更改的版本，以防出现问题，不得不重做一些糟糕的代码。这是对Git如何工作以及如何使用它的周期的简单解释。

更多git细节

第一步总是在您的本地计算机上编写代码，忽略Git，因为它不会以任何方式保存或测试代码。当您在计算机上保存本地代码时，默认情况下它并不像您想象的那样保存在Git中。你必须做第二步，称为“提交”。(顺便说一下，尚未提交的保存代码称为“阶段性”代码。)

提交和保存本地代码更改是一样的，只是在“Git世界”中。这让人们感到困惑。但当我看到“提交”这个词时，我想到的是“Git保存”。这是一个额外的步骤，因为您已经保存了一次代码更改，现在必须在Git系统中作为提交第二次保存它们，否则它们就不会成为本地Git存储库系统的一部分。我认为“提交”是一些人认为Git设计糟糕的原因之一。这不是直观的。

A push is done after you have finished all your code saves and commited your code to your Git repo locally. The push command sends your local repository changes (commits only) up to a remote repository so it is updated. When it does this it writes 100% of your changes over the remote repository completely so the two are in sync or the code matches 100% between the two. Think of this as a "Remote Git Save". It writes over the code on the remote repo with what you have locally on your computer. This made no sense to me at first. Would that not erase changes by other developers on the remote? What if the remote conflicts with your changes or you do not have changes in the remote you need first in your local repo? This confused me at first as no one could explain online if this was the same as a "merge", a "commit", "pull request", etc. It turns out this ONLY works under ONE CONDITION. Otherwise it blocks your push and fails!

A "push" only works if you are the only person changing the remote repo and the two code bases are the same other than the commits you added locally. Otherwise, any changes made by another user on that remote will cancel your push. So think of push as a "Private Remote Write Over" of the same copy as on your local rep. But we know many developers will be pushing changes to the remote copy same as you with pushes, right? So push would fail and everyone would be constantly out of synch on their local copy with the remote copy under this design.

As I mentioned, this push is ONLY allowed (not blocked on the remote repo) if the remote repository is in the exact state as your local repository BEFORE you made changes. In other words, you can only push your local change to the remote project and completely write over it with a push if the remote repo has not been modified by any other developer when you push commit local changes up. That is one weird aspect of Git that confuses people. If your local copy of code is out of sync in any way with the remote repo because it has been changed, the push will fail and you will be forced to do a pull or "rebase" which is a fancy word for "update your local repo first with the remote copy". If your push is blocked and you then do a pull, it will copy down the remote code and "merge" its code changes into your local copy. Once in sync again, you can still push your commits up with a push as they should still be present after the pull or merge.

This works perfectly in most cases unless a code change conflicts with commits or code changes you made the other developer also made in the same code area. In that rare case you have to resolve the conflict locally before you can proceed with anything else, as you could erase another developers changes with your own by accident. That is where pull requests (see below) are helpful instead of a push, as the former forces major code changes to be resolved on the remote copy manually by the code owners or admins first before any code is allowed to change the remote repo.

有趣的是，“pull”与“push”的作用相同，但在这种情况下，将最新远程项目的副本拉到本地git系统，然后将这些更改“合并”到您自己的副本中，而不是像“push”那样重写它们。当然，这将再次同步您的远程和本地副本，减去您再次使用“push”在远程回购上设置更新的新提交。

一旦你通过pull将本地副本同步到远程，你现在就可以进行push，再次将你的提交或更改发送回远程副本，并安全地写它，因为你知道你已经将你的更改与所有其他开发人员所做的更改合并了。

After the push writes over the remote copy with your local copy's commits or changes, the remote matches your local copy exactly. Because they both match, any additional commits or saves you make locally can be pushed again remotely without pulls - as long as no developers have changed the remote like you have. Git will always alert you on pushes if that is the case. You cannot screw it up. You can do "forced" pushes., "rebasing", and other tricks but that's not important. But as soon as other developers push their changes, you are out of sync again and have to do a pull again first before pushing.

这种提交-拉-推是Git开发的真正节奏，没有人告诉你，也没有人认为你理解了。大多数人都没有。这既不直观也不符合逻辑。

Of course you can "force" a push and write over everything anyway. But this system will alert you before you try that. This system of pulls and pushes always works better when one developer is updating one branch in one remote repository they own. It fails as soon as a new person adds or changes anything in the remote. That is what causes pushes and pull alerts and failures until everyone sync's again with the remote. When that is done, the developer has power to push changes as their code matches the remote again. But its better to use the Git pull request command when there are a lot of changes or merges of branches and code going to remote repo's.

Lastly, it is important to note that people developing in Git are almost always encouraged to create a new local and remote repo branch first before making changes to software. In that case, the push and pull makes perfect sense as code changes are then almost always done on an isolated branch of the software by a single developer who never conflicts with other developer changes. This then explains why its common for one developer to work on their own branch, and in that case, push and pull works perfectly, can push/pull changes quickly, never causes code conflicts, and allows the one developer to store copies of their final local changes on a remote repo branch he pushes for merging later into main branches using the pull request system described below.

奇怪的拉请求

Git谜题的最后一部分。从远程存储库的角度来看，拉取请求是将本地回购代码拉入其中的“拉取”。但它是一个请求，最初并没有物理上拉任何东西或改变任何东西，也没有推送或合并任何代码。它只是您从本地回购发送到远程回购的请求，以审查代码，如果他们批准，将您的代码拉到他们的远程副本中。

在拉取请求中，您要求远程回购管理员或所有者上传您的代码更改或提交，审查您的本地回购提交更改，然后在他们批准后将您的代码更改合并到远程回购中。当他们批准了您已审核的本地回购提交或更改时，他们会提取您的本地回购代码或分支，并将其合并到远程回购分支中。

The remote repo has admins or owners that control critical top branches of code in the remote repo that are being prepared for production. They do not like to merge changes of code into these larger branches without some control over the quality of the code. When you do a pull request you are alerting the admin or remote repo owners that you as a local developer have some finished branch of code and want them to manually pull your local repo code up into the remote repo code. This is the same as a push from a local to a remote repo, but in this case requires it be completed from the opposite direction by top remote repo owners. It also requires a manual code review and approval of changes from the remote repo owners, first.

注意:pull请求更常见的是合并两个远程回购分支之间的代码，通常会影响远程服务器或设备上必须合并到主远程分支的已完成代码分支，而不仅仅是本地提交更改。再一次，不是直观的，但就是这样!

Why would you need a pull request if you have push and pull Git commands synchronizing and merging code? pull requests work better than pushes in scenarios where lots and lots of people are pulling and pushing huge changes to finished branches with merges to the main remote repo branches and where lots of code could conflict or code added that must be tested or code reviewed first before going to a major release or code base update. Push and 'Pull' works better for isolated smaller branches only one or two developers are working on and sharing. It is much easier to pull and push code between local and remote repos than to merge massive branches of complex remote repo changes into the master branches of a remote repo.

所以rememeber ...

使用“Push”更新本地和远程控制的小分支。

使用“Pull Request”让远程存储库人员将您的小分支合并到远程服务器上的大分支中。

所以我喜欢把拉请求看作是主推，把推看作是本地推。我希望Git的人能让这些过程的名称更符合逻辑，更容易理解。这一点都不直观!

事实证明，pull request也是一种添加代码安全层的方式，当将大型代码堆栈合并到关键的顶级远程时，首先需要管理员或团队成员的许可 项目中分支或分支的合并。因此，它要求团队成员批准大量的本地回购代码更改，并在将它们拉入重要的远程回购分支之前先提交。

This serves to protect code updates to critical branches with code reviews and approvals first. But it also allows remote repos being updated by lots of teams to pause code changes on more important branches and merges before they are tested, approved, etc. This is why small branches of code private to a developer are simply pull and push changes, but larger merges of those branches are typically blocked from pushes by pull requests instead. This is more typical of finished branches using pushes that are then merged into larger branches up the Git tree.

即使我已经使用Git很多年了，我还是花了很多时间研究这个问题，因为网上没有解释这个区别的文档。

So....always use a commit-pull-push routine when working on your own code changes or sections of projectss assigned to you. Pull down repos first to make sure your local repo has all the latest changes made to it by other developers. Commit or save all your local changes before and after the pull if you like...it doesn't matter. If there are conflicts, try to resolve them locally. Then and only then, do your push to write over the remote copy with your local code. Your local and remote repositories are then 100% in sync in the Git World!

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

如果您想象在GitHub的存储库中维护一个日志文件，那么就更容易理解Git命令add和commit的使用。

对于我来说，一个典型的项目日志文件可能是这样的:

---------------- Day 1 --------------------
Message: Completed Task A
Index of files changed: File1, File2

Message: Completed Task B
Index of files changed: File2, File3
-------------------------------------------

---------------- Day 2 --------------------
Message: Corrected typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on

我的一天通常以git pull请求开始，以git push请求结束。所以一天记录里的每件事都与他们之间发生的事情相对应。每天，我都要完成一个或多个逻辑任务，这些任务需要修改一些文件。在该任务期间编辑的文件列在一个索引中。

每个子任务(这里的任务A和任务B)都是单独的提交。git add命令将文件添加到“已更改文件索引”列表中。这个过程也称为暂存，在现实中记录更改的文件和执行的更改。git commit命令记录/完成更改和相应的索引列表，以及一个自定义消息，以供以后引用。

请记住，您仍然只更改存储库的本地副本，而不是GitHub上的副本。在此之后，只有当你执行git推送时，才能将所有这些记录的更改以及每次提交的索引文件记录到主存储库(GitHub)上。

作为一个例子，为了获得那个虚构日志文件中的第二个条目，我将做:

git pull

# Make changes to File3 and File4
git add File3 File4

# Verify changes, run tests etc..
git commit -m 'Corrected typos'
git push

简而言之，git add和git commit让您可以将对主存储库的更改分解为系统的逻辑子更改。正如其他的回答和评论所指出的，它们当然还有更多的用途。然而，这是最常见的用法之一，也是Git作为多阶段修订控制系统的驱动原则，而不像其他流行的版本控制系统(如SVN)。

提交更改时，将更改保存为本地存储库中的单个逻辑集。你可以多次这样做而不用推。在它们被推送之前，它们不会离开您的本地存储库，这意味着远程存储库还没有这些更改集，因此当其他人从远程存储库中进行拉取时，您的提交不会被拉取。

当您推送时，您在本地存储库中所做的所有提交将被传输到远程存储库，因此当共享此远程存储库的其他开发人员进行拉取时，他们将把您的更改传输到他们的本地存储库。 查看Git命令和备忘单。