Git 团队协作 (6):团队作战 1.3.4&1.4

阅读数:9 2019 年 11 月 24 日 22:00

Git团队协作(6):团队作战 1.3.4&1.4

(回顾)

内容简介
Git 团队协作 是一本软件团队协作指南,采用以人为本的方式讲解版本控制,强调如何利用 Git 促进团队协作。第一部分介绍如何创建一个优秀的团队、如何构建工作流等。第二部分从实践的角度学习 Git 命令。第三部分介绍如何在 GitHub、Bitbucket 和 GitLab 平台上托管项目。

上述会议是总结经验、取长补短的最佳时机。这些会议还应该整理未来可以重用的模板。一段工作的结束会议应该是不责备、不让人羞愧的,人们可以畅谈做得不好的地方。作为项目经理,我很少为我的决定感到后悔。我依靠团队提供的信息来帮助我作出最好的决策。所以在回顾中,我总是很容易避免一些“本来应该、可以这么做”的诱惑。不过,我确实在留意一些面向未来的模式。换言之,明确我们在会议中提出的哪些问题本可以得到解决,以获得另一些有用的信息(这些信息或许会让我们在未来遇到同类项目时能够作出更好的决策)。

从版本控制的角度来说,项目的终点也是一个巨大的机遇,你可以挑出你最喜欢的工单,记录它们与众不同的原因。或许它提出了一种组织信息的新方式,而你想要重用这一点。看一看 Git 仓库,寻找一些特别好的提交信息,供以后的项目参考。


(Git 中的团队协作)

如果你尚未接触过分布式版本控制,会看到一些术语贯穿了本书剩下的部分。这些术语在简单的开发者工作流中最容易理解。

每个开发者都有一个本地的仓库副本,即项目中的更改历史的独立副本。为了共享更改,开发者一般会将一份仓库的副本发布到一个集中式的代码托管系统,如 GitHub。尽管如此,正如你将在本章剩下的部分中了解到的那样,会有很多种分享代码的方法。

在仓库的中央副本中,开发者将会创建一个他们可以更改的仓库副本。在 Git 的用语中,这个过程称为克隆副本,尽管这个过程也可以称为派生(forking)。

在克隆仓库时,软件开发者可以选择将他们的项目副本设置为私有的或公开的。一个私有仓库默认不希望别人直接查看这个副本,而只通过查看主项目来获得被官方接受的更改。另一方面,任何人都可以直接向开发者的仓库的公开副本提交贡献。对于软件开发来说,这是一个更加开放的策略,但可能会让人对哪个副本才是项目的起点感到困惑。

只有通过项目治理才能决定哪一个仓库是最重要的版本。这是因为每个仓库都可以接受更改,并与外界共享更改。项目之间的关系不是一成不变的。你可以在不同的仓库副本间建立关系网络,或者建立一个线性的关系链。但一般来说,软件产品的官方版本称为当前仓库的上游。例如,我的博客是通过 Sculpin( https://getsculpin.com/ )创建的。我将这个软件的官方发布版本克隆下来,并直接修改这个仓库来编写博文。如果我希望获得软件最新的更改,将会并入上游的更改。

派生一份新的奶油塔食谱
对长期开源软件开发者来说,派生(fork)这个术语出现时,往往是一个分裂的社区充满了对项目的失望,一群开发者决定“派生一份新的项目”,然后朝着不同的方向发展。派生简单来说就是偏离主路,就像一条林荫小路,或是我的曾祖母 Austin 的奶油塔食谱。每个派生的分支指向了不同方向。在这个奶油塔的例子中,就是加或不加小葡萄干。你可以在附录 A 中读到我家的派生食谱。

在一个单独的仓库中,我可以存放项目的不同版本。这些仓库内的更改可以通过分支进行追踪。为了从我当前的分支切换到另一个,我将会签出(check out)我想要切换过去的分支。(我心中默念“这个太酷了,快签出看看”。)在切换前,Git 将会强制要求我处理未提交的更改,要么提交,要么舍弃。提交过程会将我的更改持久存储到仓库,而储藏(stash)将会暂存更改,允许你随后拉取你刚刚储藏的工作并重新应用。

手工艺人的储藏物
编织者、裁缝和其他纤维艺术家通常会储藏一些纱线和织物。当一个新的项目开始时,我们可能去“储藏室购物”而不是去商店。那些储藏量巨大的人也许会谈到“达到了 SABLE 的状态”(储藏的纱线一辈子都用不完)。我认为这个类比对 Git 的储藏物来说也适用,和手工艺一样,我推荐定期清理储藏物以防虫蛀。如果你是一位编织者,你会喜欢上 Git for Knitters( https://github.com/gitforknitters/gitforknitters )。

并入和发布更改的过程使用了下面这些命令。我从远端仓库抓取(pull)更改,然后自动并入我的仓库。这个过程拉取(fetch)新的更改并将它们合并(merge)进入本地分支(branch)的跟踪(tracked)副本。不管什么时候,我在我的仓库的本地分支上工作。如果想与其他开发者共享更改,我会将我的工作提交至仓库,然后将我的分支推送(push)到远端仓库。

Git团队协作(6):团队作战 1.3.4&1.4

图灵地址 http://www.ituring.com.cn/book/1779

评论

发布