1. Qiita
  2. 投稿
  3. Git

[社内新人向け]Gitで使ってほしくないコマンド

  • 35
    いいね
  • 0
    コメント

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

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

社内環境

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

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

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

(1) git add --allgit add ., オプションを指定しないgit add [ファイル名]

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

理由

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

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

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

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

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

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

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

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

(2) git pull

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

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

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

git fetchgit 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禁止にすればいいと思われた方、その通りです。 :bow_tone1: ただ、受託開発なども含めると社内には新旧合わせてかなりのリポジトリがあるので、全て設定する状況には程遠いのです・・・。


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