開発
私が使用しているGithubを介して開発サイクルについて説明します。 今年は3〜14人のさまざまな規模のチームでテストされました。
主なブランチはmasterとdevの 2つです。
masterは安定したブランチであり、いつでも本番サーバーに展開できます。
devは、チームが現在作業しているブランチです。
そのため、開発の開始時には、 masterブランチとdevブランチは同一です。
1.プログラマーが新しい欠陥/機能の作業を開始したら、 devブランチに切り替えて最新バージョンを入手する必要があります。
git checkout dev git pull origin dev
2.たとえば、開発者は認証ページの欠陥の修正を開始したいと考えています。 Githubのエラー番号は1234です。開発者はdevから新しいブランチを作成する必要があります
git checkout -b 1234-bug-login
1234-bug-loginは単なる例です。 最初の単語は欠陥の番号、2番目の単語はバグ/機能、そして問題の説明です。
3.さらに、開発者は引き続きローカルで作業します。変更、コミットなどを行います。 コミットメッセージには、エラー番号と技術的な説明が含まれている必要があります
git add ...list of files... git commit -m "#1234 changing backbone model url"
4.これで、開発は終了しました。次に、変更をGithubに送信する必要があります
git push origin 1234-bug-login
これで、すべての変更がリポジトリにあります。 その後、開発者は、競合することなくマージできるように、 devからブランチを更新する必要があります。
まず、最新の開発ブランチを入手する必要があります
git checkout dev git pull origin dev
そして、 devブランチで発生したすべての変更をブランチに注ぎます（1234-bug-login）
git checkout 1234-bug-login git rebase dev git push -f origin 1234-bug-login
5.すばらしい！ リポジトリ内の競合を解決したブランチ。 ここで、開発者はGithubを使用して1234-bug-loginからdevブランチへのプルリクエストの作成を行います 。 また、プルリクエストの説明にタスク（＃1234）へのリンクを配置する必要があります。
6.プルリクエストが送信され、開発者はコードレビューを行ったり、コメントや説明を書いたりできます。
コメントを修正し、通常の方法でGithubに投稿する必要があります。 プルリクエストは自動的に更新されます。
7.修正には時間がかかることがあり、他の開発者はすでにブランチをdevにマージしています。 この場合、2つのオプションがあります。
-GithubのMerge pull requestボタンがアクティブになっています。 これは、他の開発者の変更が現在の変更と競合せず、これ以上行う必要がないことを意味します。
-[ プルリクエストのマージ ]ボタンは非アクティブです。 手順4）に戻り、変更をマージして、 devブランチから1234-bug-loginに再度送信する必要があります 。
git checkout dev git pull origin dev git checkout 1234-bug-login git rebase dev git push -f origin 1234-bug-login
8.すばらしい！ すべての変更が行われ、誰かがプルリクエストに「マージ」というコメントを書きました。 マージプルリクエストボタンをクリックして、 1234-bug-loginの変更をdevブランチにプッシュします 。
テスト中
9. 1234-bug-loginがdevに入るとすぐに、Jenkins（継続的統合システム）はdevブランチからdevサーバーを自動的に更新します 。 QAはテストを開始でき、その結果、タスクを確認または再発見できます。
10.プルリクエストが多くの変更を行う場合、開発者はJenkinsを使用して、テスターによるテストのためにブランチをqaサーバーにアップロードできます。
発売日
11.本番サーバーをアップグレードする前に、 devブランチをmasterに追加する必要があります。 これを行うには、Githubを使用してdevからマスターへのプルリクエストを作成し、 プルリクエストの マージをクリックします。 前のポイントを満たせば、競合は発生しません。
12.回帰テストが正常に完了した場合、最後のパッケージ（テストが行われたパッケージ）を取得している間に本番サーバーを更新でき、本番サーバーにインストールされます。
13.回帰テスト中にQAがエラーを見つけることがあります。 この場合、ブランチはdevからではなくmasterから作成およびマージされることを除いて、標準スキームに従って修正が実行されます。 リリース後、 masterからdevに修正を追加する必要があります。
git checkout master git pull origin master git checkout dev git pull origin dev git merge master git push origin dev