社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。
本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。

(追記：第二弾できました) →　[社内新人向け]Gitで絶対にオススメなプラグインや設定3つ

社内環境

• Web系開発がほぼ100％
• ブランチワークはGitflowをベースにしたプルリク駆動開発
• 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など）
  • GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました
• CIツールはまだ導入できず。各サーバーへのデプロイなどもgitコマンドを手動操作してます。

こんな環境なので、みんなGitの操作にはわりかし詳しいです。逆に言えば、うちで開発実務をやっていれば、Git操作ならある程度どこでも通用するレベルになれるはずです！(※個人の感想です)

使ってほしくないコマンド

（1） git add --all や git add ., オプションを指定しないgit add [ファイル名]

いきなり基本的なコマンドですが、避けて欲しいコマンドNo1です。ほとんどの初学者はこれでaddするのですが、ビジネスレベルの開発だともうちょっと細かい制御が必要になります。

理由

具体的にどんなコードがコミット対象になるのか把握できないままaddされてしまう可能性があるため。
具体的にはこんな失敗が起きやすくなります。

• 今回の対応に関係のないファイル(デバッグ用に変更した設定ファイルなど)をコミットしてしまう
• インラインでprintデバッグや、(めちゃくちゃ多くて差分が読みづらくなるような)インデントの調整など、不要なコードがコミットされてしまう

代わりに使うべきコマンド

git add -p [ファイル名]　を使う

このコマンドを使うことで、指定したファイルの差分が、ある程度のまとまり別に表示された上で、対話形式で、行単位でどのコードをコミット対象にするかを個別選択できます。（文字で書くとわかりにくいですが、実際にコマンドを叩いてみると直感的なのがわかると思います）

コミットする際のベストプラクティスは、何をコミットし、何をコミットしないのかを必ず行単位で目視チェックした上で、必要なものだけを綺麗にコミットする　 ことです。 また、　git add -pで改めて変更箇所を目視することで、

• 追加箇所にコメントが足りないから追加しよう
• 思ったよりも差分コードが複雑なだから、実装をもう少しリファクタリングしよう

という感じになり、いいことづくめなので、ぜひ 次のコミットからはgit add -p [ファイル名]を活用しましょう！
(ちなみに、新しいファイルを追加するときは差分がないのでgit add [ファイル名] を使っても大丈夫です。

（2） git pull

この辺りはよく言われることで、わかりやすくまとまった記事がありますので、そちらを見てみてください。

Git pullを使うべきでない３つの理由

代わりに使うべきコマンド

git fetchと git merge [リモートブランチ] で最新版を取得する。

コマンドは増えますが、より「今自分が何をやっているのか」という事が明確になり、初心者キラーのConflictが起きた時も、具体的に何と何が衝突しているのかがよりわかりやすくなります。Gitの理解も深まるので、ぜひfetch - mergeの手順を覚えましょう！

(3) git push develop, git push master

これは git flow + プルリク駆動特有のルールですね。　git flowについてはこちらが詳しい。

Git-flowって何？ | Qiita

理由

developブランチmasterブランチも実際に本番に反映されるコードを上げる場所であり、必ず第三者のチェックを通して更新されるべきなので

代わりに使うべきコマンド

自分の開発用ブランチを切ってpush ブランチ名, Github上でdevelopにプルリクエストする。

developとmasterへは基本的にgit pushは行いません。プルリクエストを通じてマージすることで、チームリーダーなどの第三者が「このコードは本番に反映しても安全だ」というチェック機構を経て製品コードが更新されることになるので、本番上でバグが発生する確率をかなり下げることができます。

※そもそもGithub上でpush禁止にすればいいと思われた方、その通りです。 ただ、受託開発なども含めると社内には新旧合わせてかなりのリポジトリがあるので、全て設定する状況には程遠いのです・・・。

以上です。もし他にもあったら随時追記していきます。

2/21追記

なんか社内向け記事をついでに公開、くらいのノリだったのに予想外にバズってしまって恐縮しております・・・。
はてブの方で git add に関して賛否両論になっているので少し補足させてください。

「.gitignoreを有効活用せよ！」というご意見に関しては全く正しいと思います。.gitignoreに含めるべきものを含めずに、コミットされてしまったのであれば、それはチームリーダーに責があると思います。ただ、

• テストデータの用意がめんどくさくてなんか他のファイルをいじって動くようにした
• テスト用のインラインのdebug出力が残っている
• 他のやりかけのチケットの差分がそのまま残っていた

など、.gitignore対象でないファイルに対して、実装者の不注意で不要な差分がコミットされてしまう・・・というケースは、割とありがちなように思います。

この項目を挙げた趣旨としては、「git add .はダメ」ではなく、「"コミット時に差分をしっかり確認する"という習慣を、まずはつけて欲しい」という事になります。そもそもGitを勉強中です、くらいのレベルだと git add -p を知らないことの方が多いでしょうし、まずは騙されたと思って使ってみるだけでも、「とにかく全部コミット」から「ファイル単位、行単位でコミットする内容を意識する」という段階へステップアップできると考えています。　

そしてGitの仕組みを理解している人であれば、git addだろうがgit rebaseだろうが、内部的に何が起きているのかをしっかりとハンドリングできるので、そもそもこれは使わない、みたいなルールは不要だと思います。どんどん黒魔術使いましょう！

色々と書きましたが、批判的な意見も含め、たくさんの方にご意見を頂けて、社員一同楽しく見させてもらっております。引き続きよろしくお願いします！　

3/1追記

「社内向け記事だったらQiita:Teamの方がいいんじゃない？」
というご意見をたくさんいただきました。
Qiita:Organizaionへの投稿に関しては、かなり実験的・意図的にに取り組んでいる部分があるため、
あらためて弊社のOrganizationについての方針や取り組み、成果についてまとめてみました。

まだQiita:Teamで記事書いてるの？時代はQiita:Organizationだ！という話