赵走x博客
首页
书籍
软件
工具
古诗词
搜索
登录
12、命令指南
11、单人团队：连接远程仓库
10、单人团队：使用标签
9、单人团队：在仓库中添加更改
8、单人团队：使用分支工作
7、单人团队：创建本地仓库
6、单人团队：基于 issue 的版本控制
5、工作流
4、分支策略
3、访问模型
2、项目治理
1、团队作战
6、单人团队：基于 issue 的版本控制
资源编号:76627
Git团队协作
书籍
热度：37
在本书的这一部分中，我们从实践的角度来学习 Git 命令。首先会给出一个场景，然后会 给你一些让自己陷入（摆脱）困境的命令。 本章随处可见需要上手实践的活动。在可能的情况下，你应该完成这些活动，因为这能帮 助你深入理解命令（并且在从事自己的软件项目时， 你也会觉得相应的消息更加自然）。 当提供了图表时，你应该自己重新绘制一遍，因为每当你学习一个新的活动时，你的一举 一动都会帮助你在脑海中强化这些信息。 在阅读后续章节前，你应该确保你安装了最新版本的 Git（参见附录 B） ，并确保你的系统 已经配置正确（参见附录 C） 。 第5章 尽管这本书是面向多人团队的，但我们经常也会单兵奋战，即作为独立开发者。可能你是 在做自己的业务项目，或者你的团队中只有你一个开发者。没有团队约束的单兵奋战或许 有些吓人，因为没有人会告诉你应该做什么，或是在你陷入困境时帮你一把。我会向你展 示我在做自己的项目时是如何工作的。当然，有些时候我偷懒省去了一些步骤。（毕竟没 有人监督我，所以谁会知道我走了捷径呢？）在可能的地方，我将会向你展示这些捷径的 效果。 学完本章之后，你将具备以下技能。 • 创建一份远程仓库的本地副本 • 为现有的文件集初始化版本控制 • 从空的项目目录开始创建一个新的仓库 • 通过提交消息来检查仓库历史 • 通过分支来隔离无关的工作 • 在本地仓库中创建提交 • 使用标签来高亮单个提交 • 建立你的项目与远程代码托管系统的连接 如果你是一个创造者（相对于评审者或管理者），那么你的大部分时间应该花在使用本章 介绍的命令上。应当将熟练使用这里介绍的所有工具视为阅读本部分剩余章节的前提。 喜欢通过视频教程学习的读者可以参考本书附带的系列视频， Collaborating with Git（http:// shop.oreilly.com/product/0636920034872.do） 。 # 基于 issue 的版本控制 曾经有人和我说，最擅长描述一个问题的人最有可能能够解决它。在写这本书的时候，我 发觉这个观点太正确了。当我给自己写下一个模糊不清的待办事项（TODO），比如“完成 第 4 章”时，我感到几乎没有继续写下去的动力。但当我把这个任务描述为“为 Mai 这样 的小型团队编写样例工作流”后，我更有深入写作的动力。不过，这不仅限于写书。作为 单人团队，你可能没有很大的动力来编写代码。不过，要是你和我一样，如果做的事情能 够帮助别人，你就会更有动力把这件事情做成。 • 问题 大致描述你想要解决的问题。 • 原因 为什么你想要做这件事（如果问题得到解决，谁将受益）？ • 质量保证测试 我将如何知道这个问题已经得到解决？ 这种格式与我所见到的敏捷项目使用的另一种格式非常相似。 * 卡片 从用户的角度，大致描述这个问题。 * 对话 你想要解决的问题的细节。在可能的情况下，应该避免给出具体的解决方案。 * 确认 （第一部分中的）用户用于验证问题是否解决的步骤。 在单人团队中，你可能感觉使用工单的开销对你来说大了些。或许你的记事本就已经足够 了。我通常一开始也这样认为，但继续做项目时，我开始不断地忘记一些微小的想法。有 时我为每个想法创建一个新的分支，但最后被一大堆过时的分支压得透不过气来。如果你 有同感，请现在就花点时间，找到你使用的代码托管系统中的工单跟踪选项，然后渐渐养 成习惯，记录你将对你的软件所做的工作。至少，它会给你一些用于创建分支和跟踪代码 的编号。 如果你目前还没有代码托管系统， 我向你推荐 GitLab。 一旦你找到一种跟踪想法的方式，工作的流程应该遵循以下步骤。 (1) 在你的 issue 跟踪系统中创建一个新的工单，注明这个 issue 的编号。 (2) 在你的本地仓库中，使用 issuenumber-description 格式创建一个新的分支。 (3) 完成工单描述的工作（且只完成工单中描述的工作）。 (4) 测试你的工作，确保已经完成并且是正确的。确保它能够通过开发环境下的 QA 测试。 (5) 现在， 你有了一个“杂乱”的工作目录， 其中包含了新增的文件和（或）修改过的文 件。将你的更改添加到本地仓库的暂存区。 (6) 将你缓存的修改提交至仓库。 (7) 将你的更改推送到备用服务器上。 在很多情况下， 这也将是追踪你的工单的地方， 如 GitLab、Bitbucket 或 GitHub。 根据你的工单系统，现在可以将这个工单标记为已解决， 但不需要将其标记为已关闭。 (8) 当你对你的工作完全满意时， 将你的工单分支并入主分支（通常是 master ）并将修改 后的分支推送到代码托管系统中。 (9) 再一次测试你的工作，确保没有后续问题。 (10) 将你的工单标记为已关闭。 
