「GitHub実践入門」を読んだ
Gitに関する本です。基本的な概念説明から導入準備、実際の使い方やコマンドの紹介、チームでの利用やGit Flow・Github Flowの紹介などGitの多岐にわたる内容を紹介しています。
この一冊を読めば大抵のことは理解でき、使いこなせるようになります。使い始めのときに読んでおくと学習が捗ります。 実際に使ってみるのが一番わかり易いと思いますので、勉強中の方やGitを利用する予定のある方は本を読みつつ実際にGitHubを触ってみましょう。
プルリクエストの送り方や対応方法なども書かれていて、実際の現場でのフローがわかるのではないかと思います。 入門の内容なので特殊な使い方やいざというときの対処方法はそれほど書かれていません、コンフリクトの解消や間違ったコミットの巻き戻しなどそういった点には注意しましょう。
業務で使ったことがあるので内容はすでに知っているものでしたが、備忘や共有の際にまとまっていると便利なのでこの記事にまとめておきます。
よく使うコマンドのメモ
Gitでよく使うコマンドのメモです。
init
リポジトリの初期化。.git
ディレクトリが生成される。
status
リポジトリの状態確認。
add
ステージに追加。
対象とする範囲を指定できる。.
で現在のディレクトリ以下全部、ディレクトリやファイル名を指定するとその範囲のみが対象になる。
commit
ステージ領域のファイルをコミット。 メッセージは1行目にコミットの内容の要約、2行目が空行、3行目以降が詳細な理由や目的、とするのが一般的です。
-m
でメッセージをオプションに渡せる。
-a
でaddを行っていなくても、自動で変更・削除されたファイルをコミットします。
新規作成したファイルは対象になりません。
--amend
で直前のコミットメッセージを修正できます。
メッセージに「#1」を含めることで該当するIssueに関連付けさせて表示することができます。 また、「fix #1」とすればIssueをCloseできます。
log
リポジトリのコミットログを確認する。
ディレクトリやファイル名を渡すと、その範囲が対象になります。
-p
を付けると差分が表示されます。
-graph
ブランチのマージなどの状況が視覚的に表示されます。
diff
現在のワークツリーとステージ領域の差分を表示。
HEAD
を付けることで、ワークツリーと最新コミットの差分が確認できます。この場合のHEAD
は作業しているブランチの最新コミットを参照するポインタとなってます。
branch
リポジトリのブランチを一覧表示します。 名前を渡すと新規でブランチを作成できます。
-a
でリモートブランチも含めた情報を表示。
-D xxx
xxxブランチを削除します。
checkout
ブランチを切り替えます。
-b xxx
を付けると、xxxという名前のブランチを新規作成し切り替えます。
-
を付けると、1つ前にいたブランチに移動できます。
-b xxx yyy
とするとyyyブランチを元にxxxブランチを作成して切り替えます。origin/xxxを指定して使うことがたまに有ります。
merge —no-ff xxx
xxxブランチを現在のブランチにマージします。
--no-ff
を付けることでマージコミットが発生して、あとからの参照や取り消しがやりやすくなります。
reset
指定した状態にワーキングツリーを戻します。
--hard ハッシュ値
コミットのハッシュ値を指定してその位置まで戻ることができます。
rebase
コミットを押しつぶして改変する
-i HEAD~2
とするとHEADを含めた2つのコミットを対象に合体させて、新しい一つのコミットとして書き換えます。
remote
登録されているリモートリポジトリを確認。参照用の名前を表示する。
-v
でpushとfetchの対象になっているURLを表示
add
ローカルリポジトリに指定したリモートリポジトリを登録。
git remote add origin git@github.com:xxx/yyy.git
でoriginという名前でリモートリポジトリを指定する。
remove xxx
xxxで参照しているリモートリポジトリを削除。
rename xxx yyy
xxxで参照しているリモートリポジトリをyyyにリネーム。
push
リモートリポジトリに送信。
git push -u origin master
とすると、現在のローカルリポジトリの内容をoriginという名前のリモートリポジトリの、masterブランチに送信します。
-u
でupstreamの設定を同時に行うことができ、以降pull・pushコマンドの対象がorigin masterに設定されます。
fetch
現在のブランチにリモートリポジトリのデータを取得。
pull
最新のリモートリポジトリを取得。fetchとmergeを行っている。
clone
リモートリポジトリを取得。 cloneした直後はmasterブランチなはずで、originという名前でリモートリポジトリが参照できる。
tag
タグの一覧を表示
tag xxx
でxxxという名前の軽量タグを作成、現在のブランチの最新コミット(すなわちHEAD)につく
-a
注釈付きのタグとなり、作成者や日付・メッセージなどの情報がつく
tag -a xxx -m 'release'
-m でメッセージを指定できる
tag -a xxx コミットのハッシュ
過去のコミットにタグを付けることも可能
push origin xxx
タグは通常リモートにpushされないので、明示的にpushする必要がある
push origin --tags
ローカルのタグを全部リモートへpush
Gitを用いた開発フローの例
リモートリポジトリのforkは行わないことが前提のフロー。 各メンバーがローカルリポジトリとリモートリポジトリのみ管理すれば良くなるためシンプル。
GitHub Flow
シンプルなワークフローで頻繁にデプロイすることを前提としてものです。覚えやすくとっつきやすいですが、masterブランチの状態をしっかり安全にしておくために注意する必要があります。
シンプルなことも有り高速な開発フローに向いているそうです。
- masterブランチは常にデプロイ可能な状態を保つ。
- 作業を行うときはローカルでブランチを作成してコミット。
- リモートにも同名のブランチを作っておく。
- 定期的にリモートの同名ブランチへpushする。
- 必要であればmasterへプルリクエストを行いレビュー等をする。
- 作業が完了したら、masterへマージする。
新しいブランチはmasterから作成する。ブランチ名はやる内容がわかるようにして、レビュー等を受けやすいようにコミットの粒度をなるべく小さくする。 常にデプロイできるマスターブランチを維持するためにテストやCIがとても重要です。
Git Flow
上記のGitHub Flowよりも結構ややこしいですが、その分実際の現場では役に立つことが多いと思います。 コマンドとしてGit Flowをサポートするツールがあるので、そちらを使うと快適に開発に参加できます。
可能であれば仕組みやフローの理解のために、自分で環境を用意して動かしてみるといいです。
基本的には以下のブランチができます。
- master
- develop
- feature(機能ごとに名前を付ける)
- release(バージョンごとに名前を付ける)
- hotfix(バージョンごとに名前を付ける)
開発からリリースまでの手順の概要は以下です。
- developから作業用ブランチfeatureを作成し作業を行う
- 作業が終わるとリモートのfeatureブランチへpush
- developへプルリクエスト問題なければmergeする
- featureは削除
- リリース分の作業が進んだら、developからreleaseブランチを作成
- releaseにてリリース準備
- リリース準備が終わったらmasterへmergeし、タグを発行
- releaseをdevelopにもmergeする
- masterとdevelopをリモートへpush、tagもpushする
- masterブランチをリリースする
- releaseは削除
- 不具合があった場合はタグやmasterブランチからhotfixを作成して修正
- hotfixで修正をおこない完了したらリモートへpush、masterへプルリクエスト
- hotfixの内容をdevelopにもプルリクエストする
- hotfixは削除
おわりに
会社でGitを初めて導入する際の懸念点やメリットなども紹介されており、他のバージョン管理からの乗り換え時の検討や提案にも役に立つ知識でした。
さまざまなCI関連のツールの紹介や設定方法も書かれており、実際の開発で使えると心強い情報がたくさんありました。 Git Flowなど実際にやって見ないと理解が難しいものもありますので、事前知識として頭に入れた後は機会を見つけて積極的に参加すればすぐに身につくと思います。