开发流程、部署、GitHub

Question

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

我们有3/4的分散开发人员随时在我们的代码库上工作。

我们已经开始使用GIT，我们的想法是，这项工作不仅仅是一个实时修复，然后他们就会派生出主分支。

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

开发人员在其本地进行开发，然后合并回主分支，然后主分支应将其更改推送到临时服务器(I want to set up something like this)。

如果全部获得批准，则应实时复制更改。我想以某种方式将其自动化，但不确定具体如何实现。我们使用的是GitHub，所以我相信会有自动化的部署脚本。

不过，我们只有一台实时服务器，所以如果只将主分支上更改过的文件部署到实时服务器上就更好了。

你知道该怎么做吗？

这种方法合理吗？

是否还有其他意见/警告？

负载均衡器需要做这样的事情吗？

Answer 1

我的公司关注最近的this blog。

我们创建用于生产的主分支。我的案例是关于web开发的。

我们要做的一步是

开发人员从master派生其功能/错误

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

通过这种方式，我们将获得已发布行中已有的新代码。在临时服务器中，我们使用testing分支。因此，当任何特性想要进行测试时，它将合并到该分支

在临时服务器中，我们使用

git checkout testing
git pull

有处理热修复的release分支，每个热修复都会在合并到主分支之前合并到这个分支。这个想法是release分支将在合并之前打包一些提交给master，如果出现问题，它只需使用如下命令

git reset --hard HEAD^

暂时的。

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

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

来自老板的修复关键错误的电子邮件

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

这是因为测试分支中的所有东西都已准备好部署。因此，当将所有就绪特性合并到release分支时，现在就可以进行最终测试了。

当一切都投入生产的时候，我们做

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

自动执行脚本

我想你可能会在提交代码后在.git/hooks/post-commit.sample中寻找一些脚本？不管怎么说，我从来不用它。