私の異常な開発工程 または私は如何にして神様へpull requestを送るようになったか

最近、友人とgit & pull requestで開発をしている。

現段階での自分なりの作業の進め方をメモしておく。

やり始めて間もないので色々おかしいところもあると思います。

こうするべき！！ってのがあったら教えてくれると嬉しいです。

自分のプロジェクトの場合

どんな人？

• masterブランチへのMergeが出来る人
• pull requestを受け取る側の人
• 神様

普段の作業の仕方

1. masterブランチは動く状態にしておく
2. 作業はブランチを切って行う
3. ブランチもgithubにpushしておくとグラフがｶｯｸｲｲ

pull requestがいらした

1. いきなりMergeはしないこと
2. ちゃんとローカルでチェックアウトしてから、テストしてMerge
3. どんなコマンドを使えばよいかはgithubに書いてある(以前の記事)

masterブランチは常に動くようにしておくこと！！

自分がコントリビューターの場合

どんな人？

• forkして作業してpull requestを送る人
• 神様から見たら神様に見える人達

初めに

masterブランチはfork元リポジトリの変更を追従するために使う。

自分の作業した内容をMergeしたりしない。

自分のした作業はpull requestになり、masterへMergeされることはない。

あくまでfork元の変更を取り込むために使う。

fork元の変更を追従する方法は以下の通り。

fork元リポジトリをupstreamという名前で追加

git remote add upstream git@fork元リポジトリ

fork元リポジトリの変更を取り込む

git pull upstream master

後はforkしたリポジトリの作業リポジトリにmergeする。

forkしたリポジトリのmasterブランチは常にfork元リポジトリのmasterと同じ状態にしておく。

後で沢山の変更を取り入れるのは大変すぎる。

これは凄く重要だと思ったので始めに言った。

普段の作業の仕方

適当にブランチ切って作業

以下のコマンドでブランチ作ってそのブランチに切り替える

git checkout -b branch_name

masterブランチは常に(ry

神様が神様へpull requestを送る方法

1. 神聖なるpull requestを送る前にコミットはひとつに纏める
2. 神聖(適切)なブランチ名でpull requestを送る
3. issueのコレだよ！コレ！って感じで送るとわかり易い

例えば今、hogehogeっていうブランチで作業しててひと通り作業が終わってpull requestを送りたくなったとする。

まずはmasterブランチとMergeしてfork元の最新の状態と合わせておく。

masterブランチへMergeするのでは無く、masterブランチから作業ブランチへMergeするので間違えないように。

それが終わったら、今作業しているブランチから更にブランチを切る。

例えばissueに23とかいう番号で登録されているバグを修正したとする。

（bugとか書いても意味分かんないので実際には、もっとわかり易い名前を付けるべき）

git checkout -b fix_bug

で、次にコミットを一つに纏める。

git rebase -i master

とやるとmasterブランチから自分が変更したコミットのみが抽出される。

するとコミットログを書き込むような画面が出てきて、なんか聞かれる。

「これまでのコミットログをどうするのよ？」的なことを聞かれる。

一番上のやつはそのままにして、残りはsに変更して終了。

sってのはsquashの略で、ログを統合するって意味である。

すると次にログを編集する画面が表示される。

ここで適当にログを整理して終了させる。

こうするとコミットがひとつにまとまったブランチが出来る。

これをremoteにpushしてgithubやらbitbucketやらの画面からpull requestを送れば終了である。

まとめ

2つの立場での開発の進め方を書いてみたが、大きく違うのはmasterブランチの扱い方である。

これが正しいのかは、まだ自分でも良く分かっていないが現時点ではこんな感じで運用している。

あとスクリーンショット撮るの面倒臭がってごめんなさい。