如何保持某个 git 存储库状态始终可访问？
我正在尝试为一小群人制定用于数据分析的软件协作的规则。重要的是要有一种方法来重现过去某个时刻的代码运行，即恢复到过去的状态（版本控制应该允许的事情）。过去，我们可以通过 svn 实现这一点。然后，我们可以使用用于该运行的 svn 修订号来标记我们的数据分析结果。
有故事讲述了如何通过分支、合并和变基，历史记录会丢失/变得无法访问/获取噩梦同时，为了实验性功能开发而轻松处理分支是我们考虑从 svn 切换到 git 的原因。
那么：我们应该遵循哪些规则来确保我们能够轻松且始终能够检索为给定分析运行的代码状态？仅使用主分支进行分析运行？如果是这样，主分支上应该禁止哪些操作？
编辑：下面解释了两个好的建议：标记重要的提交将使分析透明且可重现（antlersoft）。除了让标签保持安静之外，这不需要新的规则。此标记工作流程不需要变基和合并规则。汤姆·安德森的建议很有用，因为中央存储库应该容纳所有附加标签的代码（这将是一个约定/规则），可以允许其他成员访问这些代码。
I am trying to devise rules for a small group of people collaborating on software that is used for data analysis. It is important to have a means to reproduce the running of the code at some point in the past, i.e. to revert to a state in the past (something that version control should allow). In the past this has been possible for us with svn. We can then tag our data analysis results with the svn revision number used for that run.
There are stories about how through branching, merging and rebasing, histories are lost/made inaccessible/a nightmare to get to etc. At the same time, the easy handling of branching for experimental feature development is what makes us consider a switch from svn to git.
So: What rules should we follow that would make sure we will easily and always be able to retrieve a state of code that was run for a given analysis? Only use the main branch for analysis runs? If so what operations should be disallowed on the main branch?
EDIT: Two good suggestions are explained below: Tagging of commits that are important will make the analysis transparent and reproducible (antlersoft). This requires no new rules other than to leave the tags in peace. This tagging workflow does not require rules for rebasing and merging. Tom Anderson's suggestion is useful in that a central repo that is supposed to house all code that has tags attached (this would be a convention/rule) could serve to allow other members access to these bits of code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
解决此问题的方法不必限制您在任何分支上可以执行的操作。只需使用 git 标签，不要删除或移动它们。标记用于运行每个分析的提交，并记录分析的提交标签（这与您在 svn 中所做的非常相似，除了由您提供的标签名称而不是由 VCS 生成的修订号）。然后，无论您在分支上执行其他操作（变基等），分析的版本及其所有历史记录都将始终可用。
The solution to this doesn't have to involve restricting what you can do on any branch. Just use git tags, and don't remove or move them. Tag the commit you use to run each analysis, and record the commit tag with the analysis (this is very similar with what you do in svn, except instead of a revision number generated by the VCS it is a tag name you supply). Then the version for the analysis and all its history will always be available, regardless of what else you do (rebase, etc.) on the branch.
您需要遵循的唯一规则是永远不要删除历史记录。这意味着永远不要变基，或使用其他一些不太常见的操作。
相反，这意味着永远不要在运行分析的存储库中进行变基（等）。人们可以在其他存储库中自由地重新建立基础。您是否可以建立一个“黄金主”存储库，每个人都可以使用无变基策略将代码推送到该存储库，并使用它来运行您的分析？然后，人们可以在本地开发他们喜欢的代码，并在准备运行时推送到该存储库。对于使用 DVCS 的团队来说，这是一个相当正常的工作流程。
如果人们需要从本地存储库进行分析（可以说是为了发布），那么事情就会变得更加棘手。我建议每个人在本地都有两个存储库，一个用于开发，一个用于分析。开发存储库中允许进行变基，但必须将代码推送到分析存储库才能使用（然后再推送给团队的其他成员）。这有点弱，因为它只是阻止人们在分析存储库中变基的惯例，而对于没有人直接使用的中央存储库，变基就不会发生。
The only rule you would need to follow is to never delete history. That means never rebasing, or using a few other, less common operations.
Rather, it means never rebasing (etc) in the repository from which you run your analyses. People can rebase freely in other repositories. Would it be possible for you to set up a 'golden master' repository, to which everyone pushes code, with a no-rebase policy, and use that to run your analyses? People can then develop code however they like locally, and push to that repository when ready to run. That's a fairly normal workflow for teams using a DVCS.
If people need to run analyses (for publication, as it were) from their local repositories, then things are trickier. I'd suggest that everyone have two repositories locally, one for development, and one for doing analysis. Rebasing is allowed in the development repository, but code must be pushed to the analysis repository to be used (and then on to the rest of the team). That's a little weaker, because it's only convention that stops people rebasing in the analysis repository, whereas with a central repository which nobody uses directly, rebasing just isn't something that will happen.
我知道这个帖子很旧，但我只想澄清一件事......
变基不会删除任何历史记录，也不会删除任何提交。它仅添加新的提交并移动分支引用。
只要提交被任何东西（分支、标签或其他提交）引用，它就会永远存在。
仅当未引用的对象过时（默认情况下为 30 天）并且您执行垃圾收集或类似操作时，才会删除它们。
I know this thread is old but I just want to make one thing clear...
Rebasing doesn't delete any history, and doesn't delete any commits. It only adds new commits and move a branch ref.
As long as a commit is referenced by anything (branch, tag or other commit) it will live on forever.
Only unreferenced objects are deleted if they are old (think it is 30 days by default) and you do a garbage collection or similar.