我是我们网站开发公司的团队负责人,我想在我们的团队中实施Git工作流程.阅读文档和文章我发现以下结构对我们有益:
我们在Bitbucket中有一个存储库.主分支仅被视为包含稳定代码.每个开发必须建立自己的分公司,并实现他的特点/ bug修正自己的分公司.一旦他决定,他的代码准备就绪,他创建了一个很好的分支历史(使用rebase,修改,樱桃挑选等)并将其推送到Bitbucket,在那里创建一个拉动请求到主分支.质量检查验证功能并批准(或不批准)它,然后我验证代码,如果可以,我将他的工作合并为主(通过快进或重新定位以获得更好的提交历史记录).
但是这种方案只适用于单个开发人员在分支机构上工作的情况.在我们的例子中,我们几乎总是有两个开发人员用于一个分支,因为一个开发人员在服务器端(PHP),另一个开发人员在客户端(HTML/CSS/JS).这两者应该如何以一种方式进行协作,使主人的历史保持干净？
服务器开发人员创建HTML文件的基本结构,客户端开发人员需要获得此结构.逻辑上将为服务器dev创建一个分支,并为客户端dev创建自己的分支,基于服务器dev分支.但这意味着,服务器开发人员需要在Bitbucket中发布他的分支,这将使他无法重新定义或更改已经发布的提交.
另一个选择是等待,直到服务器开发人员完成他的工作,发布具有良好提交历史记录的分支并忘记它,并且只有在该客户端dev开始在该分支中工作之后,这将导致时间延迟,这甚至更糟.
您如何在工作流程中处理此类协作？
我不能真正谈到你的帖子中描述的方法的优点,但我可以描述我们如何解决我们在工作中使用的工作流程中的协作编码.
我们使用的工作流程是众多分支之一.我们的结构是这样的:
师父是金; 只有合并主人接触它(更多关于这一点).
有一个dev分支,最初是从master开始的,所有开发人员都会工作.我们不是为每个开发人员提供分支,而是从dev开发功能或票证.
对于每个谨慎的功能(错误,增强等),都会从dev创建一个新的本地分支.开发人员不必在同一分支上工作,因为每个功能分支的范围仅限于该单个开发人员正在处理的内容.这就是git便宜的分支派上用场的地方.
一旦该功能准备就绪,它就会在本地合并回dev中并推送到云端(Bitbucket,Github等).每个人都经常通过开发来保持同步.
我们按周发布时间表,因此每周,在QA批准开发分支之后,将使用名称中的日期创建发布分支.这是生产中使用的分支,取代了上周的发布分支.
一旦QA在生产中验证了发布分支,发布分支就会合并回master(和dev,只是为了安全).这是我们唯一一次接触主人,确保它尽可能干净.
对于我们这个团队来说,这非常有效.希望它有所帮助.祝好运!
我认为仍然没有人真正回答过如何在保持清晰历史的主题分支中进行协作的原始问题。
正确的答案是对不起，您不可能将所有内容放在一起。您只能整理自己的私人本地历史记录，在为其他人发布内容之后，您应该在此基础上继续工作。
在服务器开发人员不关心客户端开发更改的特定情况下，您可能会做的最好的事情是在完成功能之前，将本地分支从开发人员/功能分支中本地分支出来，并在服务器工作的基础上重新构建该部分，或者放松约束然后像您一样切换到其他工作流程;）
我们有一个主要的存储库,每个开发人员都有一个分支.
创建一个分支principal/some_project,然后在每个开发人员的fork,fork/some_project上创建相同的分支名称.
(我们使用smartgit,我们还有一个策略,遥控器被命名为'principal'和'fork'而不是'origin'和'upstream',这只会让新用户感到困惑).
每个开发人员还有一个名为some_project的本地分支.
开发人员本地分支some_project跟踪远程分支principal/some_project.
开发人员在分支some_project和push-to到他们的fork/some_project上进行本地工作,他们不时创建pull请求,这就是每个开发人员的工作如何合并到principal/some_project中.
这样开发人员可以自由地在本地提取/重新绑定并推送到他们的分支 - 这几乎是标准的fork工作流程.通过这种方式,他们可以获得其他开发人员的提交,并可能不时地解决奇怪的冲突.
这很好,现在需要的是一种合并在主体/主体中出现的持续更新的方法(例如紧急修复或在some_project完成之前交付的其他项目).
为了实现这一目标,我们指定了一个"分支引导",他们的角色是使用SmartGit中的merge(而不是pull,rebase)将master中的更新本地合并到some_project中.这也有时会产生冲突,必须解决这些冲突.完成此操作后,开发人员(分支负责人)强制推送到他们的fork/some_project分支,然后创建一个pull请求以合并到principal/some_project中.
一旦该请求被合并,所有在Principal/master上的新提交现在都存在于principal/some_project分支上(并且没有任何重新设置).
因此,下次每个开发人员访问some_project并拉(回想一下,他们跟踪的分支是principal/some_project),他们将获得所有更新,其中包括从principal/master合并的内容.
这可能听起来很长,但它实际上相当简单和强大(每个开发人员也可以只从本地/主人本地合并,但如果一个人这样做更整洁,团队的其余部分生活在一个简单的世界,就像单个开发人员的工作流程) .
京公网安备 11010802040832号 | 京ICP备19059560号-6 