赵走x博客
首页
书籍
软件
工具
古诗词
搜索
登录
12、命令指南
11、单人团队：连接远程仓库
10、单人团队：使用标签
9、单人团队：在仓库中添加更改
8、单人团队：使用分支工作
7、单人团队：创建本地仓库
6、单人团队：基于 issue 的版本控制
5、工作流
4、分支策略
3、访问模型
2、项目治理
1、团队作战
9、单人团队：在仓库中添加更改
资源编号:76630
Git团队协作
书籍
热度：34
每次你在工作目录中进行修改时，都需要显式地将这些更改保存到你的 Git 仓库。这个过 程分为两步。图 5-5 显示应该如何将更改显式地暂存到索引，然后保存至你的仓库。  图 5-5:Git 中的更改必须先进行暂存,然后再保存至仓库 之前你创建一个新的仓库时,一次性导入了一系列文件(例 5-5) 。不过,你也可以选择不 这么做。当你同时进行一些不相关的编辑,并且想将这些修改放置在不同的提交中时,这 个功能将会尤为有用。 如果你确实希望将这些更改分离到多个提交, 需要将先前使用的 --all 参数替换成你想要暂存的文件名(例 5-16) 。你可以同时添加一个或多个文件名,文件名不需要是同一种类型的。 例 5-16 将选中的已更改文件添加至你的 Git 仓库 ``` $ git add README.md process-diagram.png $ git add branch-naming-rules.png ``` 大多数时候，我都会一次一个地将文件添加到暂存区。我发现这个习惯能够避免我意外添 加更多文件。 在命令行中， 我可以输入文件名的前几个字母， 按下 Tab 键， 然后剩下的 文件名会自动显示出来（这就是 Tab 补全， 我的最爱之一）。但是，如果你有很多文件需 要添加，而且它们还不在同一个目录下，你或许会想要使用通配符来匹配子目录中的文件 （例 5-17） ，或者匹配文件名相似的文件（例 5-18） 。 例5-17递归地添加指定路径中的所有文件 ``` $ git add <directory_name>/* ``` 例5-18添加扩展名为.svg的所有文件 ``` $ git add *.svg ``` 你还可以完全忽略文件名，根据 Git 中是否已知这些文件来暂存它们。通过使用 --update 参数，你可以暂存 Git 中所有已知的且在上次提交之后编辑过（或修改过）的文件，如下 所示。 ``` $ git add --update ``` 如果你想要更加粗放一些，可以添加 --all 参数来暂存工作目录中所有修改过的文件。这 个参数将会重新暂存在首次暂存后发生修改的任何文件（确保所有新的修改都包含在这个 提交中。暂存 Git 中所有已知但还没有进行暂存的文件；暂存任何当前未被 Git 跟踪的文 件。这是一个非常贪婪的命令！在使用前，你应该检查即将添加的文件的列表，如下所示。 ``` $ git status $ git add --all ``` 一旦将变更添加至暂存区，就必须提交这个更改。如果你继续编辑任何一个刚刚添加到索 引中的文件， 那么在下次运行 commit 命令时， 仅会添加之前暂存过的更改（图 5-6） 。 如 果你继续修改某个文件，并且希望新的变更包含在提交中，就需要重复之前的命令，再次 将文件添加至暂存区。 你可以运行 commit 命令来将暂存的变更提交至仓库（例 5-6） 。 如果你在最初感到有些挫败，请记住不是只有你一个人是这样的！我花了很长时间来习惯 它的行为，当它没有意识到我已经修改了文件并暂存了新的修改时，我还以为是 Git 坏了。 直到开始学到部分暂存文件，我才意识到“不自动暂存我的修改”这个功能有多么强大。  图 5-6：一次提交只会保存已添加至索引中的文件 # 5.4.1 在仓库中添加部分文件修改 如果你希望你的提交能有更细的粒度，那么可以选择使用 --patch 参数来添加已保存的文 件中的部分修改。我喜欢使用这种方式提交文件，其中一个原因是，我可以将无关的编辑 记录在多个更小的提交中。 通过 --patch 添加文件的过程分成多个步骤（例 5-19） 。 你将首先初始化这个过程， 然后 从列表中选出一个选项，来决定如何创建你的补丁。你将会看到一条提示，将这些修改添 加至暂存区（ y ），或不改变这个补丁片段（hunk）（ n ）。修改过的行将会以一个 - （删除的 行）或一个 + （新增的行）开头。如果某行进行过修改，它会同时显示为被删除和被新增。 为了将这些补丁片段拆分成更小的单元，你可以使用 s 选项来拆分这个补丁片段。只有在 两个补丁片段之间存在至少一行未修改的工作时，这个选项才会生效。如果你希望将相邻的两行分别暂存，可以编辑（ e ）这个补丁片段。 例 5-19 将选中的修改交互式地添加到你的 Git 仓库 ``` $ git add --patch filename ``` 通过添加可选的文件名，你不再需要将所有文件都看一遍。如果你确切知道想要分割哪些 文件，并且有很多文件需要暂存，这个选项可以节省你大量处理单个文件的时间。在运行 这个命令后，你将会开始遍历这些文件，寻找需要暂存的修改，如下所示。 ``` diff --git a/ch05.asciidoc b/ch05.asciidoc index 8f82732..e7be9ce 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -6,7 +6,6 @@ changed significantly in the last few years; however, a few of the commands we'l easier to remember. Chances are very good that you have Git installed if you are using Linux or OSX. If you are using Windows, however, the changes are very good that Git is not installed unless you've explicitly installed it already. -. Open a terminal window. . Enter the command: +git --version+ The version of Git you are running should be printed to the screen. Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? ``` 在这里显示的输出中， 我们可以看到 Git 询问我们是否想要暂存这一行修改（ . Open a terminal window. ），也就是通过 - 指示的这一行删除。你可以按下 ? 查看处理这个补丁片段的其他选项。 # 5.4.2 提交部分更改 假设你刚才只将某个文件中的部分修改添加到了暂存区，那么在查看仓库状态的时候，将 会看到这个文件准备好了被提交的修改，同时也包含未被暂存的修改，如下所示。 ``` On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: ch05.asciidoc Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: ch05.asciidoc ``` 如果你将一个文件添加至暂存区，然后在提交至仓库之前继续编辑这份文件；或者如果你 只选择暂存一些补丁片段，同时使用 patch 参数交互地将文件添加到索引，都会出现与此 相同的信息。 # 5.4.3 从暂存区移除文件 如果你不小心向暂存区添加了太多的文件，同时想把这些修改分割为更小的提交，那么可 以取消暂存你提出的修改（例 5-20） 。 从暂存区移除文件并不意味着撤销你所做的修改； 它会通知 Git， 你现在还没有准备好将这些更改提交到仓库。 例 5-20 从暂存区移除提出的文件修改 ``` $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: ch05.asciidoc $ git reset HEAD ch05.asciidoc Unstaged changes after reset: M ch05.asciidoc ``` 另外， 如果你只想取消暂存你对文件做出的某些修改， 那么还可以使用 reset 命令和 --patch 参数。 撤销工作将会在第6章中更详细地介绍。 # 5.4.4 编写扩展提交消息 到现在为止，你可能都在编写精简的单行提交消息。如果你只是在练习版本控制命令，这 么做没有关系，但如果你以后需要弄清楚一条叫“糟糕，再试一次”的提交消息是什么意 思，那么恐怕不会很高兴。 我曾经将 Git 当成一个保存工作而不是记录结果的地方， 我花了好长一段时间来摆脱这 种思维方式。 当我第一次开始使用版本控制时， 为了利用这套先进的工具， 我创建的提 交粒度非常细（详见第 6 章）。这是因为我脑中想的是保存工作并撤销错误。用保存的想 法思考时，我会想到点击保存按钮，或者使用 Control-Z 来撤销我刚输入的一些东西。 当 提交变得如此细小时，提交消息就没有什么意义了（“去吃午饭了”“试了一下”“还是不 行”“糟糕”“测试”）。如果我想要回滚历史，那么要如何用这些提交信息来找到出错前正 常工作的代码？找到自己的节奏也需要花费不少时间。 你的提交消息应该总是包含做出这个修改的原因，以及对你做出的修改的一个简要总结。 为了编写一条详细的提交消息，对于你一直使用至今的单行短消息样式，你需要编写多行 这样的消息。我通常使用下面的两步过程来编写我的提交消息（例 5-21） 。 • 使用一个简短的单行消息将修改提交至仓库。 • 修补这个提交，完整地说明我在做出这个修改时在想什么。 例5-21编写详细的提交消息 ``` $ git add --all $ git commit -m "CH05: Adding technical edits." $ git commit --amend ``` 你不需要分成两步完成；你可以在第一次提交时忽略-m参数， 直接跳转到消息编辑器， 如下所示。 ``` $ git commit ``` 此时你的默认编辑器会打开，然后会提示你添加一条新的提交消息。这条消息的第一行将 用于显示 --oneline ，所有以 # 开头的行将在最终的消息中进行注释。 一旦你编辑好你的 提交消息，就需要保存它，然后退出编辑器以完成提交。 在第6章中你将会学到如何通过交互式变基将细粒度的提交压缩成一个完整的想法。 # 5.4.5 忽略文件 最终， 你可能会遇到这样的情况， Git 不断将你想添加的文件加入到仓库。 如果你使用 Mac， 这可能是烦人的 .DS_Store 文件。 如果你使用 Linux， 这可能是文本编辑器的 .swp 文件。如果你在进行一个 Web 项目，它可能会包含从 Sass 编译出的 CSS 文件。 如果你知道你最喜爱的文本编辑器或 IDE 会制造临时文件，且这些文件与项目无关，那么 你应该创建一个全局设置来忽略这些文件。 首先，运行下面的命令来告诉 Git“忽略”文件的列表存放在什么位置。 ``` $ git config --global core.excludesfile ~/.gitignore ``` 你现在可以更新这个文件， 每行一个文件名。 你可以使用确切的文件名， 或者通配符 （例如： *.swp 将会匹配所有以 .swp 结尾的文件）。 你可以查看 gitignore.io（https://www. gitignore.io/） ，使用它提供的忽略文件列表作为有用的起点。 另外，你或许希望特定仓库忽略特定的文件或文件扩展名。在这种情况下，你的最佳选择 是在仓库中添加一个额外的 .gitignore 文件。这样做附带的好处是，你的队友一定不会意外 地将构建文件提交上来。 完成下面几步来自定义特定仓库中应该被忽略的文件。 (1) 在项目根目录创建一个名为 .gitignore 的文件。 (2) 每行一个文件名，写上所有你一定不希望 Git 添加到仓库中的文件。你可以使用确切的 文件名或通配符（如 *.swp ）。 (3) 使用 add 和 commit 命令将 .gitignore 文件添加到你的仓库。 包含以上扩展名的文件将永远不会被添加至你的仓库，即使你使用了 --all 参数。
