0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Git/GitHubのコミット、プッシュ単位

Posted at

※本記事は、完全な私見であるためあくまでも参考程度に考えていただければと思います。

本記事の対象者

  • Git/Githubのコミット、プッシュ単位に関してお困りの方

結論

この問題に唯一無二の正解はないです。個人によって考え方がありますし、プロジェクトによってもやり方が異なると思うのである程度の基礎を抑えた上であとは自分のいる環境に合わせて柔軟に対応していくのみです。

他の方の意見

引用させていただくと、伊藤さんはこちらの記事の中で以下の通りまとめております。

  • 何かあったらここまで戻りたい!という単位でコミット
  • あとから振り返ったときに「変更の意図や目的」がわかる単位でコミット
  • 正常に動く単位でコミット
  • ロールバックしたらプログラムが壊れた!とならないように
  • TODOリストのTODOが1つ片付いたらコミット
  • 大きな機能を実装する場合はまず機能ブランチを切って、最後にマージ(pull request)する
  • 場合によっては複数のコミットを1コミットにsquashする
    • Rails本体の開発など

こちらの意見、非常に参考になりましたがでもやっぱりまだ頭の中でうまく整理することができませんでした。そこで色々調べたり、検索してみた結果の私の意見をこちらにまとめてしまう。

私の意見

プログラミング初心者の私ごときが伊藤さんの意見に対して反対するわけではないです。伊藤さんのまとめておられる意見に私なりの解釈を加えてみました。

  • 後から後悔するくらいなら、なるべく細かい粒度でとりあえずコミットをしておく
  • コミットメッセージに何かしらの法則を設定する
    • 機能追加であればコミットメッセージの最初に[Function]と必ずつける...等
  • 要は、やらないよりはとりあえずやっておくというのが良い。

おわりに

私の意見は私の性格に大きく関連していると思います。心配性であるためとにかく細かく保存しておかないとなくなった時が不安です。加えて私の場合は、趣味の範囲で自分ひとりで開発をしています。それなので、中途半端なところで手を一旦止めてしばらく放置してからまた再開ということが頻繁にあります。この中でたまに途中まで開発が進んだところがパアになってしまうということが何度かありました。それを防ぐためにも余裕があるときにはとにかく細かくやっておけば問題ないかと思います。

執筆:2022年8月14日(日)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?