正直最初gitにはとっつきにくかったです。
とっつきにくかった理由は、
1. 分散管理がようわからん
2. svnと用語が微妙に違う
ってとこだと思います。
1についてはhttp://git-scm.com/book/jaの
1.1と1.3をよく読めばなんとなくわかってくるかと思います。
2については反復実行して体で覚えるしかないです。
$ git clone <remote> <local> リモートリポジトリからローカルリポジトリとワークスペースを作成する。 $ git pull 最新版のリモートリポジトリを取得してローカルリポジトリ、ワークスペースを更新する $ git push <remote> <branch> リモートリポジトリへローカルリポジトリの変更を更新する $ git init --bare --shared gitのリモートリポジトリを作成する。しかもグループで共有したい。 $ git add <file> 修正したファイルをステージングにあげる。新しく追加したファイルをバージョン管理する。 $ git reset HEAD <file> ステージングに上げたファイルをステージングから下ろす。 $ git commit ステージングにあがっている修正をコミットする。 $ git commit -a git addなんてめんどくさいって時に便利。 $ git commit --amend やっちまった!一つ前のコミットを修正したい・・・ $ git mv <from> <to> ファイルをリネームする $ git rm <file> ファイルを削除し、バージョン管理からも外す $ git branch ブランチを表示し、現在のブランチを知る。 $ git branch <branch> ブランチを作成する $ git checkout <branch> ブランチを切り替えたい $ git checkout -b <branch> ブランチを作成しつつ切り替える $ git merge <branch> ブランチをマージする $ git rebase <branch> ブランチをリベースする
リモートリポジトリ関連
リモートリポジトリの取得
社内gitや自分のgitやGitHubからプロジェクトを取得するには、
以下のコマンドを打ちます。
$ git clone <remote> <local>
svn checkoutとたぶんほぼ同じです。
このコマンドで、<local>で指定したディレクトリに
ローカルリポジトリとワークスペースが作成されます。
また、↓のような感じで<local>を指定しないこともできます。
この場合、nerdtreeディレクトリが作成されます。
$ git clone https://github.com/scrooloose/nerdtree.git
clone以降、開発中はファイルのステータスが
"修正済み", "ステージングに上がっている", "コミット済み"を行き来するわけですが
その間リモートリポジトリとのやり取りは発生しません。
リモートリポジトリ <-> ローカルリポジトリのやり取り
$ git pull $ git push <remote> <branch>
git pushするとリモートリポジトリを、
ローカルリポジトリと同期するのですが、
複数人で開発している場合は、
その前にgit pullをして他の人の修正を取り込まなければgit pushできません。
リモートリポジトリの作成
$ git init --bare --shared
↑のコマンドを実行すると、リモートリポジトリを作成することができます。
--sharedを忘れると、基本的には複数人で開発できなくなります。
ただし--sharedをつけても、開発者全員が同じグループに所属している必要があります。
ステージング <-> ワークスペースのやり取り
$ git add <file>
git addしたファイル(またはディレクトリ)は
コミット候補生(ステージングされた状態)となります。
なぜステージングなんて中途半端なものがあるのか ・・・
と最初はまどろっこしいわいと思ってましたが、
コミットヒストリーにためらい傷を残さないですむので
そそっかしい人にはちょうどいいです。
(他にもステージングがある理由はあると思いますが・・・)
そして、
あ、間違ってステージングに上げてしまった!って時は慌てずに、
git reset HEAD iwaswrong.txt
を実行すればステージング前の状態に戻ります。
コミットする
ステージングにあげた修正をコミットする場合は、
を実行します。
実行するとコメントを求められますので、
あとで見直す自分のことを考えて、わかりやすいコメントを入力します。
ちょっとした修正なのでわざわざステージングに上げるのもめんどくさいという時には、
なんて便利なコマンドもあります。
これを使うと、ワークスペースの修正がすべてローカルリポジトリに反映されます。
前回のコミットのコメント間違った!とかファイル1個追加し忘れた!って時は、
でコミットをやり直せます。
$ git commit
を実行します。
実行するとコメントを求められますので、
あとで見直す自分のことを考えて、わかりやすいコメントを入力します。
ちょっとした修正なのでわざわざステージングに上げるのもめんどくさいという時には、
$ git commit -a
なんて便利なコマンドもあります。
これを使うと、ワークスペースの修正がすべてローカルリポジトリに反映されます。
前回のコミットのコメント間違った!とかファイル1個追加し忘れた!って時は、
$ git add forgottenfile.txt $ git commit --amend
でコミットをやり直せます。
ファイルをリネームしたり削除したり・・・
遠い過去なのであまり覚えてませんが、
ファイルのリネームはsvnだと若干めんどくさかったような記憶があります。
それは置いといて、まずはバージョン管理から外す方法ですが、
で可能です。コマンドを実行するとunnecessary.txtはバージョン管理から外れるのみならず、
ファイル自体削除されるので要注意です。(すぐに戻せますが)
ちなみにリネームのプロセスはgitだと以下のプロセスでできます。
・・・めんどくさっ!
以下のコマンド一発で同じ事ができるのでご安心ください。
ファイルのリネームはsvnだと若干めんどくさかったような記憶があります。
それは置いといて、まずはバージョン管理から外す方法ですが、
$ git rm unnecessary.txt
で可能です。コマンドを実行するとunnecessary.txtはバージョン管理から外れるのみならず、
ファイル自体削除されるので要注意です。(すぐに戻せますが)
ちなみにリネームのプロセスはgitだと以下のプロセスでできます。
$ mv old.txt new.txt $ git rm old.txt $ git add new.txt
・・・めんどくさっ!
以下のコマンド一発で同じ事ができるのでご安心ください。
$ git mv old.txt new.txt
ブランチ関連あれこれ
ブランチを知る
$ git branch * master
でブランチの一覧を表示します。
作成したばかりのリポジトリだとmasterブランチしかないはず。
masterの左に*がついてると思いますが、*がついているところが現在作業中のブランチです。
ブランチの作成と切り替え
例えば、devブランチを新しく作成したい場合は
$ git branch dev
を実行します。
そして、devブランチに作業ブランチを切り替えます。
$ git checkout dev
この一連の流れ(ブランチ作成しーの切り替えーの)をコマンド一発でもできます。
$ git checkout -b dev
ブランチを合併
devブランチで開発をしているさなか、というケースを考えてみる。
新機能Aを追加するためにfeatureAブランチを切って開発する一方で、
BUG 1が発見されたのでその解決のためにdevブランチからhotfix1ブランチを作成した。
新機能AもBUG 1も無事修正が終わり、devブランチとマージしたい。
しかし、featureAブランチはhotfix1ブランチから枝分かれしたことにしたい。
$ git branch master dev featureA * hotfix1 # 現在hotfix1ブランチで作業中 $ git checkout featureA # featureAブランチへ移動 $ git rebase hotfix1 # BUG 1の修正をfeatureAブランチに取り込む。 $ git branch master dev * featureA hotfix1 $ git checkout dev # devブランチへ移動 $ git merge featureA # 新機能Aをマージ
git rebaseとgit mergeをこのように使い分けると何がいいかっていうと、
git mergeだけだと、コミットヒストリーは、
--dev--featureA |--hotfix1↓
--14a2b--featureA--dev |--hotfix1----------|
となるところを
--dev--featureA |--hotfix1↓
--14a2b--hotfix1--featureA--dev
という綺麗なコミットヒストリーのツリーを作ることができる点です。
しかし、細かいことは忘れましたが、
git push前後でgit rebaseをすると、
とんでもないことが起こって、共同開発者に切れられるらしいので要注意です。
もっと便利にgitを弄びたいという方は、
* Pro Git: http://git-scm.com/book/ja
の1, 2, 3, 5章を読めばだいたいOKかと思われます。
もっと深くgitを知りたいという方は
↑の他の章も読むとよろしいかと思います。
なんにせよ↑の本一冊で十分じゃないかなと思います。
0 件のコメント:
コメントを投稿