なんか今までよくわからないままgit使ってたのでちょっといろいろ確認したい
RT @itchyny: git pull あなたの好意を引きたいgit push あなたを押し倒したいgit branch 浮気したいgit stash 昨夜のことはなかったことにしたいgit reset 最初からやり直しましょう
— ゆうなんとか@8/31きょうとさん (@yuu_hara) 6月 17, 2012今までgitを使っていて1人で管理しているはずなのに衝突が起きたり、間違って要らないファイルをステージにあげてしまったり、しかもそのままpushしてしまったり、間違ってブランチマージしちゃったりといろいろやらかしてしまったのはご承知のとおりです。1人でリポジトリをいじいじしているはずなのにカオスなグラフが出来上がるておくれぶりも何とかしたいので、覚え書きも兼ねて最低限困らないであろう程度に確認してみたいと思います。
使い始める
適当なディレクトリをgitでバージョン管理したいとき、まず最初はgit initを使います。
cd <管理したいディレクトリ> git init
もしくは、git init <管理したいディレクトリのパス>でも構わないみたいです。
でもこれ今の私はあんまり使わない気がする
すでに公開されているリポジトリをローカルに持ってきたいときはgit cloneを使います。GitHubのリポジトリをローカルに持ってくるときもこれですね。
cd <ディレクトリ> git clone <リポジトリの場所>
とコマンドを打つと、カレントディレクトリの直下にリポジトリ名のディレクトリができあがります。言うまでもなく中身はリポジトリで管理しているファイルの最新版です。なお、cloneするときにディレクトリの名前を指定することもできます。リポジトリの場所に続けてスペースを開けて指定しましょう。
変更を記録する
正直どのタイミングで変更を記録したらいいのか勘所はまだつかめていません。なのでコマンドだけ確認しましょう。
gitはリポジトリの前にステージというものがあって、ファイルの変更をリポジトリに記録する前に、一旦ステージにファイルを上げる必要があります。変更を記録したいファイルをステージに上げるには次のようにします。
git add <ファイル名>
もしくは
git add .
で、カレントディレクトリ以下のファイルを一度にステージに上げます。ちなみにこれでいらないファイルまでステージにあげてしまって四苦八苦したときの記録がこちら。
もし間違えて要らないファイルをステージにあげてしまったときは、
git reset HEAD
でファイルをステージからおろします。これをもっと早く知っていたらあの時間は無駄にならなかったのに…
変更を記録したいファイルをステージにあげたらローカルのリポジトリにコミットします。
git commit
でエディタが立ち上がるので、メッセージを編集して保存するとコミットが終わります、うまく行けばね。ちなみにメッセージを書かずに保存するとコミットされません。勢いでコミットしようとしていて、はっとなって少し頭を冷やしたいときは使うといいかもしれませんね。なお、-mオプションをつけるとエディタを開かなくてもメッセージを書き込むことができます。間違ってコミットしちゃったときは
git reset --soft HEAD^
で直前のコミットを取り消せます。ファイルまで元に戻したいときは
git reset --hard HEAD^
でコミットを取り消します。1人でいじってるぶんにはこんな感じでいいんじゃないですかね、たぶん。で、このへんの「やり直すコマンド」をよく知らない人がgitを触るとリビジョングラフがこんなかんじにておくれます。
↓言い訳
@arc680 最初の青い枝は試しにローカルからpushしたときの、2つ目の途中から延びてる枝はGistから引っ越してきたときの(黒い枝がGist)、0.2のブランチからすぐわかれて合流してるのはREADME更新してたのをpullし忘れてコミットしたらこうなった[みくったー]
くどいようですが、このリポジトリ、更新してるの1人なんだよ…？
リモートリのポジトリを更新する
ローカルのリポジトリでコミットした更新をリモート側のリポジトリにも反映させるには以下のようにします。
git push
たいていはこれで何事もなくうまく行きますが*1、どこのリポジトリに反映させたらいいかわからないとか怒られた場合はリポジトリの場所を教えてあげましょう。
git push <リポジトリの場所>
逆に、リモート側で更新があったとき、それをローカル側にも反映させるときは RT
@kyubuns: pullー git pullー git pullー
pushの反対だけにpullします。わかりやすいですね。
衝突しちゃったときは
基本的にファイルの内容のマージはgitがだいたいうまいことやってくれるらしいのですが、うまくいかなかったときはこんな感じにマージしたリビジョンごとにどこがどう変わったのかが衝突したところに書き込まれます。それでは一例(になっているのかはわかりませんが)をご覧ください。
あ…ありのまま 今 起こった事を話すぜ！
end end <<<<<<< HEAD end ======= end >>>>>>> a0ed
な… 何を言っているのか わからねーと思うが(ry
どこがかぶってるのかわからないのですが、gitさんがかぶってたって言うからかぶってたんです。
衝突の解消は、これをどちらか一方にし、コミットし直してやればOKです。ちなみにこれは解消し忘れたものです。このコマンド知ってたら見落さずに済んでいたんでしょうね…
git status
このコマンドを使うと、衝突を解消できたか、どこで衝突が起きたかを教えてくれるらしいです、使ったことがないのでなんとも言えません。
ブランチとタグ
これは使いどころがいまいちよくわかってません。ためしにかーの氏が作っているTwitterクライアント、Krileのブランチやタグを見てみると、ブランチの切り方は謎ですが、Krileのバージョンごとにタグを振っているようです。このへんのもやもやをなんとかするには、本か本家サイトをじっくり見る必要がありそうです。
使い方だけでも確認しておきましょう。今見ているブランチを確認するには
git branch
というコマンドを打ちます。すると、
* master hoge
というふうに、リポジトリにあるブランチの一覧が表示されます。今見ているブランチは行頭に*がついていて、ひと目でわかるようになっています。新たなブランチを切るときは
git branch <ブランチ名>
とします。すでに同じ名前のブランチがあると怒られます。かならず一意の名前にしましょう。コミットするブランチを切り替えるときは
git checkout <ブランチ名>
とします。ブランチ名はTabの補完が効くので積極的に使っていきましょう。Subversionから乗り換えてきた人は意味が全く違う同じ名前のコマンド*2があるので混乱しそうですね。
ブランチをマージするときは
git merge <ブランチ名>
です。これで今見ているブランチを本流にして、指定したブランチとのマージを試みます。うまくいかなかったときは前項の通りに衝突の解消をしましょう。
まとめのようなもの
説明書はしっかり読みましょう
いままであれやこれやと悩んできましたが、gitの入門書や本家サイトを予め読んでおけばあんまりておくれずに済んだと思うんですよこれ。
あと認識が間違ってるかもしれないのでおかしいところがあったらtwitterでリプライ飛ばすかFacebookでコメント投げるかしてくれるとありがたいです。
