什么是你见过的源代码库的最聪明的使用？
这实际上源于我之前的问题，其中一个答案让我想知道人们如何以不同的方式使用scm / repository来进行开发。
预先testing的提交
之前（TeamCity，build筑经理）：
这个概念很简单，构build系统在你进入trunk的提交之间是一个障碍，只有在构build系统确定你的提交没有破坏事物之后，它才允许提交被引入到版本控制中，其他开发者将同步将这些变化整合到当地的工作副本中
之后（使用像Git这样的DVCS，这是一个源代码库）：
我使用Hudson进行预testing提交的工作stream涉及三个独立的Git仓库：
- 我当地的回购（本地），
- 规范/中央回购（起源）
- 和我的“世界可读”（在防火墙内）回购（公共）。
对于预先testing的提交，我使用了一个不断变化的分支，名为“pu”（潜在更新）的世界可读的回购。
在Hudson的内部，我创build了一个可以在“pu”分支中查询世界可读的repo（public）的工作，并且在推送更新时启动构build。我从开始到原点的工作stream程是：
* hack, hack, hack * commit to local/topic * git pup public * Hudson polls public/pu * Hudson runs potential-updates job * Tests fail? o Yes: Rework commit, try again o No: Continue * Rebase onto local/master * Push to origin/master 使用这个预先testing的提交工作stream， 我可以将大部分testing需求卸载到构build系统的机器集群，而不是在本地运行，这意味着我可以花大部分时间编写代码，而不是等待testing自行完成机器在编码迭代之间 。
（变化） 私人build筑 （David Gageot，Algodeal）
与上述相同的原则，但构build是在同一个工作站上完成的，而不是用于开发的工作站，但在克隆的回购上：
如何不长期使用CI服务器，而不会因为在本地构build而耽误了越来越多的时间？
用git，这是一块蛋糕。
首先，我们将工作目录克隆到另一个文件夹。 Git 非常快速地完成拷贝。
下一次，我们不需要克隆。 只要告诉git得到增量。 净结果：即时克隆。 令人印象深刻。一致性呢？
从工作目录执行一个简单的“git pull”，将会使用delta的摘要，实现已经在共享库上推送的更改。
没事做。 令人印象深刻。当然，当构build在第二个目录中运行时，我们可以继续处理代码。 无需等待。
我们现在有一个不需要维护的私人版本，不需要额外的安装，不依赖IDE，只需要一个命令行。 共享存储库中没有更多损坏的构build。 我们可以回收我们的CI服务器。
是。 你听得很清楚 我们刚刚build立了一个无服务器的CI。 真正的CI服务器的每个附加function对我来说都是噪声。
#!/bin/bash if [ 0 -eq `git remote -v | grep -c push` ]; then REMOTE_REPO=`git remote -v | sed 's/origin//'` else REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'` fi if [ ! -z "$1" ]; then git add . git commit -a -m "$1" fi git pull if [ ! -d ".privatebuild" ]; then git clone . .privatebuild fi cd .privatebuild git clean -df git pull if [ -e "pom.xml" ]; then mvn clean install if [ $? -eq 0 ]; then echo "Publishing to: $REMOTE_REPO" git push $REMOTE_REPO master else echo "Unable to build" exit $? fi fi
对DVCS和CI有一个有趣的问题的 Dmitry Tashkinov问道：
我不明白“我们刚刚build立一个无服务器的CI”与马丁·福勒的状态是否一致：
“一旦我自己构build了一个正确同步的工作副本，我可以最终将我的修改提交到mainline，然后更新这个repository，但是我的提交并没有完成我的工作，此时我们再次构build，但是这个在基于主线代码的集成机器上运行一次，只有当这个构build成功的时候，我们才能说我的修改已经完成，总是有机会丢失我的机器上的某些东西，导致版本库没有正确更新。
你忽略或弯曲吗？@Dmitry：我不会忽视也不会忽略Martin Fowler在其ContinuousIntegration条目中描述的过程。
但是你必须认识到， DVCS增加了出版作为分支的正交维度 。
David描述的无服务器configuration项只是Martin详细描述的一般configuration项过程的一个实现：不是configurationCI服务器，而是推送到本地configuration项运行的本地副本，然后将“有效”代码推送到中央仓库。@VonC，但是这个想法是在本地运行CI，特别是不会错过机器之间的转换。
当您使用所谓的本地configuration项时，它可能会通过所有的testing，只是因为它是本地的，但是稍后在另一台机器上就会中断。
那么它是整合？ 我不是在这里批评，这个问题对我来说很难，而且我正在努力去理解。@德米特里：“那么它是整合的”？
这是一个整合的层次，可以帮助摆脱所有的基本检查（如格式问题，代码风格，基本的静态分析检测，…）
由于您拥有该发布机制，因此，如果需要，可以将该types的configuration项链接到另一个configuration项服务器。 该服务器反过来可以自动推送（如果这仍然是快进）到“中央”回购。David Gageot不需要额外的级别，在部署架构（PC-> PC）方面已经是目标，只需要基本types的CI级别。
这并不妨碍他设置更完整的系统集成服务器以进行更完整的testing。
我的最爱？ 一个未发行的工具，使用Bazaar（一个非常深思熟虑的显式重命名处理的DSCM）通过将数据存储表示为目录结构来跟踪树形结构数据。
这使得XML文档可以被分支和合并，所有的优点（冲突检测和解决，审查工作stream程，当然还有更改日志logging等）通过现代分布式源代码控制变得容易。 将文档的元素及其元数据分割到自己的文件中，避免了允许邻近区域产生虚假冲突的问题，并且使得Bazaar团队将所有的工作放到版本化的文件系统树中，以处理其他types的树形结构数据。
Polarion Track＆Wiki …
整个错误跟踪和wiki数据库存储在颠覆，以便能够保持一个完整的修订历史。
