ワークフロー

テンプレートワークフロー

# 템플릿 워크플로우
프로젝트 매니저: 이름

개발 사이트: url
개발 사이트 배포 브랜치: 브랜치 이름

라이브 사이트: url
라이브 사이트 배포 브랜치: 브랜치 이름

개발 티켓을 시작하는 브랜치: 브랜치 이름
핫픽스 티켓을 시작하는 브랜치: 브랜치 이름
작업 업데이트 시 사용 명령어: git 명령어
검토 후 작업 병합 시 사용 명령어: git 명령어

Reference

書/Git for Teams(チーム向けGit)/エマ・ジェーン・ホグビン・ウェストビーゼ/崔炳賢駅/漢光メディア

https://velog.io/@kim-jaemin420/Git-branch-naming

1.2010年Vicent DriessenのGit Flow

ブランチのタイプ

master

develop

featrue-*

hotfix-*

release-*

improvement-*

bugfix-

ブランチプロセス

のプライマリブランチでは、ブランチは「開発」ブランチです.

開発者は、開発ブランチに自由に提出できます.

機能が実装されている場合は、開発ブランチで機能-*ブランチをブランチします.

「開発」ブランチで、-*ブランチを解放して、

の導入を準備します.

テスト

で発生したエラー修正はrelease-*ブランチに直接反映されます.

のテストが完了したら、「パブリッシュ」ブランチを「マスター」と「開発」にマージします.

このプロセスは、デプロイ時間が明確なプロジェクトに特化しています.デプロイされていない場合は、開発者は自由にコミットできますが、デプロイにrelease-*ブランチが作成されている場合は、エラーの修正に集中します.これは、従来の開発プロセスでは問題ありませんが、継続的な統合/導入が可能になる今日では問題が発生します.これは、デプロイ可能なバージョンを作成するために前処理が必要だからです.配置する場合は、角度をつかんで攻撃する必要があります.

2.2011年GitHub Flow

GitHub Flowは、コミットまたはプロパティブランチでテストを完了します.
Pull RequestとCode Reviewでプライマリブランチにマージします.
したがって、release-ブランチを必要とせずに常に導入性を維持

3. Git flow + GitHub flow

GitHub Flowのように、開発者はブランチを統合し続けています.
統合テストが完了したコミットのみを選択的に配置できませんか?
GitHub Flowにstagingブランチを追加し、インタラクティブなRebaseを使用
必要なコミットはdevelopブランチからのみ選択できます.

develop:Pull Requestコミットは自由にアップロードされます.

は、導入ではなく機能実装に焦点を当てたブランチであり、導入サイクル中にコミットできます.

staging:ブランチは、デプロイメントのコミットが決定された場所です.stagingブランチは変更されません.したがって、継続的な統合/導入機能が実装されている場合、どのチームメンバーも、分割バージョンを使用して導入可能バージョン

をテストできます.

製品:フェーズブランチでテストが完了したら、本番ブランチをフェーズブランチにマージするだけで導入が完了します.

4.Resbaseを利用したGit Flow

developブランチでfeature/featureAブランチをマージします.
この場合--squashオプションを使用して複数のコミットを1つのコミットに統合することで、開発ブランチに新しいコミットを作成します.
開発ブランチでは、各プロパティにコミットがあり、Bugfixごとにコミットがあります.
これは,後で選択的にコミットをstagingブランチに移行する際に容易に区別できるようにするためである.
開発は導入によって停止することはできません.導入に関係なく、開発ブランチはアップグレードと統合を継続します.デプロイにマージされたブランチをコミットするのがstagingブランチです.

5.Gitを使用する際の注意事項

Git GUIと比較してGit CLIを使用します.Git CLIを直接使用してコマンドを入力すると、Git GUIツールに隠されている機能も知ることができます.Git GUIを使用するには、端末にコマンドを1つずつ入力する必要はありません.これは便利ですが、可能であればCLIを使用して理解して使用することをお勧めします.

Git pullコマンドの代わりに、
git fetch--pruneコマンドとgit mergeコマンドの組み合わせを使用します.
git pullはgit fetchとgit mergeを内部で自動的に処理できるショートカットです.できるだけgit fetchを使用して他のスタッフのタスクを取得し、グラフィックの状況を確認してmergeすることをお勧めします.

依存PRはできるだけ避けなければならない.
依存性がある場合は、まずPRを通過できるかどうかを疑う必要があります.
仕方がない場合は、後続のブランチを前のブランチとともに再構築する必要があります.

bash-git-promptなどのツールを使用すると、Gitステータスを端末ですばやく表示できます.
現在どのブランチで作業しているか、階層ファイルが存在するか、競合が発生しているかをすばやく決定します.

pretty git log(https://coderwall.com/p/euwpig/a-better-git-log)により、端末はGitコミット図を直感的に見ることができる.
端末で図面をコミットする際に必要なツールを表示します.
コラボレーション中のトピックブランチの再設定は、他のスタッフを苦境に陥れる可能性があります.
rebaseは、元のコミットを削除し、新しいコミットを作成する破壊的なタスクです.
複数のユーザーが作業中のブランチを強制的に再有効にした場合、一部のユーザーは消失したコミットで操作する必要がある場合があります.

Reference

Git Workflow戦略(https://blog.ull.im/engineering/2019/06/25/git-workflow-for-ci-cd.html)

継続的統合/導入(CI/CD)

https://milooy.wordpress.com/2017/06/21/working-together-with-github-tutorial/