#author("2022-02-24T14:14:55+00:00","default:admin","admin") [[GitHub:https://github.co.jp/]] -[[Githubのwikiを使ってみよう!:https://qiita.com/developer-kikikaikai/items/cf7394a6ebaedca63c2b]] *チーム開発 [#qe09dac8] -[[Githubでチーム開発するためのマニュアル:https://qiita.com/siida36/items/880d92559af9bd245c34]] *ブランチモデル [#t7072bee] -[[Gitのブランチモデル(git-flow, GitHub Flow, GitLab Flow)のブランチ名まとめ:https://www.ninton.co.jp/archives/3304]] -[[Gitブランチモデルの比較と使い分け:https://yukke722.hatenablog.jp/entry/2020/11/06/084720]] -[[Gitにおけるブランチ戦略について調べてみた:https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea]] -[[Gitの運用方法の有名な3パターンについての考察:https://kohei.life/git-flows/https://kohei.life/git-flows/]] -[[キャスレーの社内開発で利用するgitのブランチモデルとかPull Requestの簡単な解説とか:https://www.casleyconsulting.co.jp/blog/engineer/53/]] -ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン -ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる -リモートブランチの名前から、なんのためのブランチかを推測しやすくなる **Git-flow [#y8040cce] -[[Git-flow ~Gitのブランチモデルを知る~:https://tracpath.com/bootcamp/learning_git_git_flow.html]] -[[Git Flowの推奨はもう止めましょう!:https://itnews.org/news_contents/please-stop-recommending-git-flow]] ***masterブランチ [#nbaaf525] -git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる -誤って直接コミットしてしまわないように注意 ***developブランチ [#nab9cfea] -develop ブランチは、開発の中心となるブランチ -開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる -master ブランチ同様、直接このブランチにコミットすることはないので注意 -リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく ***featureブランチ [#ua2b196a] -feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ -ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる -ブランチの名前は、変更の内容がすぐに分かるような名称にする -develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。 ***releaseブランチ [#u9d7633a] -release ブランチは、その名の通り製品をリリースするために使うブランチ -製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。 -リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ(バージョンなど)をうちましょう。その後、release ブランチは削除します。 ***hotfixブランチ [#z06aab7c] -製品のリリース後に不具合が見つかった場合は master ブランチから直接 hotfix ブランチを切って緊急の修正を行う -修正完了後に master ブランチと develop ブランチにマージして、リリースタグ(マイナーバージョンなど)を打ち、その後 hotfix ブランチを削除する -派生元が master になるだけで、操作的には release ブランチと同様 ***supportブランチ(オプション) [#v35ca0e4] -プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる -support ブランチでは、旧バージョンの保守とリリースを行う -サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う **GitHub Flow [#t1725947] ***masterブランチ [#ee0ac5cf] -現在の製品のメインブランチ -常にデプロイ可能な状態 ***featureブランチ [#s0fba90a] -新しい作業を開始するときに、わかりやすい名前のブランチをmasterから分岐 -ローカルでコミットして、同じ名前でリモートにもpush -フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成 -他のメンバーがレビューして確認したら、masterへマージする -masterにマージしたらデプロイできる **GitLab Flow [#h2267557] **その他 [#rfae5d48] -[[GitFlowは使わない!シンプルな「GitFeatureFlow」を紹介します:https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama]] *アピール [#za2ed615] -[[エンジニアの転職にgithubって必要なの?丁寧に解説:https://www.rstone-jp.com/column/1031no1/]] -[[Githubのアカウントはエンジニアの転職に必要?メリット・デメリットを紹介!:https://www.geekly.co.jp/column/cat-preparation/1901_046/]] -[[エンジニアが転職する場合GitHubのアカウントを持っていると有利って本当?:https://www.geekly.co.jp/column/cat-preparation/2007_006/]] -[[エンジニアの転職には欠かせなくなってきたGitHubって?:https://axxis.co.jp/magazine/31303]] -[[GitHubアカウントを履歴書に載せる時の3大注意点【エンジニア転職】:https://tenshoku-seikou.jp/github/]] -[[エンジニア転職のFindy:https://findy-code.io/]]