ios - 将 iOS xcode 文件提交到 Github 的一般规则

Question

我最近遇到这样一种情况，当我向 github 提交大约 12 *.h 和 12 *.m 以及一堆图像( Assets )时，一位同事基本上大发雷霆。这 12 个文件包括一些 .xib 文件。总更改(包括图像和 xib xml 代码)大约有 985 个更改。 985 行主要是因为 .xib 文件正在转换为 xml 代码。同事说checkin太大了。看到这种 react 我有点惊讶，因为我不认为包含 24 个文件是一个巨大的 checkin ，或者这真的违反了提交到 github 的规则。我一生中的大部分时间都在使用 SVN，并在大型团队中工作，而我从未遇到过这个问题。我正在一个 2 人团队和一个最近的 git 用户中工作。想知道我是否真的需要改变我的 promise 方式？有什么建议吗？

-谢谢

Answer 1

我也通读了讨论，他问的问题绝对看起来像是异常(exception)，而不是常态，尤其是对于只有两个人的小团队而言。确实有一些规则要遵守，但它们只是优秀软件工程的常识。我不想超出您的问题范围，因为如果我们开始讨论不同类型分支机构的所有各种用途，我们可能会讨论好几天。

我将首先讨论您希望通过提交实现什么，然后是可以实现该目标的方法，从而向您的同事提出论点。这应该是一次对话——谁知道呢，如果你讨论他的目标，你可能会发现走他的路是有益的。希望您能找到满足所有最重要目标的共同点。当你们达成协议(protocol)时，你们应该一起制定一些指导方针，并为双方复印一份。当时记住它们似乎很容易，因为它们是合乎逻辑的，但在同一时刻，您也可能做出几周或几个月后看起来不那么合乎逻辑的妥协。

目标

1. 开发人员应该能够进行提交，而不必费力地到达项目中包含构建错误的位置。这还可以提供更高效、多产且无压力的开发环境。
2. 开发人员应该能够确信提交没有错误。任何建立在错误代码上的开发都不可能稳定。这就像盖房子——地基必须坚固，否则建在上面的一切都可能折叠。
3. 开发人员应该能够通过阅读提交评论来进行任何提交，并清楚地了解内容和范围。
4. 开发者应该能够轻松、快速地自信地选择提交，而无需反复试验。

方法

1. 提交应包含一组内聚的文件和代码。这意味着实现文件应该与头文件和 Assets 一起提交。否则，当实现调用尚未声明的方法时，提交可能会出现构建错误，或者开发人员在查看未在项目中任何地方使用的 header 中的声明时会不知所措。您的提交应该讲述您如何朝着最终产品前进的故事。每次提交都会影响您回滚以修复任何错误的效率和准确度。
2. 不要提交未成功构建的项目。
3. 测试您的代码，然后重新测试。在存储库中引入新对象时，执行单元测试，从具有最少依赖性的对象开始。
4. 如果您正在做一个小的更改，但它是有凝聚力的，并且可以讲述开发故事的一部分，那么请继续并提交它。这也将使您能够重新开始一项更大的任务，并且能够在某些事情没有成功时重置对您的工作副本的更改，并且您需要尝试一些完全不同的事情。
5. 如果您有很多提交，请使用标签。在数百个提交上设置几个标签可以节省大量时间，因为它们允许开发人员快速轻松地选择一个提交，开始查明错误的原因。
6. 对于需要大量工作的功能，也可以使用分支。这允许多个团队同时处理多个功能，而不会踩到彼此的脚趾。对于像您这样的两人团队，如果您希望能够在不同的功能上进行多次提交，这也可能是有益的。对于分支的一些逻辑用例，请查看 Source Tree，并在本地存储库中创建一些具有不同选项的分支。对我来说，它很有指导意义，为很多分支决策提供了一个很好的框架。