首先,如果你有10-15个正在进行的项目,它们现在是如何相互合作的呢?
Git通过提供分支来解决这个问题。因此,每个实验将被单独分离在自己的分支上,并基于主分支或dev分支。这也有助于使它们更容易合并。
那么推荐的工作流程是什么呢?很简单,只需使用一个中央git仓库即可。
我建议以生产代码为基础构建中央git仓库,然后移植具有潜力的“实验”。或者让实验者在新分支上合并它们,然后帮助他们提交并推送分支。
然后,要更新生产环境,您需要从主分支拉取。要更新开发服务器,您需要从开发分支拉取。不再使用SFTP。功能分支实验可以根据需要切换到开发,甚至更好的是,可以仅在每个开发人员正在运行和测试的本地副本上使用。
这与git无关,但似乎缺少了整个图片的一部分,因为你们一直依赖SFTP,而这并没有版本控制:一旦你有了一个版本控制系统,不再重要的是检出存储在哪里以及提交提交在哪里,只要它们被推送到中央仓库。现在,您可以在本地主机上运行网站的本地副本来运行实验。它将非常快速和可访问。在你实际拉取提交并更新它们之前,它不会破坏开发服务器或生产服务器,因此你可以非常自由和强大地进行实验,使用本地分支在本地机器上。假设您正在处理网站,则可以使用别名创建完全本地的副本到您的hosts文件中。所以我有一个完全本地的网站http://nw.local,它映射到一个包含git仓库的文件夹中。如果我想进行实验,我就会git branch experiment;git checkout experiment
,然后开始编写代码并提交,如果我喜欢结果,我就会将提交变基或合并到dev分支并推送。然后我经常删除该分支,并启动一个新的分支,具有新的或类似的实验功能。
master
分支。dev
的分支,并以master
分支为基础。它反映了您产品的最新稳定版本,并且在任何时间点上,dev
分支应该是master
+ 即将发布的功能。有了这个结构,您现在需要建立一个协议来测试和部署所有正在进行中的项目。branchFeatureF
的新分支。这需要从origin/master
分支创建,因为那是稳定版本。X在他的功能上工作了几天,感觉它已经准备好测试了。很好,现在将其推送到dev
分支。这就像推送到master
一样好,但由于您仍处于测试阶段,因此在dev
分支上工作以在进入master
之前进行测试。
所有QA都在开发分支上完成。在修复任何错误后,功能F现在已准备好发布,因此是时候将特性分支branchFeatureF
合并到master
中并部署您的代码了 - 太棒了。