如何使用中央存储库管理备份和监控 Git?

发布于 2024-08-11 18:29:30 字数 662 浏览 6 评论 0原文

我现在所在的团队使用 Git,我们有一个非常好的工作流程。我们有一个中央存储库,有两个分支:dev 和 master。我们创建当地分支机构来处理个别任务。当他们准备好时,我们就合并到开发中。然后,当一切准备就绪时,我们会合并到 master,并标记所有版本。如果多个开发人员需要更直接地合作完成一项任务,我们可以创建另一个(可能是临时的)远程分支,供他们共享补丁。这对我们来说效果很好,但它给我们带来了两个问题。

其中一个问题是备份问题。当然,大部分代码库都已备份。每台拥有存储库克隆的机器都拥有大部分代码。然而,某人在一天中编写的代码在合并到开发并推送之前不会被备份。如果他们正在处理的任务非常重要,那么他们可能需要几天时间才能获得任何值得合并和推送的东西。我们如何确保这个正在进行的代码备份在一个中央安全的地方?只需使用 Git 外部的一些备份解决方案?

第二个问题是监控员工进度的问题。经理希望能够看到开发人员每天编写了哪些代码。如果有一天你没有推出任何东西,那么看起来你一整天都没有做任何事情。我们需要某种方式来展示我们每天的工作,而不会强迫我们提交和推送尚未准备好提交、合并和推送的代码。

我们考虑的一种解决方案是在中央存储库上为我们创建的每个本地分支创建一个远程分支。这可能会起作用,但即使我们定期删除旧的未使用的分支,它也会变得一团糟。管理这一切还需要做很多额外的工作。

我们如何在不中断 Git 工作流程的情况下满足这些业务需求?

I'm on a team using Git right now, and we have a pretty good workflow. We have a central repository with two branches, dev and master. We create local branches to work on individual tasks. We merge into dev when they are ready. Then we merge to master when things are ready, and we tag all of our releases. If multiple developers need to cooperate on a task more directly, we can create another, possibly temporary, remote branch for them to share patches through. This is working out pretty well for us, but it leaves us with two problems.

One problem is the issue of backups. Sure, most of the code base is backed up. Every machine that has a clone of the repository has most of the code. However, the code that someone writes during the course of a day is not backed up until they merge to dev and push. If the task they are working on is non-trivial, it could be days before they have anything merge and push worthy. How do we make sure this work in progress code is backed up in a central safe place? Just use some backup solution external to Git?

The second problem is the issue of monitoring employee progress. The manager(s) want to be able to see what code the developers have written each day. If a day goes buy where you didn't push anything out, it will look like you didn't do anything all day. We need some way to show our work on a daily basis that doesn't force us to commit and push code that isn't ready for committing, merging, and pushing.

One solution we considered is to create a remote branch on the central repo for every single local branch we make. This would probably work, but it would be a big cluttered mess, even if we regularly deleted old unused branches. It's also a lot of extra work to manage all that.

How can we satisfy these business requirements without disrupting our Git workflow?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

素染倾城色 2024-08-18 18:29:30

你可以考虑做这样的事情。使用非分支命名空间进行私有开发人员备份。例如 refs/backups/xxx/* 其中 xxx 是开发人员用户 ID 或缩写或类似内容。

然后,开发人员可以执行 git push origin +refs/heads/*:refs/backups/xxx/* 来备份所有本地分支。

默认情况下,开发人员看不到彼此的私有备份,但如有必要,可以检索它们。

备份推送公式可以通过别名做成git backup命令。

尽管我认为这不是一个好主意,但开发人员的私人分支可以用来查看他的“进度”,这听起来很像微观管理。

编辑:写的时候,感觉很熟悉,然后我就想起了原因。我不久前在回答另一个问题时写了类似的内容: 链接

You could consider doing something like this. Use a non-branch namespace for private developer backups. E.g. refs/backups/xxx/* where xxx is the developers user id or initials or similar.

A developer can then do git push origin +refs/heads/*:refs/backups/xxx/* to back up all his local branches.

By default, developers don't see each other's private backups, but they are retrievable if necessary.

The backup push formula can be made into a git backup command via an alias.

Much as I think it's not a good idea, a developer's private branches can be used to see his 'progress' it sounds a lot like micro-management.

Edit: When writing it, this felt quite familiar and then I remembered why. I wrote about something similar in response to another question a while ago: link.

夏见 2024-08-18 18:29:30
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文