gitコマンドについて

前回のmemotoxin!でgitのインストールとGitHubの設定をしたので、gitコマンドの使い方をば。
自分のローカルリポジトリに更新履歴を残して、それをGitHub上で公開するところまで説明しています。

セットアップ
まず名前とemailアドレスを登録する。特に指定はないけどGitHubに登録した奴がよさそう。

git config --global user.name "Your Name"
git config --global user.email "Your E-mail address"

それとwindows, mac/unixでの改行の扱いについてそれぞれ指定

#mac/unixの人はこっち
git config --global core.autocrlf input
git config --global core.safecrlf true
#windowsの人はこっち
git config --global core.autocrlf true
git config --global core.safecrlf true

ローカルリポジトリの追加
リポジトリに追加したい作業ディレクトリに移動してgit initをする。

cd ~/Works/test
git init

すると、リポジトリ管理に必要な情報が.gitディレクトリ以下に追加される。

履歴の追加
gitの履歴はリポジトリに更新情報を追加してゆくことで管理されている。
まずaddコマンドを使って履歴に追加したいファイルををステージに登録(ステージング)する。
そしてcommitコマンドを使ってステージに登録されているファイルの更新情報をリポジトリに追加する。この履歴に追加することをコミットという。
スクリーンショット 2013-04-26 0.40.29
例としてhoge.pyとpiyo.txtの2つのファイルをステージングしてコミットしてみる。
in ~/Works/test directory

#ステージング
git add hoge.py
git add piyo.txt
#コミット
git commit -m "first commit"

コミットする際には-mオプションをつけて必ずコメントを付けないといけない。
もし、コメントを付けないでコミットしてしまった場合はエディタが開いてコメントを付けるように怒られる。

また、作業ディレクトリのすべてのファイル・フォルダをステージングしたい場合には

#作業ディレクトリ全てをステージング
git add .

とするとすべてのファイルがステージに載せられる。
この時に.DS_storeなどのファイルもステージングされてしまう。addの対象からこれを外すには.gitignoreファイルをリポジトリ内に置いてその中に除外したいファイルの名前を記述すれば良い。
またホームディレクトリに.gitignoreを置くと全てのローカルリポジトリに適用される。

現在ステージに乗っているファイルを確認するにはstatusコマンドを使う。

#ステータス確認
git status

試しにfoo.txtをステージングして確認してみる。

#ステージング
git add foo.txt
#確認
git status

new file: foo.txtとして登録されている。
statusコマンドでは、ステージに載っていないファイルや、新しく追加されたファイルや削除・変更がされたファイルの一覧を確認することができる。

間違ってステージング、してしまった場合にはステージから下ろすことができる。

#アンステージング
git rm --cache foo.txt
#確認
git status

rm ‘foo.txt’と表示が出てアンステージングされてる感じが伝わってくる。
statusでもUntracked files:の中にfoo.txtが入っていて、アンステージングできているのが確認できる。

また、間違ってコミットした場合にも、resetを使ってそのコミットを取り消すことができる。
これにはsoft resetとhard resetのが2つある。
softは作業ディレクトリの状況はそのままで、コミットの履歴のみを取り消す。
hardは作業ディレクトリの状況とコミットの履歴、両方を取り消す。

git reset --soft
git reset --hard

どちらのresetにしても、手が滑ってコミットしてしまった場合以外には使わないほうが良い。(そもそもバージョン管理のためにgitを使っているのだし…)

今までのコミット履歴を見るにはlogを使う

#履歴確認
log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short

何かいろいろ付けて整形することで見やすくなる。

あんな長ったらしいコマンドを打つのがめんどくさい場合にはエイリアスを登録するとよい。
自分のホームディレクトリ(作業ディレクトリではない!)に以下の内容で.gitconfigファイルを追加する。
~/.gitconfig

[alias]
  ch = checkout
  cm = commit
  st = status
  br = branch
  hi = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short

するとgit hiであの長ったらしいlogコマンドが打てるようになる。
他にもgit cmでcommitや、git stでstatusなどが打てる。

長くなったしこれで終わろうかと思ったけど、一番重要なバージョンの復帰を書いてなかった…
バージョンを戻すにはまずlogコマンドで戻したいバージョンを確認する。

#履歴確認
git hi

この時に一番最初の447e35aという感じのバージョンを示す文字列をコピーしておく。そして

#バージョンを変更
git checkout 447e35a
#確認
git hi
#バージョンを変更
git ch master

という感じにcheckoutでバージョンを変更することができる。作業ディレクトリのファイルもちゃんとそのバージョンの物に置き換わっている。
もちろんさっきのエイリアスを登録してたらgit ch 447e35aで戻せる。
バージョンを戻した場合、logコマンドではそこまでのlogしか確認できないため、–allオプションを付けることですべてのバージョンを確認できる。
また、masterやHEADと付いているコミットは、その名前でそのバージョンに戻せる。

logで表示されたコミットのうち、HEADと付いているものが現在の作業ディレクトリのバージョン状況を示している。
masterと付いているものはメインのバージョンで、ここからサブバージョン(?)を分化させることができる。(ブランチを切るという)
切ったブランチはmasterと比べて変更がなされたファイルを更新して結合させることができる。(マージ)
スクリーンショット 2013-04-26 1.56.19

試しにブランチを切ってみる。
まず適当なファイルを順番にコミットしてバージョンを上げた後、少し前のバージョンに戻す(別に戻さなくても良いけど、戻したほうがブランチしてる感じがわかりやすい)
* 4d9b78f 2013-04-26 | add baa.2 (HEAD, master) [Ryoji Ishii]
* 2c77ac6 2013-04-26 | add baa.1 [Ryoji Ishii]
* 4303fdc 2013-04-26 | add foo [Ryoji Ishii]
* 447e35a 2013-04-26 | first commit [Ryoji Ishii]
こんなかんじに適当なファイルをコミットしまくってバージョンを上げた後、git hi –allをして現在の場所(HEAD位置)を確認する。

#バージョンを変更
git checkout 447e35a
#確認
git hi --all

自分が過去のバージョンにいることを確認したらブランチを切る。

#ブランチを切る
git branch test
#ブランチの確認
git branch

今はテストというブランチを切った。のでブランチは
* master
test
となって、*の付いているマスターを編集していることがわかる。

このまま編集してもマスターを編集していることになるので、

#バージョンの移動
git checkout test

としてブランチを切った方のバージョンへ移動する。
適当なファイルをコミットして履歴を確認。

#ステージング
git add foobaa.0
#コミット
git commit -m "add foobaa"
#履歴確認
git hi
#全履歴確認
git hi --all

* 99715f7 2013-04-26 | add foobaa (HEAD, test) [Ryoji Ishii]
| * 4d9b78f 2013-04-26 | add baa.2 (master) [Ryoji Ishii]
| * 2c77ac6 2013-04-26 | add baa.1 [Ryoji Ishii]
| * 4303fdc 2013-04-26 | add foo [Ryoji Ishii]
|/
* 447e35a 2013-04-26 | a [Ryoji Ishii]
こんなかんじで、履歴確認だとそのブランチだけの履歴が(正しくはHEADより以前の履歴だけど)、全履歴確認だと、ブランチしてる様子も見えて全ての履歴の確認ができる。

ブランチを切ったバージョンがいい感じになったらmasterバージョンのファイルにブランチの情報を適用する。

#バージョン変更
git checkout master
#テストブランチをmasterにマージ
git merge test

すると適当なエディタが開かれ、コメントを要求されるので適当に書いて保存する。

これでmasterのコミットにブランチの更新が適用される。また、何気にlogも見やすくなっている。

git hi

masterとマージして不要になったブランチは削除するとよい。

git branch -d test

-dオプションで削除できる

また、ブランチを切った時のようにコミットに好きな名前のタグをつける事ができる。

#現在のHEAD位置にタグ付け
git tag v1.1
#指定したコミットにタグ付け
git tag v0.9 4303fdc

ハッシュ文字列を使ってタグ付けするコミットを指定することもできる。

GitHubとGit
これまでがローカルリポジトリで管理をするgitの使い方。
ローカルの方で適当なバージョンまでプロジェクトが進んだらGitHubに公開したい!
考え自体はローカルリポジトリにコミットする時と変わらず、
ローカルリポジトリに変更をコミットするのがcommit、リモートリポジトリにコミットするのがpush、ローカルリポジトリから変更を戻すのがcheckout、リモートリポジトリからリモートリポジトリにダウンロードするのがcloneととう感じ。
スクリーンショット 2013-04-26 9.33.10

自分のGitHub上にtestというリポジトリが有ってそこにローカルリポジトリのプロジェクト(とコミット履歴)を送りたいは
git push git@github.com:airtoxin/test.git master:master
とするとtestという自分のリモートリポジトリにローカルの変更がコミットされる。
master:masterは「マージするリモートブランチ:マージ元のローカルブランチ」を指定している。

GitHub上の適当なリポジトリを使ったり変更したい場合はcloneコマンドで
git clone https://github.com/airtoxin/twitterbot.git
と、欲しいリポジトリのurlを指定すればローカルにそのプロジェクトのリポジトリディレクトリが作成される。
このリポジトリはpush先が元のリモートリポジトリに設定されているので、適当な変更を加えてpushしたい場合には

git push origin master:master

とすると元のリモートリポジトリにpushされる。
originのurlを見るにはremoteコマンドで

git remote -v

とすると
origin https://github.com/airtoxin/twitterbot.git (fetch)
origin https://github.com/airtoxin/twitterbot.git (push)
という感じでpush先のurlが確認できる。

こんなかんじです。

*参考*
git immersion

広告


コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中