开发流程，部署，GitHub

Question

4

我正在为我们的团队制定一个开发流程。

我们有3/4个不同的开发人员在任何时候都在我们的代码库上工作。

我们已经开始使用GIT，想法是如果一项工作超过了现场修复，那么他们就会分叉主分支。

每个人都有自己的服务器开发环境，我们有一个暂存环境，它应该始终是主分支的副本。

开发人员在本地开发，然后合并回主分支，主分支应该将其更改推送到暂存服务器 (我想设置类似这样的东西)。

如果一切都被批准，那么更改应该被复制到生产环境。我希望以某种方式自动化此过程，但不确定如何。我们正在使用GitHub，所以我相信那里有自动化部署脚本。

然而，我们只有1个生产服务器，因此仅将主分支上的更改文件部署到生产服务器将是很好的选择。

您有什么好的建议吗？

这种方法可行吗？

有其他评论/警告吗？

在这种情况下，负载均衡器是否必要？

- iKode

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- scalopus · Accepted Answer

根据这篇博客，我的公司与其最近。

我们为生产创建一个主分支。 我的情况是用于Web开发。

我们采取的步骤是

开发人员从主分支中派生他们的功能/错误修复

git checkout -b feature/featureA
git checkout -b bug/B

通过这种方式，我们可以获取包含已发布代码的最新代码。在测试服务器中，我们使用testing分支。因此，当任何功能需要进行测试时，都会合并到该分支中。

在测试服务器中，我们使用什么？

git checkout testing
git pull

有一个发布分支处理热修复，每个热修复都会在合并到主分支之前合并到这个分支。这个想法是，在合并到主分支之前，发布分支将打包一些提交，如果出现问题，只需使用类似于以下命令：

git reset --hard HEAD^

暂时的。

让我们来看看我的完整工作步骤

git checkout master # Go to Master
git checkout -b feature/New  # New branch

老板发来邮件，要求修复关键 bug。

git stash 
git checkout master
git checkout -b hotfix/a

做事情

git commit
git checkout release
git merge hotfix/a
git checkout master
git merge release # In case that you want to pack all ready to production

生产中

git tag -d previous
git tag previous
git pull

糟糕！不工作了

git checkout previous

新的提交已合并

git checkout master
git pull

继续我的工作

git checkout feature/New
git stash pop #Restore workspace
git commit
git checkout testing # ready to mix a test
git merge feature/New

准备发布新功能

git checkout release
git merge feature/New

这是因为测试分支中的所有内容都已准备好部署。因此，当将所有准备好的特性合并到“发布”分支时，现在你可以进行最终测试。

当一切准备就绪进入生产阶段后，我们会...

git checkout testing
git merge master
git checkout release
git merge master

自动化脚本

我认为你可以查看.git/hooks/post-commit.sample，以便在提交代码后挂钩一些脚本？不管怎样，我从未使用过它。