在我工作的地方,我们(大多数)成对工作。我们已经看到了对版本控制的需求,并且由于其明显的灵活性,我们将使用bazaar作为我们的分布式版本控制系统。
经过一些实验,我们同意为了建立一个项目,我们应该使用以下步骤:
project_dir
我们目前正在尝试建立一个适合我们的工作流程。这是我们每天同意做的事情:
- 从
下拉最新更改pull_path
- 代码和提交。 NB。您的提交将保存在本地计算机上。
- 见第1步。
- 将您的更改推送到
push_path
(NB。push_path
=pull_path
)- 如果有任何冲突:
醇>
- 首先尝试 bzr resolve 。
- 如果失败,请联系您的合作伙伴并手动解决(打开文件。其他,文件.BASE和文件.THIS并进行相关更改)。
- 提交更改( bzr commit )
- 再次按下( bzr push )
- 重复上述子要点(#5),直到所有冲突都得到解决。
就工作流程而言,这是使用集市进行版本控制的正确方法吗?我们遇到了每次其他团队成员将更改推送到服务器时我们的提交注释“更改所有权”的问题。我很确定这不是它应该如何工作,但也可能是由于在项目设置阶段选择了某些选项。
作为VCS的传播者,我正在制定一个指南,供团队使用,特别是随着团队的成长,新人们的使用,并且有一个“适当的”步骤来获得完成工作。您将非常感谢您在建立一个简单的逐步流程以充分利用bzr方面做出的贡献。请在此处添加您的贡献。
提前谢谢大家:)
答案 0 :(得分:2)
您在服务器和开发机器上运行了哪些操作系统?和文件系统? Windows文件系统的权限,有时所有者/组有时与unix文件系统上的相同文件不同。这可能是第一个绊脚石。
Bazaar工作流程:
在repo服务器上运行主树,并在本地执行结帐:
bzr checkout sftp://path/to/repo/project /var/source/project
将结帐分支到您的开发环境:
bzr branch sftp://path/to/repo /var/www/project
不要在结帐时工作,只能在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将自动更新。这使得两个或更多开发人员可以同时处理同一个项目,而无需一直推拉。
答案 1 :(得分:0)
我不确定你的提交消息是如何改变所有权的,如果你进行合并并提交,那么新的提交是在进行合并的人的名下,但仍然会跟踪原始提交。见bzr log -n0