gitあんちょこ（小規模な開発のために）

※追記(28/07/20)
今見てみると、全部masterにpushしてたというのはかなりアレな気がします。
使い始めたばかりのときの視点で書いてあるので同じような立場の方には役立つかも知れないとのことで残してはおきますが、この記事の後半部分などはあまり信用しない方がいいと思われます。

10人くらいでgitを使ってゲームを作る際に使っていたコマンド群のメモ。
githubを使いつつもプルリクなどをせずに直接pushしていたような状況。
環境はWindows7に入れたcygwinのgit。
git initやgit cloneなど、最初にのみ使うものは省いています。
ほぼ自分のために覚え書きしておいたものを少し体裁を整えただけなので、もちろん無保証です。間違いなど多分にありそうです。指摘して下さると嬉しいです。

#ローカル編
一人で開発するときにも使うもの。
##状況確認

$ git status

何かgitで操作をしようとするときには、とりあえずこれを打って状況を確認する。
##ファイルの追加

$ git add [ファイル名]

• gitで管理されていないファイルを新たにgitの管理下に入れるとき
• gitで既に管理されていて、前のコミット以降に変更があったファイルの変更を反映させるとき

に使う。

後者に関しては、

$ git add -u

で変更のあった全ファイルの変更を反映できるが、勝手に変更されたメタファイルなど変なものが紛れ込まないように、必ずgit statusを確認した後にする。できれば使わない方が吉。ファイル名の入力はzshやらの補完機能を使えばいい。
##変更の取り消し

$ git checkout HEAD [ファイル名]

git statusを見たときに変更されたファイルになっていたが、git addで変更を反映したくないファイルを、前のコミットの時の状態に戻すためのコマンド。
間違って実行すると取り返しの付かないコマンドであることに注意。
あまり推奨されない方法らしいが直感的。

##addしたものを戻す

$ git reset [ファイル名]

間違ってgit addしたファイルがあったときに、その操作を取り消す。
##コミットする

$ git commit -m "コミットメッセージ"

git add（や、ここでは触れないがgit rmなど）したファイルについて、それらの変更を確定する。
これをすることによってはじめて、gitの履歴に今の状態が保存される。
##コミットの履歴を確認する

$ git log

コミットの履歴を見られる。
たとえば、

$ git log -p -1

のようにすると、最も新しいコミットの前のコミットからの変更点が見られる。

#ブランチ編
複数人でやるなら使った方がマージの時に安心？ 一人のときも好みに応じて。
##ブランチを作る

$ git branch [ブランチ名]

これでブランチができる。

$ git branch

と引数なしで実行すると、現在のブランチとブランチの一覧を確認できる。
##ブランチを切り替える

$ git checkout [ブランチ名]

引数に入れた名前のブランチに切り替える。
##ブランチを統合する
例えば、testという名前のブランチで作業していて、その変更をmasterに反映したいとする。
まず、testの変更を全てコミットする。この際に、git statusをしても何も出ないようになるように、要らないものはgit checkoutを使って変更を取り消しておく。
次に、masterブランチに切り替える。
そこで、

$ git merge test

と入力することで、testに行ったコミットがmasterのほうにも取り込まれる。
複数人の開発の時などは、このときに、「～のファイルで変更が衝突（コンフリクト）した」とのエラーメッセージが出ることがある。
その時は、コンフリクトしたファイルを開いて編集することになる。

<<<<<<< HEAD
[masterブランチでの内容]
=======
[testブランチでの内容]
>>>>>>> test

競合した部分がこのようになっているので、正しい内容になるようにエディタで変更して上書き保存する。
全てのファイルを編集したあとは、そのファイルをgit addしてgit commitする（これをマージコミットというらしい）。
##ブランチを削除する

$ git branch -d [ブランチ名]

ブランチを削除する。もし統合されていない変更があるとエラーがでて削除できない。無理矢理削除するオプションもあるが。

#リモート編
##方針
複数人で開発するときは、リモートの（向こうの）リポジトリをローカルのリポジトリに統合するときの競合の処理が問題になる。
次のようにしていたらさほど面倒はなかった。

• ローカルに2つのブランチを用意する。
  • master
  • test（名前は好きにする）
• 自分が変更を加える際は常にtestブランチのほうで行う。
• masterのほうはリモートと同期する。
• 自分の変更をリモートに反映したいときは次のように行う。
  • 1. master ブランチに切り替え、git fetch の後 git merge（引数なし）をしてリモートの内容をローカルのmasterブランチに反映させる。
  • 1. masterブランチのまま、git merge testをして、masterブランチにtestブランチを統合する。
  • 1. git push origin masterでローカルのmasterをリモートに反映させる。
  • 1. testブランチを一度削除したあとに再び作り、testブランチに切り替えて開発の続きをする。

こうすることで、うっかり自分の行った変更を消してしまわないかびくびくしながら統合しなくて済む。

##リモートの内容を取得する

$ git fetch

リモートの内容を取得する。git mergeするまでは反映されない。
##リモートでの変更を統合する

$ git merge

fetchしてきた内容を現在のリポジトリに統合する。
引数無しで行うと環境によっては（たぶんWindowsに普通に入れたgitでは）エラーになるらしいので、その場合はgit configで何かを設定すればエラーが出なくなる。
エラーメッセージでググるといいみたい。
##ローカルの変更をリモートに反映する

$ git push origin master

だいたいこれでいい。masterブランチの内容をリモートのoriginに反映する。
引数のmasterはローカルのmasterブランチ。
originはリモートのブランチを指すのだが、何を指しているかといえば、

$ git config --list

をしたときに出てくる一覧の「remote.origin.url」が指している先のブランチになる。
よって、git remote addなどのコマンドを用いてリモートのブランチを増やした際などは、origin以外を指定することもある。
詳しくはその都度ググればいいはず。

#以上
上にもたびたび書いていますが、その他いつも使うものではないコマンドは、必要になったときにググればいいと思います。そんな立場で書いています。あんちょこなので。
いんたーねっとってすごいです。