您所见过的源代码存储库最聪明的用法是什么?

Pre-tested commits

之前(TeamCity,构建经理):

这个概念很简单,构建系统是你的提交进入主干之间的一个障碍,只有在构建系统确定你的提交没有破坏东西之后,它才允许将提交引入到版本控制中,其他开发人员将同步更改并将其集成到本地工作副本中

我与Hudson进行预测试提交的工作流程涉及三个独立的Git存储库:

• 我的本地回购(本地),
• 规范/中央回购(起源)
• 我的“世界可读”(防火墙内)回购(公共)。

对于预测试的提交,我在世界可读的repo上使用了一个不断变化的分支“pu”(潜在更新)。
在Hudson内部,我创建了一个任务,它对“pu”分支中的更改进行全球可读的repo(public)投票,并在推送更新时启动构建。

我的工作流程是从“开始”更改为“起源”:

* 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

使用此预先测试的提交工作流

(变化) Private Build

与上述原理相同,但构建是在与用于开发的工作站相同的工作站上完成的,但是在克隆的repo上:

如何在长期内不使用CI服务器,同时又不因盯着本地构建而损失越来越多的时间?

对于git来说,这是小菜一碟。
非常 迅速地。
下一次,我们不需要克隆。告诉吉特去拿三角洲。最终结果是:即时克隆。令人印象深刻。

一致性如何?
做一个简单的 git pull ’ 从工作目录将实现,使用delta’s的摘要是,更改已经推送到共享存储库中的位置。
无事可做。再次令人印象深刻。

我们现在有了一个私有构建,不需要维护,不需要额外安装,不依赖IDE,只需一个命令行即可运行。共享存储库中不再有损坏的生成。我们可以回收我们的CI服务器。

对。你听得很清楚。我们刚刚构建了一个无服务器CI。真正的CI服务器的每一个附加功能对我来说都是噪音。

#!/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

Dmitry Tashkinov ,谁有 interesting question on DVCS and CI

我不明白“我们刚刚构建了一个无服务器CI”是如何与Martin Fowler的状态相一致的:
“一旦我自己构建了一个正确同步的工作副本,我就可以最终将我的更改提交到主线,然后更新存储库。然而,我的承诺并没有完成我的工作。此时我们再次构建,但这次是在基于主线代码的集成机上。只有当这个构建成功时,我们才能说我的更改完成了。我总是有可能在我的机器上遗漏了一些东西,并且存储库没有正确更新。”
你是忽略它还是弯曲它?

Martin Fowler in his ContinuousIntegration entry .
但你必须意识到 DVCS adds publication as an orthogonal dimension to branching
David描述的无服务器CI只是Martin详细描述的一般CI过程的一个实现:您不需要CI服务器,而是推送到本地CI运行的本地副本,然后将“有效”代码推送到中心repo。

当您使用所谓的本地CI时,它可能会通过所有测试,因为它是本地的,但稍后会在另一台机器上崩溃。
那是整合吗?我不是在批评,这个问题对我来说很难,我正在努力理解。

@德米特里:“那是整合吗”?

因为您有发布机制,所以如果需要,可以将此类CI链接到另一个CI服务器。反过来,该服务器可以自动推送(如果这仍然是快进)到“中心”repo。

这并不妨碍他为更完整的测试设置更完整的系统集成服务器。

这使得XML文档可以被分支和合并,而现代分布式源代码管理使得所有的优点(冲突检测和解决、审阅工作流,当然还有更改日志等等)都变得容易。将文档的组件及其元数据拆分到它们自己的文件中,避免了允许邻近性产生错误冲突的问题,并且允许Bazaar团队在版本文件系统树中所做的所有工作来处理其他类型的树结构数据。

整个bug跟踪和wiki数据库存储在subversion中,以便能够保存完整的修订历史记录。

http://www.polarion.com/products/trackwiki/features.php