質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.91%

コミット の粒度がわからない

解決済

回答 4

投稿

  • 評価
  • クリップ 1
  • VIEW 265

fork_

score 33

git初心者です。
gitでコード管理しながらrailsでアプリケーション作成したいのですが、gitのコミット粒度がいまいちわかりません。
いろいろなサイトを拝見していたのですが、「機能ごとにコミットする」、「戻りたいところに戻れるようにコミットする」と記述してありました。
railsの環境構築を終えて、masterブランチから、developmentブランチを作成したところです。
機能追加ごとに、developmentブランチから、 feature/xxx のような形でブランチを作成し、作り終えたらdevelopmentブランチにmergeする認識です。

先にログイン機能から実装を考えているのですが、この時点でfeature/add login functionのようなブランチを作成するべきなのでしょうか。
「機能ごとにコミットする」というのは、Userモデルを作成したらコミット、usersコントローラーを作成したらコミット、という細かい粒度ではなく、モデル作成、コントローラー作成、ビュー作成、ログイン機能に必要なものを実装し終えた後にコミットするという認識なのでしょうか。
実際の開発現場ではどのような粒度でコミットしているのか知りたいです。

掲示板アプリのようなものを作成しようと考えています。

  • ログイン機能(User,Shopの2つの視点でログインする)
  • サインアップ、サインイン、ログアウトが最低限必要とする。
  • 投稿機能
  • Shopとしてログインしている場合のみ投稿、編集、削除ができる
  • タイトルを入力して投稿ができる
  • 画像を添付して投稿ができる。
  • 投稿をデータベースに保存する。
  • いいね機能
  • Shopの投稿に対して、Userがいいね、いいね解除ができる。
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • hentaiman

    2020/07/06 16:10

    >実際の開発現場
    組織での使い方を知りたいって感じですかね?自分はソロなんで回答出来ませんが

    キャンセル

  • fork_

    2020/07/06 16:14

    個人開発のgitの使い方も是非知りたいです。

    キャンセル

回答 4

checkベストアンサー

+2

まず最初に、一般的なものが知りたかったらgit ブランチモデルで検索してください

以下はソロ活動前提での自分の場合の意見
形になるまではmasterとdevだけで十分(masterが一般的な開発におけるdevの役割)
作業はdevで行いコミットの単位はエラーの出ない状態で都度コミット
機能作成はひとつずつ順番にやればいいので、feature/xxxxは不要(コミットメッセージに書けばいい)
むしろfeature/xxx作ってあっちこっち気が逸れてOKな状態がNG

一通りの機能を作り終えたリリース以降は、普通にdev派生のfeature/xxxを作って開発・修正。devにマージ。

「機能ごとにコミットする」というのは、Userモデルを作成したらコミット、usersコントローラーを作成したらコミット、という細かい粒度ではなく、モデル作成、コントローラー作成、ビュー作成、ログイン機能に必要なものを実装し終えた後にコミットするという認識なのでしょうか。

前者でしょうね。小まめにコミットしておいて好きなところに戻れるのがメリットだと思うので。

git無し開発に慣れてる事もあって簡単なものならNextCloudのオートセーブで十分間に合ってると感じる人の意見です。なので参考にならないかもしれない

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/06 16:48

    なるほどですね。。自分の中でgit運用の指標が出来ました。
    ご回答いただき、ありがとうございました。

    キャンセル

  • 2020/07/06 19:44 編集

    >質問者さん
    私もローカルリポジトリにおいてかなり頻繁にコミットする方ですが、加えて「rebase」を覚えておくときれいにまとめやすくなり、masterにpushするときに冗長で不要なコミットを除去できて良いと思います。

    キャンセル

  • 2020/07/06 19:51

    > 不要なコミットを除去
    自己レスですが、「除去」と書くと消えちゃうイメージが浮かぶので語弊があるかもしれませんね。git rebaseでの「squash」などでのコミットのまとめ上げ、でしょうか。

    キャンセル

0

実際の開発現場ではどのような粒度でコミットしているのか知りたいです。

その現場にガイドラインがあればそれに従いましょう。

ない場合、コミットの粒度に決まりはないので好きにやればいい話になりますが、迷うのであればその現場の人にまず相談しましょう。

一般論としてのどうやるのが望ましいのかを漠然と知りたい、ということであれば、GitHubで興味のあるリポジトリ(なるべく世間的な評価が高そうな人のもの)を複数見て参考にすれば良いんじゃないでしょうか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/06 16:47

    ご回答ありがとうございます。
    実際のリポジトリを見て、理解を深めていきます!

    キャンセル

0

ローカルリポジトリならあなたの好きな粒度にすればいいのでは。
あとでrebaseなりなんなりで綺麗にできますし。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/06 16:50

    ご回答ありがとうございます。
    なるほどですね。。

    キャンセル

0

コミットする時、基本的にメッセージを付け加えます。
git commit -m "コミットメッセージ"

後からgit logsで一覧表示した時に、
それに付随するメッセージを確認出来ます。

あれもこれもそれも実装して1コミットに収めると、
メッセージと全く関係のない仕事がこっそり紛れ込んでしまいます。

言ってる事とやってる事が違う人ってどう思いますか?
嘘つき!ってなりますよね。

人間は一貫性を求める生き物なので、
1行で他人に過不足なく説明出来るくらいの粒度にしましょう。
これが丁度良いコミットの単位です。


因みに現場によって決まっている事もあります。

例えばGitHubでは機能要望をIssueという要望掲示板に書き込んで、
プルリクエスト時にこのIssueと関係のある修正だよみたいな使い方が出来ますが、
そのIssueのID番号をコミットメッセージに含めて管理しましょうみたいなプロジェクトもあったりします。

ブランチ切って、プルリクエストを投げる時にコミットをまとめて1個に潰す。
これはこれで一貫性があって美しい管理方法ですね。

こんな風にルールが存在する現場に後から入って、
僕が考える最強のコミット履歴管理方をぶつけると一貫性がなくなりぐちゃぐちゃになりますし、
ルールが無ければ自分の考えるキレイな方法で、あればそれに従う感じになります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/06 17:56

    詳細にご回答いただき、ありがとうございます!
    実際の現場によっても運用ルールが異なることもあるんですね...
    > 1行で他人に過不足なく説明出来るくらいの粒度にしましょう。
    こちら意識しながら運用していきます。ありがとうございました。。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.91%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る