いちばんやさしいGit&GitHubの教本人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

はじめに

今の職場では、ソースコードのバージョン管理システムとしてSVNを使っています。自分が入社する前からずっと使い続けているようですが、今は当時よりも共同作業者の数が圧倒的に増えて、最近ではコミットの度に他に同じコードを編集している人がいないか確認したりとか、一つのブランチにいろんな人が同時に複数の変更を入れてマージが面倒になったりと非効率感が漂っています。
そこで、分散バージョン管理ができるGitを導入出来れば、今の問題が解決できるのではないかと考え、上記の書籍を読んでGitについて学ぶことにしました。
今回の記事は、これを読んで参考になった部分をTwitter上でメモしたものになります。

メモ

年末年始の読書3冊目はこれ！
2019年の目標達成に必要不可欠な1冊なので、今回1番楽しみにしてたやつ！！ pic.twitter.com/OI3nAbWKef
— Shisato (@4310sy) 2019年1月2日

Gitの特徴

大規模なプロジェクトを高速に、そして複数人で並行して扱いやすくした仕組みを持っている。

GitHubの普及により、インターネット上でのスムーズな共同作業も可能。
— Shisato (@4310sy) 2019年1月2日

コミットを指定するためのコミットハッシュ

コミットをする時にSHA-1ハッシュ関数と呼ばれる計算式により割り出されるもの。

ハッシュ値を指定すればそこからコミットを特定出来る。
— Shisato (@4310sy) 2019年1月2日

ローカルにコミットを行い状態を保存するのに用いる場所

ワークツリー
編集の開始地点。新規追加ファイルは、Git管理外の状態。

ステージングエリア(インデックス)
コミットしたいファイル選んで登録する場所。

Gitディレクトリ
それ以降変更されないデータとしてコミットを格納する場所。
— Shisato (@4310sy) 2019年1月2日

さまざまなリポジトリから変更を受け付ける時

リモートリポジトリをクローンしたらブランチを切って、各々が作業しコミット

複数作業を並行して進め、それぞれを任意の時点でリモートに反映

コンフリクトを検知した際に教えてくれる
— Shisato (@4310sy) 2019年1月2日

Git操作専用のGUIクライアント

Sourcetree
GitHub Desktop
IDEのプラグイン
— Shisato (@4310sy) 2019年1月2日

git checkout
ワークツリーの変更を取り消す

git reset
ステージングエリアに入れた変更をワークツリーに戻す

git diff
ワークツリー、ステージングエリア、Gitディレクトリ間の差分を確認する
— Shisato (@4310sy) 2019年1月2日

ステージングエリアとGitディレクトリの差分を確認する時は、

git diff --cachedというようにオプションを付ける。
— Shisato (@4310sy) 2019年1月2日

コミット時などのメッセージを入力する時にエディタを開くように設定する

git config --global core.editor "exeファイルのパス --wait"
— Shisato (@4310sy) 2019年1月2日

エディタを設定しておくと、git commit実行時にエディタが自動的に開く。

オススメのコミットメッセージ形式

1行目に要約
2行目に空欄
3行目以降に詳細説明を書く
— Shisato (@4310sy) 2019年1月2日

エディタを開く必要がない時は、

git commit -mで直接メッセージを指定してコミットする
— Shisato (@4310sy) 2019年1月2日

ワークツリーの変更を取り消すコマンド

git checkout -- ファイルパス or ディレクトリパス

ハイフン２つで直前のコミット状態に戻す働きをする。

ブランチ名を指定するとブランチを切り替える。
— Shisato (@4310sy) 2019年1月2日

ステージングエリアへの登録を取り消すコマンド

git reset HEAD ファイルパス or ディレクトリパス

HEADは最後にコミットした状態を意味する。
— Shisato (@4310sy) 2019年1月2日

.gitignoreファイルで管理しないファイルを設定する

.gitignoreファイルを作って、管理しないファイルやディレクトリを直接指定する

ファイルが配置されたディレクトリ配下のパスにしか効果はない
— Shisato (@4310sy) 2019年1月2日

差分付きでコミット履歴を確認する

git log -p
— Shisato (@4310sy) 2019年1月2日

SSHと公開鍵を用いたサーバ認証

SSHキーを生成
ssh-keygen -t rsa -b 4096 -C "メルアド"

鍵の保存場所を確認して、パスフレーズを設定
確認用に2度入力

公開鍵の保存パスをコピー
clip < 保存パス

GitHubの設定画面でSSH and GPG keysを選択し、New SSH keyをクリック
— Shisato (@4310sy) 2019年1月3日

公開鍵を貼り付ける

タイトルは、どのPCで発行したキーか分かるようにする

確認用コマンドを入力する
ssh -T git@github.com

yesと入力

パスフレーズを入力する

Hi ユーザ名! You've successfully authenticated

と表示されれば成功
— Shisato (@4310sy) 2019年1月3日

フォーク機能によるリポジトリの複製

フォーク元に変更を変更することも出来る。

複製元のリポジトリのページを開いてForkクリック

完了すると、自分のアカウントページに同一内容のリポジトリが作成される。
— Shisato (@4310sy) 2019年1月3日

リモートリポジトリの設定を確認する

git remote -v

ローカルリポジトリに紐付いたクローン元のリモートリポジトリURLがoriginとして表示される

ローカルリポジトリに対して複数のリモートリポジトリを設定できる

それぞれを識別するための名前が必要。初期値でoriginという名前がつく。
— Shisato (@4310sy) 2019年1月3日

プルリク時のブランチ選択

レビュー対象のトピックブランチとマージ先ブランチを設定する。
マージ先ブランチがあるリポジトリからフォークしたものである場合は、リポジトリも設定する必要がある。
デフォルトではフォーク元のリポジトリが指定されるので、自分のアカウントのリポジトリに変更する。
— Shisato (@4310sy) 2019年1月4日

プルリク作成時はレビュアーを設定する。
レビュアーに指定できるのは、リポジトリのコラボレータとなっているアカウント。権限を与えたいアカウントをSetting→Collaborators→Add collaboratorから追加する。

追加されたアカウントにはInvitationメールが届くのでAcceptする。
— Shisato (@4310sy) 2019年1月4日

プルリクの内容はブラウザ上でレビューする。

Files changedで差分の確認
Commitsでコミット履歴を確認
コメント欄にメッセージを記入してCommentする
— Shisato (@4310sy) 2019年1月4日

レビュー後のマージ実行者はチームによって異なる。
レビューした人がマージするか、レビューを依頼した人がするか。
どちらを選択するか決める際は、マージの影響をしっかり把握した人が、適切なタイミングで操作を行えるルールになっていることが大切。
— Shisato (@4310sy) 2019年1月4日

GitHubでのコミュニケーションには、略語を活用する文化がある。
最も有名なのは下記。

「問題ないと思う」「よいと思う」の意味で「LGTM(Looks Good To Me」。
プルリクの内容を承諾する意味でレビュアーがLGTMを伝えるのは定番。
— Shisato (@4310sy) 2019年1月4日

レビュー結果の種類

Comment
疑問点が見つかり、依頼者に確認をしたい時

Approve
マージを承認する時

Request changes
修正依頼を出す時
— Shisato (@4310sy) 2019年1月4日

３種類のマージ方法

Create a merge commit
全てのマージコミットが履歴に残る。

Squash and merge
トピックブランチを一つにまとめた後でマージする。

Rebase and merge
ブランチの分かれ元をベースブランチの最新コミットに変更して。
マージ後の履歴が一直線になる。
— Shisato (@4310sy) 2019年1月4日

プルのフェッチの違い

プル
リモートからの取得内容がワークツリーまで反映される。
パソコン内のファイルが即座に書き替わる。

フェッチ
ローカルリポジトリまでしか取得内容が反映されない。
すぐにマージしたくない、内容を確認したいだけの場合はフェッチを使う。
— Shisato (@4310sy) 2019年1月4日

git pullコマンド
git pull プル先のリモートリポジトリプルするブランチ
例: git pull origin master

git fetchコマンド
git fetch フェッチ先のリモートリポジトリ
git fetch origin
— Shisato (@4310sy) 2019年1月4日

ローカルに持っていないリポジトリをリモートから取得したい場合はプルができないのでフェッチを使う。
— Shisato (@4310sy) 2019年1月4日

git checkoutコマンドでも同様のことが出来る。この際は、-bオプションがなくてもGitが自動でローカルにリポジトリを作成する。

checkoutは特定のバージョンをワークツリーに反映させる。ワークツリーにあるファイルがmodifiedである場合は、不要な上書きを防ぐためにcheckoutを出来ないようにする。
— Shisato (@4310sy) 2019年1月4日

GitHubフロー

作業ごとに一つだけトピックブランチを作って、細かい単位でサイクルを回す。頻繁なデプロイを前提とする。

masterブランチからトピックブランチ作成
↓
変更したい内容をコミット
↓
プルリクを作成してレビュー、デプロイ
↓
masterブランチにマージ
— Shisato (@4310sy) 2019年1月4日

作業ごとにブランチを使い分ける理由

・作業の影響範囲を限定できる
・リリースしたい部分だけを抽出するのが楽
・片方にバグがあったときは、それだけを元に戻せる
— Shisato (@4310sy) 2019年1月4日

別作業用に追加でブランチを作成するときは、他の作業と切り分けるために、一度masterブランチに戻ってからブランチを作成する。
— Shisato (@4310sy) 2019年1月4日

作業が途中のブランチの作業を再開する際は、その時点での最新のmasterブランチの情報を取り込んでからにする。
— Shisato (@4310sy) 2019年1月4日

git mergeコマンドで取り込む

git merge 取り込みたいブランチ
例: git merge master
— Shisato (@4310sy) 2019年1月4日

git statusコマンドでコンフリクトの発生を確認できる。
コンフリクトしているファイルはboth modifiedと表示される。

コンフリクト発生時のyouとthem
youはマージ元である現在使用中のブランチ
themはマージ先のブランチ
— Shisato (@4310sy) 2019年1月4日