与 Git 的持续集成 [英] Continuous integration with Git

问题描述

我想在 Git 之上提供集成挂钩，以便在集成失败时拒绝推送.例如，当开发人员推送他的更改时，我想检查项目是否仍然编译成功.

I would like to provide integration hooks on top of Git such that pushes get rejected when the integration failed. For example when a developer pushes his changes, I would like to check that the project still compiles successfully.

目前，我设置了更新后挂钩来进行编译检查.但是，当我想拒绝推送时，我会还原更改并通知开发人员:

Presently, I setup the post-update hook to do the compilation checking. However when I want to reject the push, I revert the changes and inform the developer about it :

git revert --no-edit HEAD
echo "Rejected !"

我的问题是，当另一个开发人员想要推送他的更改时，他必须先拉动从而覆盖他的工作，然后需要发出痛苦的重置/存储命令才能正确合并.
此外，在分支合并的情况下恢复将不起作用(需要 -m 选项)

My issue is that when another developer wants to push his changes, he has to pull first thus overriding his work and then needs to issue painful reset/stash commands to merge correctly.
Moreover, the revert will not work in case of branch merging (which needs the -m option)

我目前的解决方法是，我不是在服务器上恢复，而是将更改合并到另一个分支(这是我的开发人员的默认拉取源):

My current workaround is that instead of reverting on the server, I merge the changes in another branch (which is the default pull origin for my developers):

git checkout integrated
git merge master

实现这一目标的最佳方法是什么?

What is the best approach to achieve this goal ?

推荐答案

最好的方法是为开发者提供他们自己的特性分支，这些分支有更新后的钩子来检查编译，然后将它合并到 master(如果你想在这方面全神贯注，您可以将钩子推送到您手动合并到主控的另一个分支).这样您就不必担心它会被拒绝.在我看来，master 应该只用作发布分支的参考点，而不是每个人都将所有内容推送到的东西.

Best approach for this would be giving developers their own feature branches which have post-update hook that checks the compiling and then merges it into master (If you want to go all paranoid on this you can make the hook push to another branch which you merge to master manually). This way you don't have to worry about it being rejected. In my opinion master should be only used as a release branch a reference point not something that everyone pushes everything to.

这篇关于与 Git 的持续集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！