我正在尝试为我们的团队制定开发流程。
我们有3/4个不同的开发人员在任何时候都在使用我们的代码库。
我们已经开始使用GIT，我们的想法是，工作不仅仅是实时修复，然后他们分叉主分支。
每个人在服务器上都有自己的开发环境，我们有一个暂存环境，它应该始终是主分支的副本。
开发人员在他们的本地开发，然后合并回主分支，然后应该将他们的更改推送到临时服务器（I want to set up something like this）。
如果所有内容都获得批准，则应立即复制更改。我想以某种方式自动化，不确定如何。我们正在使用GitHub，所以我确信那里有自动部署脚本。
我们只有1个实时服务器，所以如果只有主分支上的已更改文件可以部署到实时服务器，那就太好了。
任何想法如何做到这一点？
这种方法听起来不错吗？
还有其他意见/警告吗？
负载均衡器是否需要做这样的事情？
答案 0 :(得分：4)
我的公司紧随this blog附近。
我们为生产创建主分支。 我的案例是针对网络开发。
我们要做的就是
开发人员从 master
分叉他们的功能/错误git checkout -b feature/featureA
git checkout -b bug/B
通过这种方式，我们将获得已发布的新代码。在登台服务器中，我们使用测试分支。因此，当任何功能想要进行测试时，它将合并到该分支
在登台服务器中，我们使用
git checkout testing
git pull
有发布分支处理热修复，每个热修复都会在合并到主服务器之前合并到此分支。想法是发布分支将在合并到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
这是因为测试分支中的所有内容都准备好部署。因此，当将所有就绪功能合并到发布分支时，现在，您可以进行最终测试。
当一切都在生产时，我们会这样做
git checkout testing
git merge master
git checkout release
git merge master
自动化脚本
我认为你提交代码后可能会考虑.git/hooks/post-commit.sample连接一些脚本？无论如何，我从不使用它。