9:42 PM投稿記事の長さ:枕草子 冒頭 × 45.4個 くらい

GUI から CUI へ解脱して始める Git 生活

サムネイル画像

皆様、いかがお過ごしであろうか? この前書いた Qiita の記事がバズってご満悦の野地である。読んでくれた方々に改めて感謝。

このブログではバズったといえる記事はほとんどないが、代わりに長期的に読まれる記事を細々書いていく予定なので今後も乞うご期待。

今回は筆者が今まで仕事で使ってきた Git クライアントである Sourcetree を解脱して Git Bash に乗り換えた際に得た知識を紹介したいと思う。

CLI ならではの操作感がクセになるので、Git コマンドの勉強も兼ねて試してみてはいかがだろうか。

能率だ通信速度だに興味がなくても。映画の世界で見るような黒い画面を使用するプログラマーに憧れがあるのであれば今すぐこの記事に記載されている全コマンドを覚えて最強の「それっぽさ」を手に入れよう。スタバで映えます(野地調べ)。

なお、この記事では基本的な Linux コマンドの説明は行わない上に、Git の基本的な使用方法については取り扱わない。

cdls などは確実に使用することになるかと思われるので、まだ Linux コマンドを使用したことが無い場合は前もって勉強しておこう。

また、中盤からは Git Bash 関係なく Git コマンドの説明になるので、Mac 使いのあなたもターミナルを起動して一緒に解脱の準備ができる。

ドーザーもマカーも仲良く GUI の俗世からおさらばしよう。

  1. Git を CLI 環境で操作するメリットとデメリット
  2. Git Bash のインストール
  3. リポジトリの作成・クローン
  4. ブランチの管理
  5. ステータス・差分の確認
  6. ステージング・コミット・プッシュ
  7. ログの確認
  8. フェッチ・プル・マージ・チェリーピック
  9. スタッシュ
  10. まとめ

Git を CLI 環境で操作するメリットとデメリット

先にデメリットについて書いておこう。慣れるまでは GUI アプリケーションからの操作に比べて10倍以上の時間がかかることだ。

どんなツールであろうと慣れるまではトライ & エラーを繰り返すことになるのは当たり前だが、CLI 系のツールは直感的ではなく、メッセージも英語であることが多いため特に苦労することになるだろう。

既に CLI に慣れていたとしても今まで Git クライアントが隠蔽してくれていた Git コマンドを直接打ち込んで操作する必要があるので Git コマンド自体の勉強コストもある。

逆に慣れれば GUI ツールで操作するよりも素早く Git を操作することができるようになるのがメリットになる。

当然 CLI による操作なのでマウスをほぼ(あるいは全く)使用しないで作業が完結する上、貧弱なマシンパワー or リモートでの操作もサクサク動作するので最終的な作業スピードは向上するだろう。

そして必然的に Git コマンドを理解することになるので、エラーが起こった際のググり力・解決能力が段違いとなるはずだ。

Git Bash のインストール

既に Sourcetree をインストールしたことがあるなら Git Bash も一緒にインストールされているのでこの章は飛ばしても大丈夫だ。

Git Bash 及び Git 環境はhttps://gitforwindows.org/からインストールできる。

このページの「Download」ボタンからダウントードできるインストーラの指示に従ってインストールを進めよう。

途中で選択肢がいくつも出てくるが、「Adjusting your PATH environment」以外はデフォルトの設定で大丈夫だ。

「Adjusting your PATH environment」は「Git form the command line and also from 3rd-party software」をチェックしておこう。これで Linux コマンドが使用できるようになる。

リポジトリの作成・クローン

GitHub 等を使用するなら、リモートリポジトリの作成はブラウザから行うため説明は不要だろう。

しかし自前のサーバーにリモートリポジトリを作成するなら Git Bash から作成することができる。

もし事前にサーバーをネットワークドライブとして割り当ててないのであればエクスプローラーのサイドバーから「PC」を選択した後、メニューに出現する「ネットワークドライブの割り当て」でサーバーを登録しておこう。

まずは Git Bash を開き、cd コマンドでリモートリポジトリにしたいディレクトリに移動しよう。

そこで git init --bare --shared

を実行するとリモートリポジトリ用の設定でリポジトリの初期化が行われる。

--bare はリポジトリを監視するファイルを置くワーキングディレクトリではなく、ファイルを共有する専用のベアリポジトリとして設定するオプションで、 --shared はリモートリポジトリ用のパーミッション設定を行うものとなる。

これが終わったら今度は実際に監視するファイルを置くローカルディレクトリへ移動して

git init

を実行。これでファイルの変更が Git によって監視されるので、今度はそれを push する先を指定するために、

git remote add 任意のリポジトリ名 リモートリポジトリのパス
例: git remote add origin /z/var/www/html/test

を実行しよう。これでローカルリポジトリに対して「任意のリポジトリ名」でリモートリポジトリが登録されたのでファイル変更の push が可能になる。

例で設定したこの origin という名前は Git がデフォルトで使用する名前なので、リモートリポジトリを一つしか使わない場合はこの名前を使用するのが無難だろう。以降の説明もリモートリポジトリの名前として origin を使用していく。

ブランチの管理・プッシュ

ブランチの確認・表示

この時点でCLI上に現在のブランチとしてmasterが表示されているだろう。

git branch

と実行すると現在のブランチ一覧と、現在のブランチが表示される。

git branch -r

と、-r オプションを付ければリモートのブランチ、

git branch -a

と、-a オプションを付ければローカルとリモートのブランチ両方が表示される。

ブランチの作成・切り替え

現在はローカル・リモートともに master ブランチしか存在しないかと思うので、作業用ブランチとして develop ブランチを作成してみよう。

ローカルブランチを作成するには

git branch develop

と実行すれば develop が作成される。

その後 develop にチェックアウトするには

git checkout develop

と実行する。

ちなみに上記二つを一気に行うには

git checkout -b develop

と、git checkout-b オプションをつけると実現できるので慣れたら使用してもよいだろう。

develop ブランチに切り替えたら今度はリモートリポジトリに develop ブランチを作成してみよう。

git branch コマンドは主にロカールブランチを操作するコマンドなので、リモートブランチを操作する場合は git push を使用する。

なんのファイル追加・変更をしていない状態で構わないので develop ブランチにチェックアウトしている状態で

git push origin develop

と実行すれば、

Total 0 (delta 0), reused 0 (delta 0)
To W:/var/www/html/test
* [new branch] develop -> develop

のように origin リモートリポジトリへ develop ブランチが作成される。

ブランチごとにデフォルトのリモートリポジトリを設定

さて、この時点でまだ一切ファイルの追加・変更を行ってはいないだろうが、ここで先にプッシュ&プルをデフォルトで行うリモートリポジトリ設定をしてみよう。

git push --set-upstream origin develop

と実行すれば、以降 git push コマンドを実行したときにデフォルトで origin という名前で登録されたリモートリポジトリへ変更がプッシュされるようになる。

これはリモートリポジトリの名前無しに git push git pull git fetch コマンドを使用する場合、ブランチごとに設定する必用があるので注意しよう。

ブランチの削除

なお、ローカルブランチを削除する場合は対象以外のブランチへチェックアウトした後に、

git branch develop -d

というふうに -d オプションを付けてあげれば削除となる。

リモートのブランチを削除する場合も同様で

git push -d origin develop

と、やはり -d オプションを付けてあげれば削除となる。

ステータス・差分の確認

ファイルの追加・変更を行えば当然差分が発生するが、Git 上でその内容を確認するためにはどうすればよいのだろうか。

まず、Git が捕捉しているファイルの差分状況やステージ・コミット情報などを確認する場合は

git status

を実行する。

こうすれば

On branch develop
Your branch is up to date with 'origni/develop'.

nothing to commit, working tree clean

のように現在のステータスが表示される。

上記の例ではなんの変更も捕捉されていない状態だが、例えば test.txt が変更され、new.txt が新たに追加されたときは、

On branch develop
Your branch is up to date with 'origin/develop'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: test.txt

Untracked files:
(use "git add <file>..." to include in what will be committed)

new.txt

no changes added to commit (use "git add" and/or "git commit -a")

のように表示されるだろう。

これらファイルの差分を見る場合は、

git diff

と実行すれば差分が表示される。

ある特定のファイルのみの差分を表示するのであれば、

git diff ファイルパス

ブランチ同士の差分を表示するのであれば

git diff ブランチ名A ブランチ名B

ブランチ同士のある特定のファイルのみの差分を表示するのであれば、

git diff ブランチ名A ブランチ名B ファイルパス

を実行すれば結果を絞ることができる。

ちなみに Git の差分表示は行単位で行われるが

git diff --color-words

というように --color-words オプションを付けると差分が行単位ではなく単語単位になるのでより詳細な差分を見たい場合は活用すると便利だろう。

ステージング・コミット・プッシュ

ステージング

変更ファイルの状態が分かったら今度はそれをステージングしてみよう。

全ての変更をステージングする際は

git add .

と実行する。

. は全ての変更をステージングするという意味なので忘れないように注意しよう。

ちなみにステージングするファイルを個別に指定する場合は

git add ./new.txt

のようにカレントディレクトリからのパスを指定し、ステージングするファイルをディレクトリ単位で指定する場合は、

git add ./path/to/.

のように git add ディレクトリパス/.

と実行すればよい。

さらに、ファイル内の特定部分のみステージングしたい場合は

git add ./test.txt -p

と実行すれば変更箇所ごとにステージングするかどうか聞かれるので、ステージングするなら y キーを、しないなら n キーを押そう。

ちなみに一度ステージングしたファイルは

git reset

で全て元に戻すことができる。

また、ファイルの変更を作業開始前に戻したい場合は

git checkout .

で作業内容を破棄することができるので、作業を戻したい場合は活用してみよう。

コミット

これらステージングした変更をコミットするには

git commit

を実行する。

デフォルトではテキストエディタとして Vim が設定されており、画面が Vim によるコミットメッセージ編集画面になるのでコミットメッセージを編集して保存すればコミットが行われる。

テキストエディタを変更したい場合は、例えば

git config --global core.editor emacs

のようにすればエディタを Emacs へ変更できるが、既にエディタのインストール・パスを通し済みである必用があるので注意。

プッシュ

最後にプッシュだが、先述の通りデフォルトのリモートリポジトリブランチが設定されているのであれば

git push

でプッシュができる。

設定をしていない場合は

git push origin develop

のようにリモートリポジトリ名とブランチ名を明記してプッシュしよう。

ログの確認

Git のログももちろん CLI 上で表示することができる。

一番シンプルな表示は

git log

で、日時やコミット作者、コミットメッセージが表示される。

ちなみに、1画面でログが表示しきれないときは画面をスクロールすることができるが、このモードを抜けるためには q を押すことで脱出することができる。

h を押すことで操作方法が表示されるが、基本的な操作方法は vi に近いので、/ で検索が可能だし、G で最後、g で先頭に移動することができる。

さて、この git log はオプションが多く、欲しい情報によって様々なオプションを付けて使うことになるだろう。

まず、コミットごとの差分を表示する際は git log -p というように -p オプションを付ければ git diff のようにコミットごとの差分を表示することができる。

そして表示するコミットの数を絞る場合は git log -10 というふうに -10 と数字を指定すれば最新から指定数のコミットのみ表示することができる。

コミットごとに表示される情報が多すぎる場合は --oneline オプションを付けるとコミット一つにつき 1行の表示になる。

また、--decorate を付けるとブランチおよび HEAD の現在位置が表示される。

そして --graph を付けると各コミット間の樹形図的関係がアスキーアートで表示される。

更に --all を付けると現在のブランチとは関係ないコミットも全て表示される。

以上を組み合わせて、

git log --oneline --decorate --graph

とすれば GUI で見た樹形図と遜色ない履歴を見ることができるだろう。

フェッチ・プル・マージ・チェリーピック

フェッチ・プル

Git のフェッチ、プルは単純で、それぞれ

git fetch origin

git pull origin

で実行することができる。

プッシュ時に先述した git push --set-upstream origin develop

のようにデフォルトのリモートリポジトリ設定を行っておけば origin 部分無しにフェッチ・プルが行える。

マージ

マージを行う場合は

git merge ブランチ名

というようにすれば勝手にマージが発動するだろう。

マージの内容によってはコミットを行う必要があり、その場合は勝手にコミットメッセージが入力された状態でコミットメッセージ編集画面に移動するので問題なければそのまま保存・コミットを行おう。

問題はコンフリクトが起きた場合だが、この場合は実行後のメッセージになんのファイルがコンフリクトが起きたか明記され、いきなりはコミットが行われないようになっている。

git status

で確認してみると問題なくマージが完了したファイルのみがステージングされていることが分かるだろう。

git diff

はステージングしているファイルを対象にしないため(逆に --staged オプションを実行すればステージングされたファイルのみの差分を表示できる)、そのまま git diff を実行すれば衝突箇所を確認することができる。

勿論開発エディタに戻ってコードを理想の状態に修正してもいいが、現在のブランチ・またはマージ先のブランチの内容を変更せずに適用したい場合は git checkout にオプションをつけて自動解決することも可能だ。

現在のブランチを優先する際は

git checkout --ours

逆に、マージ先のブランチを優先する際は

git checkout --theirs

とすることで勝手にコンフリクトが解消されるので活用すると便利だろう。

ファイルごとにこの機能を使う際は

git checkout --ours ファイルパス

のように --ours--theirs の後にファイルパスを入力すれば OK だ。

チェリーピック

チェリーピックを行う場合は

git log --oneline

を実行したときの先頭に表示される7文字のハッシュを覚えておき、

git cherry-pick ハッシュ名

と実行すれば OK だ。

ハッシュの確認はもちろんデフォルトの git log でも可能だが、この場合表示されるハッシュはかなり長いので --oneline オプションを付けた方が無難だろう。

スタッシュ

Git の便利機能として、現在まだコミットしていない作業内容を一時的な記憶領域に保存しておくスタッシュ機能がある。

現在の作業内容をスタッシュとして登録する場合は

git stash

で作業内容を保存できる。保存と同時に全てのファイル追加・変更・削除は元通りになるので、ブランチを移動するなり各種作業を行うなりの操作が可能になる。

現在のスタッシュ一覧を確認する場合は

git stash list

と入力すれば

stash@{0}: WIP on master: 06a771b test2
stash@{1}: WIP on master: 06a771b test2

というような履歴が表示されるだろう。

これら履歴の stash@{0} という部分が各スタッシュ名で、これを適用する場合は

git stash apply stash@{0}

というようにすれば保存した作業内容が再適用される。

ちなみに、適用前にスタッシュした内容がどんなものかを確認する際は

git stash show スタッシュ名

とすれば変更ファイル名一覧が、

git stash show -p スタッシュ名

とすればファイルごとの差分が見れる。

さて、git stash apply を行うだけでは履歴から対象スタッシュは消えないため、スタッシュを溜めすぎると後からどのスタッシュがどの作業内容か分かり辛くなる。

なので

git stash drop stash@{0}

を使用して個別に使用済のスタッシュは削除するか、もしくは

git stash pop

を使用すれば最新スタッシュを適用後、自動でそのスタッシュを削除できるので、うまく活用していこう。

まとめ

覚える事が多そうだが、日常的に使うのは fetch, pull, checkout, add, commit, push, status, diff , log くらいなので、案外早く慣れるだろう。

どんな CLI ツールにも言えることだが、ほとんどの単純作業は慣れれば GUI よりサクサク行うことが可能だし、エンジニアならプログラムによる自動化も行える。そしてなにより、なんかカッコイイ。これに尽きる。

万が一、CLI でクールに仕事をこなすあなたを見て「黒い画面でパチパチやってる人とかネクラそう……」とか言っている輩がいたら、そいつは未だに見た目だけの俗世から解脱できぬ愚民に違いないので無視で構わない。さぁ。 Git を使うなら、あなたも CLI の世界へ、 Let’s 解脱。

コメントを付ける

入力エリアすべてが必須項目です。

内容をよくご確認の上、送信してください