Apr*_*che 5 git collaboration version-control backup workflow
我现在正在使用Git的团队,我们有一个非常好的工作流程.我们有一个中央存储库,有两个分支,dev和master.我们创建了本地分支机构来处理各个任务.当他们准备好时我们合并到dev.然后我们在事情准备就绪时合并为主人,并标记我们的所有版本.如果多个开发人员需要更直接地合作完成任务,我们可以为他们创建另一个可能是临时的远程分支来共享补丁.这对我们来说非常好,但它给我们留下了两个问题.
一个问题是备份问题.当然,大部分代码库都是备份的.每个具有存储库克隆的计算机都具有大部分代码.但是,有人在一天中写入的代码在合并到dev和push之前不会备份.如果他们正在处理的任务非常重要,那么他们可能需要几天时间才能完成任何合并和推动.我们如何确保将正在进行的工作代码备份到中央安全位置？只需使用Git外部的一些备份解决方案？
第二个问题是监控员工进度的问题.经理希望能够看到开发人员每天编写的代码.如果在没有推出任何东西的情况下购买一天,看起来你整天都没有做任何事情.我们需要某种方式来每天展示我们的工作,这不会迫使我们提交和推送尚未准备好提交,合并和推送的代码.
我们考虑的一个解决方案是在我们制作的每个本地分支的中央仓库上创建一个远程分支.这可能会有效,但即使我们经常删除旧的未使用的分支,它也会是一个混乱的混乱.管理所有这些也需要做很多额外的工作.
如何在不中断Git工作流程的情况下满足这些业务需求？
你可以考虑做这样的事情。使用非分支命名空间进行私有开发人员备份。例如refs/backups/xxx/*，其中 xxx 是开发人员用户 ID 或缩写或类似名称。
然后，开发人员可以git push origin +refs/heads/*:refs/backups/xxx/*备份他的所有本地分支机构。
默认情况下，开发人员看不到彼此的私有备份，但如有必要，可以检索它们。
git backup备份推送公式可以通过别名做成命令。
尽管我认为这不是一个好主意，但开发人员的私人分支可以用来查看他的“进度”，这听起来很像微观管理。
编辑：写的时候感觉很熟悉，然后我就想起来为什么了。我不久前在回答另一个问题时写了类似的内容：链接。