我们正在努力为我们的git项目（所有网站）提供正确的工作流程。
我们有5个开发人员（前端和后端）同时处理30多个项目（实时站点和测试版网站），每个项目都完成了多项任务，每个任务都由多个开发人员处理（通常在那里）是前端和后端之间的来回）
我们目前的工作流程如下：
pull dev branch
work on task
commit to dev branch
push dev
deploy dev branch to staging site
repeat ad infinitum
当测试版网站上的功能最终被客户批准时：
cherry pick commit/commits in to master (We can not merge development branch in to master as there will be mulitple pieces of code in the development branch that are not ready for live.)
push master
deploy master to live
Pray.
在客户批准之前，其中一些提交可以在开发分支中进行数周（甚至数月）。到这时主分支已经大规模地改变了，当给出“上线”批准时，开发人员不记得提交与指定任务有什么关联！到那时，他们收到的冲突等数量是压倒性的。
此外，一般来说，“go live”任务被赋予1 dev，但是他们不知道具体任务的提交是什么。
我们使用分支来实现大部分功能，并且看起来运行良好，但是通常会在很长一段时间内发生一个小的变化，因此不会创建任何分支。
我们最终会在实时网站上出现错误，这些错误往往会直接在FTP上修复，因为没有人信任这些存储库。也迷失/覆盖工作。
问题
GIT适合我们吗？
我们应该使用其他东西吗？
或者我们只是需要让我们的流程正确吗？
答案 0 :(得分：1)
您应该维护staging分支。如果它是master的快速修复，您应该从master创建一个分支。将此代码合并到staging并部署staging以进行客户端测试。 staging批准后master合并go live。
如果不是快速修复，那么您应该从task-branch创建dev并在完成后将其合并到staging。部署它以进行客户端测试，并在master批准后将其合并到go live。
答案 1 :(得分：0)
Git适合您，但您的工作流程可以进行优化。
使用易于使用和配置的GitLab CI。
你应该让你的分支开发人员合并来自子分支的更改。
所以架构就像：
您的开发人员必须开发一个名为User-Product-Wishlist的功能，然后，他将创建从最新的Dev分支派生的分支user_product_wishlist。一旦他做了，他也会从他的分支到Dev分支创建一个拉/合并请求，我们稍后会看到这个。
在你的开发人员完成他的任务之前，他肯定会在其分支上推送几个提交 在最终推送到服务器之前，他必须将自己的分支重新设置为只有一个并且干净的提交 他检查了他所做的提交量并运行git命令（x是提交量）：
git rebase -i HEAD~X
对于他所做的所有更改，只会提交一次，很高兴不是吗？
现在我们的功能的提交历史是干净的，他可以推动远程分支上的工作：
git push origin user-product-wishlist -f
-force（-f）选项总是在rebase之后使用，因为它会更改提交时间戳历史记录，因此我们需要覆盖服务器上的先前版本。
现在是时候在您的团队进行代码审查或您可能处理的任何其他检查之后接受拉/合并请求。如果你看到拉/合并请求有冲突，因为其他开发人员将他们的功能合并到dev中，你必须使用远程Dev分支重新定义你当前的分支，所以：
git rebase origin/dev
解决冲突如果你有，如果没有，你可以推动你的分支在服务器上更新它：
git push origin user-product-wishlist -f
现在您可以接受拉/合并请求并在DEV分支上合并。
即使在合并分支等之后，您仍将在Dev分支上保留一个干净的提交历史记录......
如果您需要回滚到特定版本，查看您的提交历史记录会更容易！
现在由您决定何时部署到分段或生产
如果您有多个要测试的功能，可以在服务器上创建不同的拉/合并请求签出此分支，一旦经过测试和确认，您就可以合并。