小编Rij*_*ijk的帖子

我已经阅读了有关Integration Manager工作流的内容,它看起来非常适合我们的开发过程(该项目的一位主要开发人员,在开发人员致力于项目存储库之前审查其他开发人员的工作).

但是,有一件事我不清楚.在Pro Git书的这个可视化中,似乎每个开发人员都有自己的(远程)存储库来推送到:

但是,在本章("私人小团队" 一节)中,他们似乎正在使用分支来实现相同类型的工作流程.

它是否正确？我们应该使用哪种策略; 分支机构或多个存储库？我猜想如果你从不同的存储库中提取工作,维护提交的时间表会更难？

桑多夫斯基主张对你的"主要"回购历史非常严格,保持干净,不要在分支和检查点提交的情况下混乱.

您永远不应该将私有分支直接合并到具有vanilla合并的公共分支中.首先,使用重置,rebase,squash合并和提交修改等工具清理分支.

将公共历史视为不可变的,原子的,易于遵循.将私人历史视为一次性和可塑性.

这对我很有吸引力,我正在计划实现一个工作流程,我的同事们每个人都有自己的远程存储库来推送,并在他们完成分支工作并清理提交历史记录时执行拉取请求.随后,我("集成管理器")将这些干净的提交合并到一般开发分支中.

我想这种方法意味着受祝福的回购将不会有除主人和开发分支以外的任何分支.功能分支仅存在于本地存储库中 - 如果需要在分支上进行协作,则可以通过将分支推送到其中一个协作员工的远程存储库来实现.

但是,Pro Git书将其描述为" 公共小型项目" 的工作流程.这是否意味着在我们的案例中使用不同的工作流更好,比如将已完成的分支推送到受祝福的仓库而不是个人存储库？

要明确:我不是要添加不必要的复杂性或开销.我的目标是建立一个工作流程,让我和我的同事可以异步工作,我可以在完成工作时审查他们的工作,并通过评论将其反弹或将其合并到代码库中(如果一切正常).

编辑:显然问的问题不明确,所以我将尝试总结一下:

让我的同事将他们的分支机构直接推送到我们受祝福的存储库(例如,它会以某种方式'污染'它的历史)会有不利之处吗？

我创建了一个钩子，当开发人员将更新推送到他的共享存储库时，该钩子发出通知电子邮件。这封电子邮件包含已更改文件的列表，例如：

A   __classes/Page/Activity.php
M   __config/Scheme.php

我使用以下bash生成的代码：

$(git diff "$newrev"^ "$newrev" --name-status)

这很好。但是，我现在尝试将所有这些移植到著名的post-receive-email hook。该钩子确实具有hooks.showrev配置指令，但是我认为这仅允许在命令中%s使用一次修订号（）。所以这不起作用：

showrev = "git diff %s^ %s --name-status"

必须有一个“ plumbing”命令来执行此操作。谁能指出我正确的方向？:)

在函数调用中设置变量值 - 我没有看到这么多,这被认为是好的做法吗？

function myUpdate($status){
    ...
}

myUpdate($status = 'live');

我个人喜欢它,因为它更具描述性.我反过来更频繁地看到它,即在函数定义中指定默认值.