• 一部事実とは異なりますよ。
• TODO:もっと分かりやすい表現あるので後で差し替え

簡単なgitの使い方を説明します。通常の運用の場合とちょっと大きめの機能を追加する場合の二種類をまとめます。

通常のgithub運用の流れ

以下の図のように、左をremoteと右をlocalとします。

リモートもローカルも一覧表示
git branch -a

1. cloneとかfetchとかしてlocalのbranchをremoteのbranchと同期させる

• サーバ上にしかない開発状態をローカルにもコピーします。
• 初めてプロジェクトに参加してローカルのマシンに初めて環境を作る場合はcloneをします。
• 既に参加済でremote側の開発状態に進展があり、ローカルの状態と乖離してるようであればfetchを行い同期をします。
• masterブランチに居るときにpullすることで、remote上のmaster(origi/master)とlocalのmasterを同期させます。

git clone
または
git checkout master
git fetch -p
git pull

2. ローカルに落としてきたmasterから作業用のブランチを切る

//
という感じの名前でブランチを切る。

git checkout -b beta/master
これでローカルに新機能masterが作られます。
さらに
git checkout -b ogk/beta/feature/hogehoge
で作業用ブランチを切ります。

3. 作業用ブランチに作業内容を反映させていく

• commit をして作業用のブランチに対して内容を反映させます。
• コミット時にコメントで追加や変更内容を記述します。これは他人が読む事を考えてちゃんと書きます。

git add .
git commit -m "Modifier your life."

4. ブランチを切った時に決めた機能がそろったらpushする

• １タスク単位などで区切られた作業が完了したらpushしてremoteのbranchにアップロードします。
• この時に新たに作るremoteのbranchはローカルで作成したbranch名と同じものが良いです。後から追加で修正する必要が出てきても対応しやすいです。

git push origin ogk/beta/feature/hogehoge:ogk/beta/feature/hogehoge

5. ブラウザからpull requestをかける

• pull request 時に何を追加したのか、過去のcommitメッセージの内容をまとめて記述します。
• 変更した事を、どうやったら確認できるかも記述します。
• 特にゲームの場合は pull request に対して確認者がコードを読まない(読めない)場合もあるので、追加した内容が分かる様にしておきます。

6. mergeしてもらう

• だれかにpullrequestを確認してもらったら作業が完了になります。
• 到底マージできる内容でなければそっとコメントを残してあげます。

7. branch の delete

• pull request を確認し、mergeした人は branch も消す様にします。
• 同様に作業者はローカルのbranchを削除してすっきりした気持ちを味わいます。

git push origin :ogk/beta/feature/hogehoge
でもremoteのブランチ削除ができます。

ちょっと大きい機能を乗せる場合の流れ

1. remote 上にブランチを作成

• 次の様に、一度ローカルにもってきたmasterから機能用のmaster branchを作成して改めてpushするのが分かりやすいと思います。
• origin/master -> master -> prototype/master -> origin/ogk/prototype/master
• 以降、prototypeのbranchはと呼びます。

git checkout master;git fetch;git pull
git checkout -b prototype/piyo/master
git push orogin prototype/piyo/master:prototype/piyo/master

2. fetch して同期

• 通常運用と同様にfetchをします。
• 通常と違うのは、master から branch を発生させるのではなくて、remoteにあるorigin/新機能/masterからbranchを切るというところです。

git checkout -b ogk/prototype/piyo/additionaFunctionName prototype/piyo/master

3. localのbranchを切る

• 先ほど作成した新機能branchからさらに作業用ブランチを切ります。

git checkout -b ogk/prototype/piyo/AddFunctionA origin/prototype/piyo/master

4. 作業をしてコミットする

• 通常運用同様に commit を重ねます。

git commit -a

5. push して pull request の準備

• 通常運用同様に push して remote 上に新たにブランチを作成します。

git push origin ogk/prototype/piyo/AddFunctionA:ogk/prototype/piyo/AddFunctionA

6. pull request はへ

• pull request する先はorigin/masterではなくてorigin/新機能/masterへ行います。
• pull request のeditでcompaire先を変更します。
• 同時に、新機能branchからorigin/masterへの pull request も出します。origin/master へのmergeが出来るかを確認するためです。
• 以降、origin/masterとorigin/新機能/masterとの乖離具合はこのpull requestを見る事で確認できるようになります。

7. merge してもらう

• 通常運用同様にmergeしてもらいます。

8. 改めてfetch

git fetch -p;

git checkout prototype/piyo/master
git rebase origin/prototype/piyo/master

• 6 に出した pull request 以外に既にmergeされたものがある場合は、ローカル新機能用branchを最新の開発状態に更新すべく、fetchします。
• 新機能branchのmasterに居る状態でpull origin/新機能branch するのを忘れない様にします。

9. さらに開発を進め

git add .
git commit -m "commit message"

10. push して pull request の準備

• 先ほどの運用と同じ様にrequestをかけます。
  git push origin prototype/piyo/huga:prototype/piyo/huga

11. merge

merge をしてもらうとlocalで作業した内容がremoteのブランチのlogに追加されます。
これで作業内容が統合され、開発状況がみんなに共有されるようになりました。

最後にこの大きくなったbranchをmaster側へmergeする作業が残ります。
masterから乖離があるとgithubのmergeボタンがグレーアウトして押せなくなってしまいます。

定期的にorigin/masterをrebaseすると乖離が少なくなります。
この時、から新機能に関わるスタッフが既にlocalにbranchを切ってるかもしれません。
なので、一声かけてからrebaseすると良いと思います。