问题描述
以下是 git 工作流程的示例:
Here's are examples of git workflows:
- https://github.com/bard/sameplace/wiki/典型-git-workflow
- http://www.nabble.com/Git-workflow-overview-td16340337.html
- http://osteele.com/archives/2008/05/my-git-workflow
假设您想利用错误跟踪器与版本控制系统的集成.在哪里/如何适合这些工作流程.您实际上会在跟踪器中看到什么?
Let's say you wanted to take advantage of bug tracker integration with your version control system. Where/how would that fit into these workflows. What would you actually see in the tracker?
我是 BugTracker.NET 的作者，它像许多其他错误跟踪器(Trac、Redmine、FogBugz)一样与 svn 集成.我们都或多或少地以相同的方式做这件事.但是对于 git，我很难想象与 git 的集成会是什么样子.
I'm the author of BugTracker.NET which like many other bug trackers (Trac, Redmine, FogBugz) integrates with svn. We all do it more or less the same way. But with git, I have trouble imagining what integration with git would look like.
我已经看过一次 github-fogbugz 集成的尝试，但即使是作者也说很明显，FogBugz 是为更传统的 CVS/SVN SCM 系统编写的.因此，提交列表显示并没有真正与 git 兼容".
I've taken a look at one attempt at github-fogbugz integration, but even the author of that says "It's fairly obvious that FogBugz was written for a more traditional CVS/SVN SCM system in mind. As such, the commit list display doesn't really jive with git".
关于 Redmine/git 工作流程的主题:似乎最典型的设置是 Redmine 与任何被认为是中央"存储库的本地克隆一起工作，因此当它们进入这个克隆时它会看到变化.触发器或计划作业会自动推送到 Redmine 的克隆.
A thread about Redmine/git workflow:It seems that the most typical setup is that Redmine works with a local clone of whatever is considered to be the "central" repository, so it sees changes when they make it to this clone. Triggers or scheduled jobs automate the pushing to Redmine's clone.
似乎即使使用 linux 和 Linus，最终还是有一个主要的 git 存储库，可以被认为是仁慈的独裁者存储库:参见 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=总结
Seems even with linux and Linus, there ultimately IS a main git repository that could be considered the benevolent dictator repository: See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
尾声:谢谢大家.根据你们给我的指导，我的 BugTracker.NET 现在包括 git 集成.
EPILOGUE: Thanks everybody. My BugTracker.NET now includes git integration, according to the guidance you folks gave me.
推荐答案
Trac 和 Redmine 都支持与 Git 的集成.它看起来或多或少与 Subversion 支持完全相同.错误跟踪器作为仁慈的独裁者 存储库跟踪一个存储库，它不必关心该位置周围的所有其他克隆.
Trac and Redmine both support integration with Git. It looks more or less exactly the same as the Subversion support. The bug tracker follows one repo as the benevolent dictator repo, it doesn't have to care about all the other clones around the place.
我认为值得一提的一件事是，任何错误跟踪器都需要正确支持 git 分支.在分支上工作是 Git 方法论的重要组成部分，它需要在错误跟踪器中得到支持.Redmine 可以通过补丁来做到这一点，但上次我看(大约一个月前)，它不在主源树中(你只能关注 master).
One thing I do think is worth mentioning is that any bug tracker needs to support git branches properly. Working on branches is such an important part of the Git methodology, it needs to be supported in the bug tracker. Redmine can do this through a patch, but last I looked (about a month ago), it wasn't in the main source tree (you could only follow master).
其他有用的功能将是如何创建和合并分支的图形表示，类似于 gitk 的外观.我不知道有任何错误跟踪器可以进行这种可视化.
Other useful features would be a graphical representation of how branches are created and merged, similar to how gitk looks. I don't know of any bug tracker that does this kind of visualisation.
由 Corey Trager 编辑.我在这里复制/粘贴@Squelch 的回答(我也赞成 @Squelch):
EDIT by Corey Trager. I copy/pasted @Squelch's answer here (I upvoted @Squelch too):
由于 Git 的分布式特性与 SVN 的集中特性相反，每个用户或存储库的副本很可能有不同的分支.现有跟踪器通常具有存储库的本地副本，用作中央参考(仁慈的独裁者")，可以将其视为所有用户的工作副本.
Due to the distributed nature of Git against the centralized nature of SVN, it is quite possible for every user or copy of the repository to have different branches. The exisitnig trackers typically have a local copy of the repository that is used as a central reference ("benevolent dictator") that can be regarded as the working copy for all users.
用户在其本地副本中拥有与跟踪器不同的分支结构是非常可行的.他们可能会选择保留一些私有，仅从他们感兴趣的远程拉取分支，或者将新分支推送到远程(跟踪器).用户甚至可以在他们之间共享远程可能永远看不到的分支.
It is quite feasible for users to have a different branch structure in their local copy from that of the tracker. They might choose to keep some private, pull only the branches from the remote that they are interested in, or push a new branch to the remote (tracker). Users can even share branches between themselves that the remote may never see.
错误跟踪器实际上只能引用它有权访问的存储库.通常这是跟踪器本地的，但也可以从远程存储库拉到跟踪器，并且更难管理.如果它正在访问远程，它只能跟踪它知道的分支，并且除了计划任务之外没有真正启动此任务的方法.这还假设用户也在为其本地副本提供服务.
The bug tracker can really only reference repositories it has access to. Commonly this is local to the tracker, but it is also possible to pull from repositories remote to the tracker, and far harder to manage. If it is accessing a remote, it can only track branches that it has knowledge of, and there is not really a method of initiating this task apart from a scheduled task. This also assumes that users are serving their local copy too.
正如您已经注意到的，计划任务或事件挂钩可用于使用提交日志更新跟踪器以获取详细信息.然后，可以将这些详细信息与跟踪器问题进行匹配，以便根据需要和上文所述进行查看.
As you have already noted, a scheduled task, or an event hook can be used to update the tracker using the commit log for details. These details can then be matched to the tracker issues for viewing as required and noted above.
简而言之，跟踪器通常会看到它当前可以访问的分支上所做的任何更改.使用钩子可以立即看到这些更改，包括创建新分支.在用户推送这些更改之前，它不会查看或跟踪对用户(离线)存储库所做的更改.
In short, the tracker will typically see whatever changes are made on the branches it currently has access to. With a hook these changes are seen immediately including the creation of a new branch. It will not see or track changes made to users (offline) repositories until they push those changes.
@Squelch 结束
END OF @Squelch
这篇关于错误跟踪器/版本控制集成如何与典型的 git 工作流程一起工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！