看了几个git的工作流，感觉都不太符合自己目前的流程。目前我们有三个环境：生产环境、测试环境、本地环境。开发人员在本地开发，push到测试环境，测试人员就在测试环境测试 验收。
目前我们只有十几个人的小团队，没有一个具体的版本发布流程，所以也没有到哪天发布什么版本，哪个任务在什么时间完成之类的，每个人的工作更像是在做hotfix，做完一个小功能或者修复一个小bug就直接推送到develop分支，任务指向测试人员去测试环境测试，没问题了 直接把develop合并到master，发布！ 这个流程在人少的时候还可以，人稍微多一点，就牵扯到 我有个功能要上线了 而另一个功能还在测试阶段，master和develop没法合并，只能等测试结束...
基于功能分支的模式，好像可以解决上述的问题，切一个分支做功能或者修复bug，合并到develop去测试，测试通过后合并到master，这时候master就可以随时推送到生产环境。但是另一个问题，团队里的成员水平参差不齐，不能让每个人都有权限合并到master，需要有人去review代码，也就是说，合并到master这个操作只能由一个人或几个人去操作而不是全部，然而可能每天产生的分支就有很多，小到修改一行文字可能都是一个分支，手工去合并这些小分支又是一个很大的工作量.这个跟提交pr的方式有点类似，不够高效...
有什么方法能让测试人员及时看到你的修改方便测试 ，又能随时随地的！有选择性的！往生产环境合并代码？
仅有的幸福2017-05-02 09:39:28
これは私たちのワークフローと非常に似ていますが、バージョンをリリースする特定の時期を規定しており、バージョンがリリースされた後、開発者は独自のブランチで開発し、マージするときにスーパーバイザーにマージリクエストを送信します。監督者が同意した場合は開発ブランチに進み、テスト後、問題がなければメインブランチに進みます。
世界只因有你2017-05-02 09:39:28
あなたの質問は普通だと思います。たとえば、A さんが関数を作成した場合、開発ブランチをプッシュして、誰がこのバージョンをリリースしても、関数全体が完成しているかどうかをテストする前に、それをテストする必要があります。 、彼はこのプロセスを経る必要があります。開発時にテスト中のコードがあり、緊急のバグ修正をプッシュする必要がある場合、通常 2 つの方法があり、1 つは開発時にテスト中のコードを選択する方法、もう 1 つは緊急ブランチを使用する方法です。
阿神2017-05-02 09:39:28
git Cherry-pick
このコマンドはコミットを選択的にマージできます。通知テストの場合、マージ後に指定した電子メール アドレスに電子メールを自動的に送信するように GitHub を構成できます。
git チェリーピック
