分步集市工作流程

Question

在我工作的地方，我们（大部分）成对工作。我们已经看到了对版本控制的需求，我们将使用 bazaar 作为我们的分布式版本控制系统，因为它具有明显的灵活性。

经过一些实验，我们已经同意，为了建立一个项目，我们应该使用以下步骤：

在服务器上

1. bzr init（初始化项目）
2. bzr add（告诉 bzr 跟踪当前目录中的所有文件，因此在运行此命令之前，请确保您的项目骨架中没有不必要的文件）
3. bzr commit -m "initial commit"（将添加的文件提交到 bzr 进行版本控制）

在开发机器上

1. 在你的本地机器上，做一个 bzr 分支 project_dir

日常生活

我们目前正在尝试建立一个适合我们的工作流程。这是我们约定每天要做的事情：

1. 从 pull_path 下拉最新更改
2. 代码和提交。注意。您的提交将保存在您的本地计算机上。
3. 参见步骤 1。
4. 将您的更改推送到 push_path（注意：push_path = pull_path）
5. 如果有任何冲突：
   
   • 首先尝试bzr resolve。
   • 如果失败，请让您的合作伙伴手动解决（打开 file.OTHER、file.BASE 和 file.THIS 并进行相关更改）。
   • 提交您的更改（bzr commit）
   • 再次推送（bzr push）
   • 重复上述子点 (#5)，直到所有冲突都解决。

就工作流程而言，这是对 bazaar 进行版本控制的正确方法吗？我们遇到了这样的问题：每次其他团队成员将更改推送到服务器时，我们的提交 cmets 都会“更改所有权”。我很确定这不是它应该如何工作的，但这也可能是由于在项目设置阶段选择了某些选项。

作为这里的 VCS 布道者，我正在编写一份供团队使用的指南，特别是随着团队的成长，新人可以使用，如果有一套“适当”的步骤来获得完成工作。非常感谢您在建立一个良好且简单的分步流程以充分利用 bzr 方面所做的贡献。请在此处添加您的贡献。

提前谢谢大家:)

Answer 1

您在服务器和开发机器上运行什么操作系统？和文件系统？ Windows 文件系统的权限，有时所有者/组有时与 unix 文件系统上的相同文件不同。这可能是第一个绊脚石。

集市工作流程：

在 repo 服务器上运行一个主树，并在本地进行结帐：

bzr checkout sftp://path/to/repo/project /var/source/project

在本地/将结帐分支到您的开发环境：

bzr branch sftp://path/to/repo /var/www/project

不要在 checkout 上工作，只在 dev 分支上工作。使用各种 bzr 命令在那里工作和提交。

一旦工作模块/错误修复/任务完成，合并（而不是推送）到主仓库：

//In /var/source/project
bzr merge /var/www/project
//Resolve any conflicts
bzr resolve
//Commit the merge
bzr commit -m "Work module | task | bug fixed"

因为 /var/source/project 是 checkout，所以 repo 服务器上的 repo 会自动更新。这使两个或多个开发人员可以同时处理同一个项目，而无需一直推拉。

Answer 2

我不确定您的提交消息如何更改所有权，如果您进行合并并提交，那么新提交将以进行合并的人的名义进行，但仍会跟踪原始提交。见bzr log -n0