Q&A
＞実際の開発現場
組織での使い方を知りたいって感じですかね？自分はソロなんで回答出来ませんが
git初心者です。
gitでコード管理しながらrailsでアプリケーション作成したいのですが、gitのコミット粒度がいまいちわかりません。
いろいろなサイトを拝見していたのですが、「機能ごとにコミットする」、「戻りたいところに戻れるようにコミットする」と記述してありました。
railsの環境構築を終えて、masterブランチから、developmentブランチを作成したところです。
機能追加ごとに、developmentブランチから、 feature/xxx のような形でブランチを作成し、作り終えたらdevelopmentブランチにmergeする認識です。
先にログイン機能から実装を考えているのですが、この時点でfeature/add login functionのようなブランチを作成するべきなのでしょうか。
「機能ごとにコミットする」というのは、Userモデルを作成したらコミット、usersコントローラーを作成したらコミット、という細かい粒度ではなく、モデル作成、コントローラー作成、ビュー作成、ログイン機能に必要なものを実装し終えた後にコミットするという認識なのでしょうか。
実際の開発現場ではどのような粒度でコミットしているのか知りたいです。
掲示板アプリのようなものを作成しようと考えています。
- ログイン機能（User,Shopの２つの視点でログインする）
- サインアップ、サインイン、ログアウトが最低限必要とする。
- 投稿機能
- Shopとしてログインしている場合のみ投稿、編集、削除ができる
- タイトルを入力して投稿ができる
- 画像を添付して投稿ができる。
- 投稿をデータベースに保存する。
- Shopとしてログインしている場合のみ投稿、編集、削除ができる
- いいね機能
- Shopの投稿に対して、Userがいいね、いいね解除ができる。
回答4件
0
ベストアンサー
まず最初に、一般的なものが知りたかったらgit ブランチモデルで検索してください
以下はソロ活動前提での自分の場合の意見
形になるまではmasterとdevだけで十分（masterが一般的な開発におけるdevの役割）
作業はdevで行いコミットの単位はエラーの出ない状態で都度コミット
機能作成はひとつずつ順番にやればいいので、feature/xxxxは不要（コミットメッセージに書けばいい）
むしろfeature/xxx作ってあっちこっち気が逸れてOKな状態がNG
一通りの機能を作り終えたリリース以降は、普通にdev派生のfeature/xxxを作って開発・修正。devにマージ。
「機能ごとにコミットする」というのは、Userモデルを作成したらコミット、usersコントローラーを作成したらコミット、という細かい粒度ではなく、モデル作成、コントローラー作成、ビュー作成、ログイン機能に必要なものを実装し終えた後にコミットするという認識なのでしょうか。
前者でしょうね。小まめにコミットしておいて好きなところに戻れるのがメリットだと思うので。
git無し開発に慣れてる事もあって簡単なものならNextCloudのオートセーブで十分間に合ってると感じる人の意見です。なので参考にならないかもしれない
投稿2020/07/06 07:37
編集2020/07/06 07:39総合スコア6426
なるほどですね。。自分の中でgit運用の指標が出来ました。
ご回答いただき、ありがとうございました。
＞質問者さん
私もローカルリポジトリにおいてかなり頻繁にコミットする方ですが、加えて「rebase」を覚えておくときれいにまとめやすくなり、masterにpushするときに冗長で不要なコミットを除去できて良いと思います。
> 不要なコミットを除去
自己レスですが、「除去」と書くと消えちゃうイメージが浮かぶので語弊があるかもしれませんね。git rebaseでの「squash」などでのコミットのまとめ上げ、でしょうか。
0
コミットする時、基本的にメッセージを付け加えます。
git commit -m "コミットメッセージ"
後からgit logsで一覧表示した時に、
それに付随するメッセージを確認出来ます。
あれもこれもそれも実装して1コミットに収めると、
メッセージと全く関係のない仕事がこっそり紛れ込んでしまいます。
言ってる事とやってる事が違う人ってどう思いますか？
嘘つき！ってなりますよね。
人間は一貫性を求める生き物なので、
1行で他人に過不足なく説明出来るくらいの粒度にしましょう。
これが丁度良いコミットの単位です。
因みに現場によって決まっている事もあります。
例えばGitHubでは機能要望をIssueという要望掲示板に書き込んで、
プルリクエスト時にこのIssueと関係のある修正だよみたいな使い方が出来ますが、
そのIssueのID番号をコミットメッセージに含めて管理しましょうみたいなプロジェクトもあったりします。
ブランチ切って、プルリクエストを投げる時にコミットをまとめて1個に潰す。
これはこれで一貫性があって美しい管理方法ですね。
こんな風にルールが存在する現場に後から入って、
僕が考える最強のコミット履歴管理方をぶつけると一貫性がなくなりぐちゃぐちゃになりますし、
ルールが無ければ自分の考えるキレイな方法で、あればそれに従う感じになります。
投稿2020/07/06 08:48
総合スコア21203
詳細にご回答いただき、ありがとうございます！
実際の現場によっても運用ルールが異なることもあるんですね...
> 1行で他人に過不足なく説明出来るくらいの粒度にしましょう。
こちら意識しながら運用していきます。ありがとうございました。。
0
実際の開発現場ではどのような粒度でコミットしているのか知りたいです。
その現場にガイドラインがあればそれに従いましょう。
ない場合、コミットの粒度に決まりはないので好きにやればいい話になりますが、迷うのであればその現場の人にまず相談しましょう。
一般論としてのどうやるのが望ましいのかを漠然と知りたい、ということであれば、GitHubで興味のあるリポジトリ（なるべく世間的な評価が高そうな人のもの）を複数見て参考にすれば良いんじゃないでしょうか。
投稿2020/07/06 07:15
総合スコア8947
あなたの回答
tips
プレビュー
