我是版本控制的新手,我知道“提交”实际上是在更新您正在处理的新“当前”版本时创建备份。
我不明白的是从实际角度来看是什么。是暂存只存在于名称中还是有用的东西?当你提交时,无论如何它都会提交一切,对吗?
编辑:我想我可能会混淆术语。 “暂存”文件是否与“跟踪”文件相同?
答案 0 :(得分:63)
当你提交它时,它只会提交索引中的更改(“暂存”文件)。这有很多用途,但最明显的是将你的工作变化分解成更小的,独立的部分。也许您在实现功能时修复了一个错误。您可以git add
只是该文件(或git add -p
只添加文件的一部分!)然后在提交其他所有内容之前提交该错误修复。如果您使用git commit -a
,那么您只是在提交之前强制执行add
所有内容。如果您想利用暂存文件,请不要使用-a
。
您还可以使用--cached
到多个命令将暂存文件视为中间工作副本。例如,git diff --cached
会向您显示该阶段与HEAD
的不同之处,以便您可以在不混淆其他工作更改的情况下查看您要提交的内容。
答案 1 :(得分:14)
答案 2 :(得分:6)
分段的一个实际目的是文件提交的逻辑分离。
由于staging允许您继续对文件/工作目录进行编辑,并在您认为已准备就绪时进行部分提交,因此您可以使用单独的阶段进行逻辑上不相关的编辑。
假设您有4个文件fileA.html
,fileB.html
,fileC.html
和fileD.html
。您对所有4个文件进行了更改并准备提交,但fileA.html
和fileB.html
中的更改在逻辑上相关(例如,两个文件中的相同新功能实现),而fileC.html
和fileD.html
与以前的文件在逻辑上无关。您可以先暂存文件fileA.html
和fileB.html
并提交这些文件。
git add fileA.html
git add fileB.html
git commit -m "Implemented new feature XYZ"
然后在下一步中,您将对剩余的两个文件进行更改并提交更改。
git add fileC.html
git add fileD.html
git commit -m "Implemented another feature EFG"
答案 3 :(得分:2)
暂存区域有助于我们以更大的灵活性制作提交。通过精心设计,我的意思是将提交分解为逻辑单元。如果您需要可维护的软件,这一点非常重要。最明显的方法是:
您可以在单个工作目录中处理多个功能/错误,并仍然可以进行有意义的提交。拥有一个包含我们所有活动工作的单一工作目录也非常方便。 (这可以在没有临时区域的情况下完成,只要更改不会与文件重叠。您还有责任手动跟踪它们是否重叠)
您可以在此处找到更多示例: Uses of Index
最好的部分是,优势并不止于此工作流程列表。如果确实出现了独特的工作流程,您几乎可以确定暂存区域可以帮助您。
答案 4 :(得分:1)
如果您想象在Github上的存储库中维护日志文件,则更容易理解git命令add
和commit
的使用。
我的典型项目日志文件可能如下所示:
---------------- Day 1 --------------------
Message: Complete Task A
Index of files changed: File1, File2
Message: Complete Task B
Index of files changed: File2, File3
-------------------------------------------
---------------- Day 2 --------------------
Message: Correct typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on
我通常以git pull
请求开始我的一天,并以git push
请求结束。因此,一天内的所有记录都与他们之间发生的事情相对应。在每一天,我完成了一个或多个逻辑任务,需要更改一些文件。在该任务期间编辑的文件列在索引中。
这些子任务(这里的任务A和任务B)中的每一个都是单独的提交。 git add
命令将文件添加到“已更改的文件索引”中。名单。此过程也称为分段。 git commit
命令记录/最终确定更改以及相应的索引列表以及自定义消息。
请记住,您仍然只更改存储库的本地副本,而不是Github上的副本。在此之后,只有当你做了一个' git push'将所有这些记录的更改以及每个提交的索引文件记录在主存储库(在Github上)上。
作为一个例子,要获得该虚构日志文件中的第二个条目,我本可以做到:
git pull
# Make changes to these files
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Correct typos'
git push
简而言之,git add
和git commit
允许您将对主存储库的更改分解为系统逻辑子更改。正如其他答案和评论所指出的那样,它们有更多的用途。然而,这是最常见的用法之一,也是Git背后的驱动原则,它是一个多阶段的修订控制系统,不像其他流行的像Svn。
答案 5 :(得分:1)
我看到@Ben Jackson和@Tapashee Tabassum Urmi提到的使用舞台来缩小提交的要点,有时我将其用于此目的,但是我主要使用它来放大我的提交!这是我的观点:
说我想添加一个小的功能,它需要几个较小的步骤。对于较小的步骤并充斥我的时间表,我认为没有任何意义。但是我想保存每个步骤,然后在必要时返回
我只是将较小的步骤相互叠加,当我觉得值得提交时,我就会提交。这样,我从时间轴中删除了不必要的提交,但是却可以撤消(签出)最后一步。
我看到了执行此操作的其他方法(简化git历史记录),您可以根据自己的喜好使用
答案 6 :(得分:0)
这就像一个复选框,提供了选择提交哪些文件的功能。
例如,如果我编辑了fileA.txt
和fileB.txt
。但是我只想提交fileA.txt
的更改。因为我还没有完成fileB.txt
。
我可以简单地使用git add fileA.txt
并使用git commit -m "changed fileA.txt"
提交并继续使用fileB.txt
,完成后我可以轻松地提交fileB.txt