概要
ポートフォリオ制作真っ最中です。
Gitで大苦戦したので、先人の方々の力をお借りし、メモとして再度手順や概念をまとめました。
※僕の追記部分に誤りなどあれば、コメントくださると嬉しいです。
前提
まずローカル環境には3つの状態がある
- 作業ディレクトリ(ワークツリー)
- ステージングエリア
- Gitディレクトリ(ローカルリポジトリ)
1つのトピックの変更をステージングエリアに持っていくことが大事。そしてローカルリポジトリの内容が大事。
-
ブランチモデル①GitFlow
- masterブランチ
- リリース可能な完全品質を保証するブランチ。
- releaseブランチからのマージのみで更新される。
- masterブランチ上で直接作業したりコミットするのはNG。
- developブランチ
- 開発の主軸になるブランチ。
- masterブランチから派生させる。
- developブランチ上で直接作業したりコミットするのはNG。
- releaseブランチ
- リリース作業を行うためのブランチ。
- developブランチから派生させる。
- リリース作業が完了したらmasterブランチとdevelopブランチにマージする。
- マージされたら該当のreleaseブランチは削除する。
- featureブランチ
- 機能追加および修正作業を行うためのブランチ。
- developブランチから派生させる。
- 作業完了してレビューが通ったら、developブランチにマージする。
- どのような機能追加を行うブランチなのかが一目で分かるようなブランチ名を心がける。
- マージされたら該当のfeatureブランチは削除する。
- hotfixブランチ
- リリース済みのものの緊急修正用の作業を行うブランチ。
- masterブランチから派生させる。
- 修正作業完了後はmasterブランチとdevelopブランチにマージする。
- マージされたら該当のhotfixブランチは削除する。
- masterブランチ
-
ブランチモデル②GitHub Flow
- masterブランチ
- リリース可能な完全品質を保証するブランチ。
- git-flowでいうmasterブランチ+developブランチ相当。
- masterブランチ上で直接作業したりコミットするのはNG。
- リリース作業はmasterブランチ上で行う。（releaseブランチは別途用意しない。）
- topicブランチ
- 機能追加やバグ修正を行うブランチ。
- 実際のファイル編集作業はこのブランチ上で行う。
- masterブランチから枝分かれする唯一のブランチ。
- git-flowでいうfeatureブランチ+hotfixブランチ相当。
- masterブランチにマージされたらtopicブランチは削除する。
- masterブランチ
(引用：https://qiita.com/gold-kou/items/7f6a3b46e2781b0dd4a0)
(引用:https://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314)
GitHub flowの利用
基本原則
- masterブランチは、常時デプロイ可能である
- 機能追加、バグフィックスなどは 説明的な名前のブランチをmasterから作成する
- 作成したブランチでローカル開発。小さい単位でこまめにコミットし、リモートにもこまめにPush
- フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、Pull Requestを作成する
- フィードバックや助言が欲しい時に作成するPull RequestをWIP Pull RequestといいPull Request名の頭に [WIP] をつけるのが慣習
- レビューがOKを出してもらったら、masterへマージ
- masterへpushしたら、即デプロイをする
開発の流れのイメージ
【Step1】リモートリポジトリ作成
【Step2】clone
リモートリポジトリをローカルにclone
$ git clone <url>
【Step3】ローカルでブランチきる
ブランチの命名規則はチームやコミュニティそれぞれの流儀があるためそれに従う。
タスク番号とか書いてあれば分かりやすいと思う。
$ git checkout -b <branch name>
【Step4】ファイル編集
機能実装などそのブランチで必要なファイル編集をワーキングツリー上で行う。
【Step5】変更ファイルの確認
現在ブランチでaddやコミットが実施されていないファイルの一覧を表示。
$ git status
【Step6】ステージング環境に追加
ワーキングツリー上で編集したファイルをステージング環境に追加する。
変に-allオプションとかつかわずに焦らず1つ1つaddしていく方がいいと思う。
$ git add <file>
【Step7】ローカルコミット
コミットメッセージの書き方はチームやコミュニティそれぞれの流儀があるためそれに従う。
$ git commit -m "<commit message>"
【Step8】最新リモートリポジトリの内容をローカルリポジトリに適用
pushの前に最新状態があれば取得しておく。
$ git pull --rebase origin develop
（上記で競合が発生した場合）
競合したファイルの修正
競合したファイルを適切に修正する。
他人のコミット内容を変更することになるので修正内容はメンバと確認した方がよい場合もある。
修正したファイルをステージング環境へ移動
$ git add <修正済みファイル>
rebaseを完了する
$ git rebase --continue
【Step9】リモートリポジトリにアップロードする
$ git push origin <local branch>
【Step10】pull request
GitのWEB-UIでレビューアにpull request送信。
【Step11】(必要あれば)レビュー対応してマージまで繰り返す
pull requestに関していただいたレビューに対応する。
Step4から終わるまで繰り返し、最終的にリモートリポジトリ上でマージされる。
【Step12】ローカルを最新化
リモートリポジトリ上でマージされると、コミットが進むため、ローカルの情報をリモートリポジトリに合わせるために最新化する。
$ git checkout develop
$ git pull
以下基本コマンド等を記載
リモートリポジトリの運用
リモートリポジトリのディレクトリをそのまま持ってくる&gitの管理下に置く
git clone <リモートリポジトリのURI>
リモートリポジトリの確認
git remote
リモートリポジトリの確認(URLも表示)
git remote -v
リモートリポジトリの追加
git remote add <登録名> <リモートリポジトリのURL>
リモートリポジトリの削除
git remote rm <リモートリポジトリ登録名>
ブランチの運用
ブランチの作成
git branch <ブランチ名>
ブランチ変更=チェックアウト
git checkout <ブランチ名>
ブランチの作成+チェックアウト
git checkout -b <ブランチ名>
ブランチ名変更
git branch -m <変更前のブランチ名> <変更後のブランチ名>
ブランチ削除
git branch -d <ブランチ名>
ブランチ一覧確認
git branch
マージ(topicブランチをmasterブランチへ@master)
git merge topic
リベース(topicブランチをmasterブランチへ@master)
git rebase master
fetch
pull
ワーキングツリーからリモートリポジトリまでの流れ
ワーキングツリー ▶ ステージングエリア
git add <ファイル名>
git add .
ステージングエリア ▶ ローカルリポジトリ
git commit -m "メッセージ"
ローカルリポジトリ ▶ リモートリポジトリ
git push <リモートリポジトリの登録名/ブランチ> <ブランチ>
git push origin/master master
ローカルリポジトリ ▶ リモートリポジトリ(rebase後など強制的にpush)
git push <リモートリポジトリの登録名/ブランチ> <ブランチ> **-f**
git push origin/master master **-f**
状態確認
前回のコミットと比較した変更内容を表示(ステージングエリア&ワーキングツリーどちらも)
git status
コミットログを確認
git log