git 打git_Git的阴暗面

git 打git

git很棒！

作为一个分布式源代码工具，git很棒。 我喜欢在飞机上时无需无线连接即可提交代码，并且能够解散自己的工作。 它的设计显然考虑了“离线”模型。 我可以创建一个快速分支，进行实验，进行大范围的更改，并且如果我发现它很烂的话就把整个东西丢掉……这个想法真是太好了！ 事实上，这使它领先于开源的前身（即……SVN，CVS和RCS）。

但也许是成功的受害者

但是，我观察到的是，很多人都采用了“一切都是分支”的开发模型，并且最终以“拉动请求批准工程师”这样的角色（不是真正的头衔，但是如果您最终做的是这项工作，您就会知道自己在做）。 当公共分支机构/分支机构的数量达到一定数量且复杂性远远超过其可能提供的任何值时，就会发生此问题。

什么是生产力？

在这里，我将采取一种不太受欢迎的立场，但总的来说，我的立场是分支机构会产生反作用……在每个人拿出干草叉之前，让我解释一下我对软件项目的“生产率”版本。 生产力正在生产能够提供正价值的边际成本来实现业务目标的软件。 尽管那可能是罗word的，甚至在技术上是不正确的，但我想使用的整体平等公式是：产品生产的所有活动的总和必须小于软件提供的价值。 换句话说，如果花费200万美元来构建/部署某些软件，但是企业只能收回100万美元的价值（通过节省成本或新销售等方式），我会认为这是失败的。

分支用例

作为软件工程师，我想创建一个分支，以便其他开发人员无法看到我在其内部版本中所做的更改。

好吧，因为：

1. 首先，创建分支，将其他人的分支合并到您的分支（可能通过不同的分支）的活动是所有如果您都在同一主干上就可以立即免费获得的东西。
2. 其次，您故意拖延了团队其他成员对变更的了解，这意味着持续集成的整个概念已被抛诸脑后

这给我带来了一个关键问题

您是敏捷还是脆弱？

如果您要分支每个功能或错误并将其合并回去，我会说，您的代码库和/或过程比敏捷更脆弱。

你的想法？

翻译自: https://www.javacodegeeks.com/2019/08/dark-side-git.html

git 打git