刚接触 Git 和 GitHub，我做错了吗？
我对一个现有文件 test.cs git add 进行了更改
- 。
- git commit -m “我对 test.cs 的更改”
- git pull origin master
- >它拉下 SomeOtherFile.cs （由其他人更改，不是新的）
- > >我检查构建...)
- git push
当我转到 github 时，我的推送下有两个提交，一个用于“test.cs”，一个用于 SomeOtherFile.cs
这是预期的行为吗？
谢谢..
I make a change to one existing file test.cs
- git add .
- git commit -m "my change to test.cs"
- git pull origin master
- > it pulls down SomeOtherFile.cs (changed by someone else, not new)
- > I check the build... )
- git push
When I go to github, there are two commits under my push, one for 'test.cs', and one for SomeOtherFile.cs
Is this expected behavior?
Thanks..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您执行 git add . 时，您会将工作目录中的任何文件的更改添加到索引中。如果您只想为
test.cs创建提交，请改为：When you do
git add ., you will add changes to any files in your working directory to the index. If you only want to create a commit fortest.cs, do instead:所以你在这里遇到的是合并和变基之间的区别。当您执行以下操作时：
您创建了一个合并提交，该提交合并了 master 中的更改。该合并提交是空的，但它已创建。合并的这种行为是预期的，但在我看来是不可取的。创建提交是为了保存两个分支（您的本地分支和 Origin Master）之间的差异，并且无论是否存在任何差异都会创建提交。如果你改为发布，
你就会进行变基。变基会查找本地和 Origin Master 共同的最后一次提交，将自该提交以来的更改保留到临时存储中，然后对 Origin Master 的更改进行分层（来自 NotYou 的 SomeOtherFile.cs 提交），最后重播您的更改在新更新的线路之上。此重放是逐个提交完成的，因此如果您提前 10 个提交，那么它将发生 10 次。
如果没有冲突，那么这一切都会立即发生，无需干预。如果存在冲突，那么您将在中间停止，要求纠正问题，然后您发出 a
以使流程继续。这里发生的情况是，冲突是通过重新定义原始提交来处理的，而不是通过添加合并提交来处理。但它保持文件历史记录干净，而合并并不像您所看到的那样。
So what you are running into here is the difference between a Merge and a Rebase. When you did the:
You created a merge commit which merged the changes in from master. That merge commit was empty, but it was created. This behavior from merge is expected, but in my opinion undesirable. The commit was created to hold the differences between the two branches (Your local and Origin Master), and is created regardless of the existence of any differences. If you had instead issued
You would have done a rebase. A rebase looks for the last commit your local and Origin Master have in common, sets aside into temporary storage your changes since that commit, then layers on the changes from Origin Master (the SomeOtherFile.cs commit from NotYou), and finally replays your changes on top of that new updated line. This replaying is done commit by commit, so if you're 10 commits ahead it will happen 10 times.
If there are no conflicts, then this all happens instantly and without intervention. If there is a conflict, then you will be stopped in the middle, asked to correct the problem, and then you issue a
to have the process move on. What happens here is that conflicts are handled by redefining your original commit, rather than by adding a merge commit. But it keeps the file histories clean, which merge does not as you have seen.