この文書は、社内のGit Flowルールを統一するために書かれました。この方法は、純粋なGit Flowを導入するものではなく、Git FlowとGitLab Flowの両方をミックスしたもので、長年にわたって会社のベストプラクティスとして取り組んできたものです。リポジトリの履歴をきれいに読みやすく保ち、変更とプロジェクトのライフサイクルをよりよく管理するのに役立ちます。
この文書は、社内のGitFlowルールを統一するために書かれました。この方法は純粋なGitFlowを導入するものではなく、GitFlowとGitLab Flowの両方をミックスしたものであり、長年にわたって会社のベストプラクティスとして取り組んできたものです。リポジトリの履歴をきれいで読みやすいものにし、変更点や プロジェクト ライフサイクル。
リポジトリの初期化
リポジトリを初期化した後 開発する そして マスター ブランチがデフォルトで含まれていない場合は、それを追加する。developブランチには、開発用の コード これは、新機能を含む master ブランチのミラーです。masterには安定版のコードが含まれ、本番状態を表します。どちらも寿命は無限で、Git Flowの他のブランチと比べて、削除されることはありません。適切な保護ルールを設定する マージ前にプルリクエストのレビューが必要 そして マージ前にステータスチェックの合格が必要.また、選ばれた人だけに許可することもできます。 チーム メンバーが変更をマスターにマージする。
$ git init
$ git commit --allow-empty -m "最初のコミット"
$ git checkout -b develop master
注： 例えば、利用可能な環境を表すために、さらに無限ブランチを追加することがプロジェクトにとって重要な場合もある。しかし、可能であれば「2つのルール」を守ってください。
特徴的な枝
ある機能を使って作業を開始する場合、まず、自分の 開発する ブランチを同期させた。
$ git checkout develop && git pull --rebase
次に、featureブランチにチェックアウトします。指定されたスキーマにそれぞれ名前をつけてください： 機能-JIRA-TASK-ID または、そのルールを破って別の名前をつけることもできます。この場合、release、hotfix、bugfix、development、master ブランチに予約されているパターンと衝突しないようにしてください。JIRA タスク ID を保持することで、機能ブランチをより効果的に管理できるようになります。
$ git checkout -b feature-JIRA-TASK-ID develop
このブランチは、指定した機能が開発され、その後親ブランチにマージされる限り存在するはずです。ローカルブランチにコミットするには、このコマンドに従ってください：
$ git add .
$ git commit -m "JIRA-TASK-ID: タスクの説明"
早く頻繁にコミットする」ルールに従って、ローカルブランチにコミットを追加することをお勧めします。しかし、最終的には JIRA タスクを表す単一のコミットにまとめなければなりません。頻繁にコミットすることは、開発履歴を管理するのに役立ちます。機能の準備ができたら、ブランチを開発するために Pull Request をオープンしましょう。まず、ローカルブランチをプッシュします：
$ git push origin feature-JIRA-TASK-ID
ブランチの準備ができたら プルリクエスト GitHubのこの記事に従ってください： https://help.github.com/en/articles/creating-a-pull-request
プルリクエストを開く前に、以下を確認してください：
- a 適切な記述 通常は、次のようになる。 JIRAタスクにリンクするしかし、現在のコードに関連する有用な情報を含めることもできる。
- サークルCI ステップは正常に通過した
- あなたの チームメンバーが割り当てられた - チームメンバー全員をアサイニーに含めるのは良い習慣です。
- その 査読者が選ばれた - レビュアーの人数はチームによって異なる
- あなたのコードは実際にレビューの準備ができている 最後にコードを見て、リファクタリングすることが残っていないかもう一度考え、ローカルでテストする。 そして、次のステップに進む準備ができていることを確認する。
- そこには マージ競合がなく、ブランチがdevelopで最新である。 - もしあれば、まずそれを解決すること
$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # squash には -i フラグを使用する。
$ git push -f origin feature-JIRA-TASK-ID 1TP63F フラグがリモートリポジトリを上書きするので、注意してください。
- 重要なコミットだけを残す - 各コミットは、例えばJIRAタスクで表現されるべきである、 JIRA-TASK-ID: 新機能の設定； であるべきだ。 リベース中につぶれた あなたのブランチとdevelopブランチ
- を持っている。 適切なデスティネーション・ブランチを選択
- をお忘れなく。 JIRA タスクのステータスを変更する
機能ブランチのマージ
あなたの変更をdevelopブランチにマージする時が来た：
- プルリクエストが選ばれたチームメンバーによって承認された
- すべてのテストが正常に終了
- マージ競合はなく、コミット履歴も正常です。
これは、プロジェクトマネージャーか機能開発者のどちらかが行うことができる。マージを行うには、以下の手順に従ってください：
$ git checkout develop
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID
これで JIRA タスクのステータスを変更できるようになりました。
リリース
リリースブランチは、現在のリリースの責任者が作成する必要があります。通常、リリースは定期的に作成されます。 スプリント ライフサイクル。
セマンティック・バージョニング
リリースブランチに適切な名前と対応するタグをつけるのは、最初のうちは簡単なことではありません。セマンティック・バージョニング (https://semver.org/)を使用することで、より良い制御が可能になり、gitの履歴を読みやすくなります。バージョン文字列は MAJOR.MINOR.PATCH スキーマに従って作成されます：
- MAJOR - 互換性のないAPIの変更を表す変更
- マイナー - 後方互換性のある方法で新機能を追加する。
- PATCH - 後方互換性のあるバグ修正の追加
また、ベータブランチやレガシーブランチなどの特別な接尾辞を使用したり、プレリリースを作成したりすることもできます。その場合は、1.1.0-beta.4、1.1.0-beta.5、1.1.0-alphaなど、適切な名前をつけてください。
リリースの作成
releaseブランチはdevelopブランチの子であるべきで、バグフィックスに関連するコミットだけを含むことができる。
ブランチ名はリリース・バージョンに基づき、接頭辞にreleaseをつける： リリース-MAJOR.MINOR.PATCH. リリースブランチは 自動と手動の両方で完全テスト にある。 ステージング環境.バグが発生した場合、これは適切な修正をプッシュしてプロセス全体を再実行する最後の機会です。それから、package.json のようなファイルに現在のリリースバージョンの文字列の変更を加えて、リリースコミットをプッシュする必要があります。また、CHANGELOG.md ファイルにも影響を与えるべきです。これは、適切なリリースの前にすべての変更を追跡し、マージ処理が完了したときに GitHub リリース用のコンテンツを準備するのに役立ちます。単一ファイルのアップデートは、リリースのすべての変更点を3つのカテゴリに分類して構成する必要があります: 機能、修正、メンテナンスです。
しかし最初のステップでは、developブランチとmasterブランチの両方が最新であることを確認する。
$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P
$ git add .
$ git commit -m "製品 名称 M.M.Pリリース"
$ git push origin release-M.M.P
この時点で、リリースブランチを持つ master に別のプルリクエストを作成することにしてもよい。リモートマシンですべてのテストがうまくいくかどうか、追加でチェックするのもよいだろう。
$ git checkout master
$ git merge release-M.M.P
$ git tag -a M.M.P # 追加メッセージは -m フラグで設定できます。
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P
次に GitHub のリリースページに移動し、"Draft new release" ボタンを押します。表示されたフォームで、現在のバージョンのタグを選択し、リリースのコミットと同様のリリースタイトル (Product Name M.M.P release) と、CHANGELOG.md ファイルに基づいた適切な説明を設定します。公開プロジェクトの場合、説明には現在のリリースに含まれるすべてのPRのリストを含める必要があります。
リリースブランチでバグフィックスが適用された場合は、developブランチを更新してください：
$ git checkout develop && git merge master
$ git push origin develo
ホットフィックスとバグフィックス
バグとホットフィックスの主な違いは、対象ブランチである。
バグ修正
バグ修正は、リリースブランチにパッチを当ててから master にマージしてください。まず、現在の feature ブランチからブランチを作成します。ローカルに最新のブランチがあることを確認してください。
$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P
その後、必要な変更をコミットする。プロセスが終了したら、プルリクエストを作成してリリースブランチを対象とします。feature branch のセクションのガイダンスに従ってください。最終的なコミットタイトルは、指定されたスキーマに合わせる必要があります：「Bugfix M.M.P: 問題の本質の修正" です。プルリクエストが承認されたら、それを現在のリリースにマージします。
$ git checkout release-M.M.P.
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
ホットフィックス
masterブランチでHotfixを行うには、対象となるブランチがmasterブランチになったことを念頭に置きながら、バグフィックスとよく似た手順を踏む必要があります。
$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P は現在のリリースを表します。
そして、通常の開発ステップに従い、プロセスが終了したら master ブランチをターゲットとしてプルリクエストを作成します。最終的なコミットは、指定されたスキーマ "Hotfix X.Y.(Z + 1)：問題本質の修正".すべてのチェックポイントが正常に通過したら、master にマージします。このステップはバグフィックスの場合とは異なり、現在のリリースバージョンをバンプする必要があります。
$ git checkout master && git pull --rebase
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # 追加メッセージは -m フラグで設定できます。
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop
カンニングペーパー
リポジトリ開設
$ git init
$ git commit --allow-empty -m "最初のコミット"
$ git checkout -b develop master
$ git push origin develop
$ git push origin master
特徴
$ git checkout develop && git pull --rebase
$ git checkout -b 機能-JIRA-TASK-ID develop
開発とコミットの開始
$ git add .
$ git commit -m "IRA-TASK-ID: Task description" #initial commit
$ git push origin feature-JIRA-TASK-ID
プルリクエストを開く
リベースとプルリクエストの準備
$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # squash には -i フラグを使用する。
$ git push -f origin feature-JIRA-TASK-ID 1TP63F フラグがリモートリポジトリを上書きするので、注意してください。
変更をマージしてブランチを削除する
$ git checkout develop # ブランチは、この段階で develop ブランチと同期しておく必要があります。
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID
リリース
$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P
リリースコミットを作成する
$ git add .
$ git commit -m "製品名 M.M.P release" #initial commit
$ git push origin release-M.M.P
プルリクエストを開く
変更のマージ、リリース、ブランチの削除
$ git checkout master #ブランチはこの段階でmasterブランチと同期する必要があります。
$ git merge release-M.M.P
$ git tag -a M.M.P #追加メッセージは-mフラグで設定できます。
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P
バグ修正
$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P
$ 修正をコミット
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" 1TP63初期コミット
$ git push origin bugfix-M.M.P
プルリクエストを開く
変更をマージしてブランチを削除する
$ git checkout release-M.M.P #ブランチは、この段階で現在のリリースブランチと同期させる。
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P
ホットフィックス
$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P は現在のリリースを表します。
$ 修正をコミットする
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" 1TP63初期コミット
$ git push origin bugfix-M.M.P
プルリクエストを開く
変更のマージ、リリース、ブランチの削除
$ git checkout master # ブランチは、この段階で現在の master と同期させておきます。
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # 追加メッセージは -m フラグで設定できます。
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop
続きを読む
