DVCS 在远程服务器上工作

发布于 2024-09-27 17:41:51 字数 376 浏览 3 评论 0 原文

我的工作场所正在考虑迁移到现代 (D)VCS，这是我正在推动的事情。

我的老板同意这个想法，当前的工作流程是建立一个集中存储库，每个人都可以在任务完成后提交/合并他们的更改，在处理任务时，每个开发人员都可以拥有自己的分支来处理和提交。

问题是他不太喜欢这样的想法：人们只有在将更改推送到共享存储库之前才在工作站上拥有代码。这是因为磁盘故障等原因。

他希望看到的是每个人在服务器上都有自己的分支，当您在本地工作站上提交时，该分支会自动更新。

是否有任何 DVCS 以易于设置的方式支持此功能？

请注意，我个人认为每个开发人员承担备份其代码的责任是完全可以接受的，例如只需将其更改推送到远程服务器上的私有分支。这可以手动完成，也可以使用 cron 脚本自动完成。

原文

分享到QQ

分享到微博

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

发布评论

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

简单爱 2024-10-04 17:41:52

只是为了“我们也是”因素：这在 Mercurial 中是可行的，就像在 bzr 和 git 中一样。只需使用一个提交钩子，在可用时推送到更集中的存储库。像这样的事情：

[hooks]
commit = hg push ssh://path/to/individual/developer/repo

我要注意的一件事是，与通过挂钩强制执行此操作相比，您可以使推送到中央存储库对个人开发人员有吸引力，并且您会发现他们自己做这件事。我为让人们提交/推送（每天/每小时）所做的事情：

确保他们有一个可以推送的存储库，不期望编译/测试通过 - 如果您能让
他们轻松设置，则为检查点存储库在中央服务器上建立他们选择的存储库的持续集成构建 - 如果他们只需点击三下即可轻松开始为他们的个人分支构建更改，那么他们将在每次更改后推动只是为了查看测试suite run
不要因为他们有分支历史而羞愧——良好的 DVCS 使用涉及大量的拉/合并/推周期。如果你让他们使用变基或折叠将 30 个变更集（其中 15 个合并）变成每个功能/错误的一个变更集，那么他们就会被激励将事物保留在本地，直到他们准备好一次拉/合并/推送整个事物，
运行一些非-公共场所的判断指标。没有什么比按代码行对开发人员进行排名更严厉和愚蠢的了，但是可以注意到一些事情，无论是来自所有存储库 RSS 源的聚合 RSS 源，还是获得快速“X 将变更集 Y 推送到存储库 Z 中”的 commits@ 电子邮件别名” 每当有人按下时都会发出消息。这很好，因为人们总是喜欢在加班时享受一点阳光，而在训练结束时的“推动”就可以实现这一点。

Just for the "us too" factor: this is doable in mercurial as it is in bzr and git. Just use a commit hook that pushes to a more central-ish repo when available. Something like this:

[hooks]
commit = hg push ssh://path/to/individual/developer/repo

One thing I'll note is that rather that enforcing this via hooks you can make pushing to central repo attractive to individual developers and you'll find they do it on their own. Things I've done to get people committing/pushing (daily/hourly):

make sure they have a repo they can push to that has no expectations about compiling/tests passing - a checkpoint repo if you will
make it easy for them to set up a continuous integration build of repos of their choice on the central server -- if it's three-clicks-easy for them to start build-on-change for their personal branches then they'll be pushing after each change just to see the test suite run
don't shame them for having a branchy history -- good DVCS use involves a lot of pull/merge/push cycles. If you make them use rebase or collapse to turn 30 changesets with 15 merges into one changeset per feature/bug then they're incentivized to keep thing local until they're ready to pull/merge/push the whole thing at once
run some non-judgemental metrics in a public place. Nothing draconian and silly like ranking developers by lines of code, but something that can be noticed, whether it's an aggregate RSS feed from all the repo RSS feeds, or a commits@ email alias that gets a quick "X pushed changeset Y into repo Z" message whenever someone pushes. That's nice because people always like a little sunshine on their extra-hours-worked and a "push" at the end of session gets that.

回复收藏 0 原文

山川志 2024-10-04 17:41:52

您可以准备一个提交后挂钩（请参阅本地存储库中的.git/hooks/post-commit.sample）以自动将当前分支推送到服务器。

如果这样做，我认为共享服务器上的分支名称应该以开发人员的名称作为前缀，以防止名称冲突。

回复收藏 0 原文

狼性发作 2024-10-04 17:41:52

这听起来与我们目前在 Bazaar 上的设置非常相似，但我认为它可以在 Mercurial 和其他人中使用 Git 中的提交后挂钩或 Mercurial 中的“提交后推送”进行复制。在 Bazaar 中执行此操作的方法是执行以下操作：

# Create a repository
bzr init-repo --no-trees path/to/server/project
# Create the main development branch
bzr init path/to/server/project/trunk
# Create the local working copy (which contains the complete history but is bound to the server copy of trunk)
bzr co path/to/server/project/trunk working-directory-name
# Alternative command that works the same:
bzr branch --bind path/to/server/project/trunk working-directory-name

cd working-directory-name

# Now create a branch for the user to work on
bzr switch -b new-branch
# Hack hack hack
# Commit (gets pushed to server as this is a checkout a.k.a bound-branch)
bzr ci -m "Done stuff"
# Go back to trunk to merge
bzr switch trunk
# Merge
bzr merge path/to/server/project/new-branch
# Commit the merge changes (gets pushed to server)
bzr ci -m "Merged new-branch"

所有分支都将保存在 /path/to/server/project 的存储库中。对本地工作副本的任何提交都会自动推送到服务器。如果您使用 GUI，您可以安装我的 remote-feature-branches 插件，该插件会自动执行使用主干分支创建新存储库并在本地检查它的过程（上面的前三个命令）。

我只使用过一点 Mercurial，但我相信您执行此操作的方法是在服务器上建立一个分支，并在本地对其进行分支并编辑 .hgrc 文件以包括：

[hooks]
commit.autopush = hg push

所有用户都将拥有一个本地副本在本例中包含所有分支，而在 Bazaar 中，本地副本仅包含他们正在处理的分支的历史记录。实现略有不同，但我认为功能大致相同。

This sounds fairly similar to the set-up that we have with Bazaar at the moment, but I think it can be replicated in Mercurial and others using post-commit hooks in Git or "push-after-commit" in Mercurial. The way of doing this in Bazaar would be to do something like this:

# Create a repository
bzr init-repo --no-trees path/to/server/project
# Create the main development branch
bzr init path/to/server/project/trunk
# Create the local working copy (which contains the complete history but is bound to the server copy of trunk)
bzr co path/to/server/project/trunk working-directory-name
# Alternative command that works the same:
bzr branch --bind path/to/server/project/trunk working-directory-name

cd working-directory-name

# Now create a branch for the user to work on
bzr switch -b new-branch
# Hack hack hack
# Commit (gets pushed to server as this is a checkout a.k.a bound-branch)
bzr ci -m "Done stuff"
# Go back to trunk to merge
bzr switch trunk
# Merge
bzr merge path/to/server/project/new-branch
# Commit the merge changes (gets pushed to server)
bzr ci -m "Merged new-branch"

All the branches will be held in a repository at /path/to/server/project. Any commits to the local working copy will be pushed to the server automatically. If you use GUIs, you can install my remote-feature-branches plugin, which automates the process of creating a new repository with a trunk branch and checking it out locally (the first three commands above).

I've only used Mercurial a little, but I believe that the way you'd do this would be to have a branch on the server and to branch it locally and edit the .hgrc file to include:

[hooks]
commit.autopush = hg push

All users would have a local copy that contains all branches in this case, whereas in Bazaar, the local copy would only have the history of the branch that they were working on. Slightly different implementations, but functionally much the same I think.

回复收藏 0 原文