SUNABACO 
みなさんはGitのコマンドについてどれくらいの知識がありますか？
全く無くて大丈夫です！この記事を読んで少しでも興味を持ってもらえると嬉しいです
最近は、SourceTreeなど、GUIのGit管理システムがあるので、初心者も入りやすくなりましたが、重要なのは、Gitの目的とその仕組みを知っていることです。
日常のタスクでは、ステージにファイルを追加する方法（add）、コミットを行う方法（commit）、およびリモートリポジトリから変更をプッシュ（push）およびプル（pull）する方法を知っていれば十分だと思います。
今回は、さらにGitコマンドを扱えるようになりたい方達のために、応用コマンドをご紹介したいと思います。
この記事を読む人におすすめな記事▼
履歴の追跡
Gitには、リポジトリで実行されたすべてのアクションのログがあります。
commit, rebase, checkout、またはその他の操作を実行すると、それらすべてが保存されています。
git logとかでcommit履歴を見て、rebaseやsquashでcommitをまとめたり、過去のcommitにcheckoutできたりしますね。これ言われて理解できる人は、もうGit上級者でしょう。
Gitは、すべてのアクション履歴を参照ログと呼ばれる別の場所に保存します。 特定のアクションが実行されたときのブランチの状態へリンクされています。 コマンドはgit reflogです。
git reflogを使うと過去のあらゆるコミット履歴を見ることができ，git logやgit branchでは辿り着けない時点まで戻すことができるので、ぜひ一回遊んでみてください！
どこで壊れたときを見つける方法
どこかでバグが発生した場合、バグを引き起こしたコミットを見つけるために、Git履歴を査定しないといけないときがあります。履歴ログが少ない場合は、さほど大変ではありませんが、大規模開発の場合、そのバグ地点を探すのは骨の折れる作業です。
しかし、幸いにも、Gitにはこのバグが発生した地点を探す機能があります。
git bisectコマンドを使用すると、バイナリ検索というものが開始されます。 問題が存在しなかったときからコミットに問題が発生したときまでのコミットの履歴ログを調べてくれるのです。
git bisect startを実行すると検索が開始されます。ここで最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」ということです。たとえば、コミット77beb52cには問題がなく、コミットafeb16fbに問題がある場合、
git bisect bad afeb16fb
git bisect good 77beb52c
としましょう。
その後、検索を実行します。我々はコミットに問題あるのかを判断する必要があり、そのコミットに問題が存在しなかったと思われる場合は、git bisect goodと記述します。 そうすることで、開始点はそのコミットにシフトされ、より小さな履歴ログで検索処理が繰り返されます。
逆にコミットにすでに問題が含まれていることがわかった場合は、コマンドgit bisect badを使用します。そのコミットが新しいエンドポイントになり、検索は次のループに入ります。
その繰り返しで、問題が発生した場所に単一のコミットが残るまで、この処理が続いていきます。このコマンドを使用すると、履歴ログをすばやく分析し、問題が発生したときまでさかのぼることができるのです。
下書きを保存する
ソフトウェア開発者が新機能を実装している最中、突然、特定のブランチに切り替えて、いくつかの変更を加える必要があったとしましょう。このとき、なにをするべきでしょうか？
最初に頭によぎるのは、そこまでの変更をcommitすることです。しかし、多くの人がブランチで作業している可能性がある場合、途中までしか実装していないものをcommitすることはあまり推奨できません。
このような場合、コマンドgit stashを使ってみましょう！
このコマンドは、作業ディレクトリをローカルスタックに保存できます。一番最近追加された変更は常に一番上にあり、後のすべての変更は、作業ディレクトリから削除されます。
git stashは、下書き保存みたいな感じです。ファイルをいじったり、実験したりすることができます。大量のブランチを作成せずに、新しいアプローチを探索することができるので、ぜひ使ってみてください。
まとめ
Gitは慣れるまで、正直難しい機能だと思いますが、使いこなせるようになってくるとGit無しでは生きていけなくなるので、頑張って身につけてくださいね！