---

Push系

こちらはブランチ作成など、pushとpullの基本です。

$ git pull origin 参照のブランチ
$ git checkout -b feature/#チケット番号_チケット名前
$ git commit --allow-empty -m "[WIP]#チケット番号 なんのためのもの”
$ git push origin feature/#チケット番号_チケット名前

Github Flow

ずっとmasterを参照しているは特徴です。

GitHub Flowには以下の6つのルールがあります。

• masterブランチは常にデプロイ可能である
• 作業用ブランチをmasterから作成する
• 作業用ブランチを定期的にプッシュする
• プルリクエストを活用する
• プルリクエストが承認されたらmasterへマージする
• masterへのマージが完了したら直ちにデプロイを行う

Git Flow

Github Flowより一個作業ブランチ増えていて、ちょっと複雑になりました。

今度参照しているブランチはdevelopになるかと思います。

各ブランチのルールは以下になります。

分岐元	マージ先	用途
master	developとmaster	緊急の修正作業を行う
develop	developとmaster	リリース準備作業を行う
feature	develop	機能実装やバグ修正などの開発作業を行う

暫定系

機能を実装していて、急にバグ発生しまして対応しないといけない。

今のコードの扱いはコミットして、「とりあえずコミット」とかコメントすることあるだろう。

この場合、stashを活用しましょう。

#現在のブランチの作業状態を暫く保存していきました。（コミットしていないもの
$ git stash

$ git stash save "コメント入れてもいいです"

#ブランチに戻り、前stashで保存した状態に戻す
$ git stash apply

#stashの履歴をリストアップ
$ git stash list

#stashの記録を全削除
$ git stash clear

#一番最新のstashにして、そして削除していきます
$ git stash pop

#一番最新のstashを削除する
$ git stash drop

間違い系

作業進んでいて、コミット間違いとか、ロールバックは発生することがあります。

このパターンで上書きとか考える人が多いではないかと思います。

コマンドをうまく使うと、gitのコミット履歴を綺麗になります。

reset

間違って、pullしているかどうか関わらず、一個やり直せるチャンスを与えてくれます。

$ git log

#最近のコミットもしくは指定したコミットまで戻る
$ git reset --soft HEAD^

注意：基本的に--softをお勧めですが、--hardもたまに使います。

revert

resetはコミットを戻しましたが、チームメンバーの他のコミットに影響出るかもしれないです。

revertで他のコミットに影響でないように済むです。

具体的に、resetした後に、このコマンドで、resetのコミットまで、その他メンバーのコミット分を自分で合併することによって、他人のコミットに極めて影響ないようにしました。

$ git revert HEAD^

$ git revert -m 1 <commitHash>

reflog

resetより強力なロールバック機能です。

もし、reset間違ってしまった場合、このコマンドでこの誤動作を修正してくれます。

$ git reflog