今天,版本控制系统也许是每一个开发者工具箱中的必备。而了解其基本规则可以让它更加起作用。我们总结了一些帮助您使用Git来高效的进行版本控制的最佳实践。
一次提交应该是一组相关变更的打包。例如,修复了两个不同的bug应该产生两个分开的提交。小巧规模的提交使得其他开发者很容易去理解变更的目的,并且在发生某些问题时也能方便的回滚它们。使用像中转区域和只中转一个文件的某些部分,这类工具,Git使得创建十分精细粒度的提交更加容易。
经常提交保持了您提交的小巧,并且再一次帮助你只提交相关的变更。此外,它允许您与其他人更高频率的分享代码。那就每个人就能够更加容易的有规律的整合变更,并且避免混合冲突的问题。反之,做一些大型规模的提交,并且极少分享他们,使得解决冲突变得困难起来。
其它翻译版本 (2) 加载中您应该只在最后完成时再提交代码。这并不意味着您必须在提交之前完成一整个大的功能。正相反:把功能的实现分解成逻辑块,并且牢记尽早且经常提交。但是不要只为了在一天的余下部分离开办公室之前在资源库中留下点什么而提交。如果你的提交只是因为你需要一个干净的工作备份(检出一个分支,检入变更等等),取而代之请考虑使用Git的“Stash”(隐藏)功能吧。
抵制住在你“认为”完成了一些东西以后就提交的诱惑。对它进行彻底的测试,以确保它真的完成了,并且没有副作用(根据现有能提供消息来判断)。在你的本地配置库中提交半成品只需要你谅解你自己就行了,但是当用它来推动与他人分享你的代码的时候,测试您的代码就更加重要了。
用一个对您的变更的简短总结作为信息的开端(建议最多用50个字符)。用一个空行来把它和接下来的正文分开。信息的正文应该提交如下问题的详细答案:变更的动机是什么?它更前面的实现区别在哪里?使用原始的,现成的事态(“change”而不是“changed”或者“changes”)同git merge命令生成的信息保持一致。
让您的文件在一个远程服务器上备份是使用一个版本控制系统的好的副作用。但是您不应该像一个备份系统那样使用您的VCS。在做版本控制的时候,您应该注意进行语义上的提交(见“相关的变更”)——你不应该只是填满文件。
分支是Git最强的功能之一——并且这不是偶然的:快速和容易的分支是从一开始就有的重要需求。分支是帮助您避免混合不同开发路线的完美工具。您应该在您的开发工作流中广泛的使用分支:新的功能,bug修复,创意...
Git让你从许多不同的工作流中挑选——长时间运行分支,主分支,合并或垫底,git流...。 基于两个因素决定你选择哪一个:您的计划(project),您开发和部署的整体工作流程还有(也许是最重要的)您和您队友的个人喜好。不管您选择怎样去工作,只要确保认同一个每个人都遵守的共同的工作流。
其它翻译版本 (3) 加载中 本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务