開発
私が使用している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