※ 結構やっつけで書いているので、読みにくいところがあるかもしれません
結論
- こまめにコミットする
- git-now を私は使っています
- テストをちゃんと書く
考察
開発でつまずいてしまう理由の一つは、バグが修正できないからだと思います。ではバグを見つけ、修正するためにはどうすればいいのでしょうか。
エラーメッセージをよく読むということがまず大切なことです。それで解決するならば問題はありません。
しかし、複雑なソフトウェアになると、一つの変更が思いがけないところまでに影響してバグを生み出すことがあります。そしてそのようなバグを発見することが難しいことがあります。
そこでデバッグ作業を行うことになります。デバッグ作業にはいくつかの方法がありますが、私が最近有効と思っているのが git bisect を使ったデバッグです。
git bisect についての詳しい説明はたとえば以下の記事や公式ドキュメントなどをご覧ください。
冒頭の「結論」の条件を満たしていれば、git bisect を使うことでバグの箇所を簡単に特定することができます。「ある作業を行ったからバグが混入したことが分かる」というのは、デバッグにおける強力な武器だと思います。
現実は……
……と、言うのはたやすいのですが、現実はそううまくは行かないものです。
上記のデバッグ方策を採るためにはテストを書くことが必須です。テストを書くためには、実装部分がテストしやすい形で書かれていることが必要です。また、適切なテストを書く必要もあります。ここで時間がかかると総合的には開発は遅くなるでしょう（あくまで「速度」のみを主眼に置いた場合の評価です）。
また、こまめにコミットを行うということはあとで squash をする必要があり、git rebase の理解が必須です。git bisect を用いるためには git checkout や HEAD、ブランチの概念の理解が必須です。
バグが混入したコミットを発見したとしても、それをもとに原因を探るためには（diff などを素早く見るために）IDE や エディタ に習熟している必要があるでしょう。
発展的には、バグがバグを生まないようにするために、一つのブランチ（プルリクエスト）の粒度を絞ることが必要です。そのための問題の切り分けを適切に行う必要もあるかと思います。
なかなかに大変
以上のようなことを独学で身につけるのは大変だと思います*1。このような基礎体力は後々になってじわじわと効いてくるので余裕があるうちに知っておいたほうがいいと思うのですが、なかなかに機会を作るのが大変なのではないでしょうか（私の観測範囲だけかも）。
ソフトウェアの規模が大きくなく、開発速度を重視する場合には*2、上記の方法に則ることで余計に時間がかかることもあります*3。ソフトウェアの複雑さも高くないため、後でリファクタリングをすることを前提のコードを残すこともあるかもしれません。
もちろんテストをシュッと書き、場当たり的でない実装を行い、そしてそれを高速で回していけるチームというのは理想だと思います。ところが現実にはそれはなかなかに大変で（と思う）、どこかで折り合いをつけなければいけないと思っています。
まとまらない
とりとめもなく書きましたが、最近思っていることをだらだらと記してみました。
