使用分布式版本控制时构建排序 [英] Build sequencing when using distributed version control

问题描述

现在，我们使用Perforce进行版本控制。它具有一个我们可以用来引用构建的严格增加变化数字的方便功能，例如如果构建至少为44902，将得到错误修正。

我想切换到使用分布式系统（可能是git），以便更轻松地在家中进行分支和工作。 （这两种方法对于Perforce来说都是完全可能的，但git工作流程有一些优点。）因此，虽然分支开发将被分配，并且不会引用通用的修订版序列，但我们仍然会保留一个主git回购，需要在创建构建之前进入。

保持严格增加构建ID的最佳方法是什么？我能想到的最直接的方法是有一些post-commit钩子，当主repo更新时它会被触发，并且它会注册新的树对象（或提交对象的哈希）？我是新手git）与一个集中的数据库交付id。 （我说的是数据库，但我可能会用git标签来做，并且只是寻找下一个可用的标签号或者其他东西，所以数据库实际上就是.git / refs / tags / build-id /。 ）

这是可行的，但我想知道是否有一个更简单或已经实现的或标准/最佳实践的方式来完成此操作。第二个建议使用 git describe 来解决。假如你有一个明智的版本控制策略，并且你没有对你的仓库做任何疯狂的事情， git describe 将永远是单调的（至少和你一样单调） ，当你的修订历史是一个DAG而不是一棵树）并且是唯一的。

一点示范：

  git init 
 git commit --allow-empty -m'Commit One。'
 git tag -a -m'Tag One。'1.2.3 
 git describe＃=> 1.2.3 
 git commit --allow-empty -m'Commit Two。'
 git describe＃=> 1.2.3-1-gaac161d 
 git commit --allow-empty -m'Commit Three。'
 git describe＃=> 1.2.3-2-g462715d 
 git tag -a -m'Tag Two。'2.0.0 
 git describe＃=> 2.0.0 
  

输出 git描述由以下组件组成：

1. 可从您要求描述的提交中获得的最新标记


2. 提交和标记之间的提交数量（如果非零）


3. 提交（的缩写）ID（如果＃2不为零）

<＃>＃2是什么让输出单调，＃3是什么使它独一无二。当commit 是标签时，＃2和＃3被省略，使得 git describe 也适用于产品发布版本。

Right now, we are using Perforce for version control. It has the handy feature of a strictly increasing change number that we can use to refer to builds, eg "you'll get the bugfix if your build is at least 44902".

I'd like to switch over to using a distributed system (probably git) to make it easier to branch and to work from home. (Both of which are perfectly possible with Perforce, but the git workflow has some advantages.) So although "tributary development" would be distributed and not refer to a common revision sequencing, we'd still maintain a master git repo that all changes would need to feed into before a build was created.

What's the best way to preserve strictly increasing build ids? The most straightforward way I can think of is to have some sort of post-commit hook that fires off whenever the master repo gets updated, and it registers (the hash of) the new tree object (or commit object? I'm new to git) with a centralized database that hands out ids. (I say "database", but I'd probably do it with git tags, and just look for the next available tag number or something. So the "database" would really be .git/refs/tags/build-id/.)

This is workable, but I'm wondering if there is an easier, or already-implemented, or standard/"best practice" way of accomplishing this.

解决方案

I second the suggestion of using git describe. Provided that you have a sane versioning policy, and you don't do any crazy stuff with your repository, git describe will always be monotonic (at least as monotonic as you can be, when your revision history is a DAG instead of a tree) and unique.

A little demonstration:

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

The output of git describe consists of the following components:

1. The newest tag reachable from the commit you are asking to describe
2. The number of commits between the commit and the tag (if non-zero)
3. The (abbreviated) id of the commit (if #2 is non-zero)

#2 is what makes the output monotonic, #3 is what makes it unique. #2 and #3 are omitted, when the commit is the tag, making git describe also suitable for production releases.

这篇关于使用分布式版本控制时构建排序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！