Gitの運用について。masterブランチへをキレイに運用したい。
解決済
回答 1
投稿
- 評価
- クリップ 1
- VIEW 1,544
git勉強中の者です。今までは一人で開発していたため、常にmasterブランチにコミットする使い方をしていました。
ところが、今後、複数人でgitを使った開発を行うプロジェクトが始まりました。
実は他の人もgitはあまりわからず試行錯誤しながら運用しています。
現在は、機能追加や修正等の案件ごとにブランチを作り、各ユーザーがそのブランチを共有して開発。
案件ごとに、上長のOKが出たところでmasterへマージするという方法を取っています。
ところが、これだとmasterブランチに各ブランチ内でのコミットも反映されますよね？
例えばブランチAで「部品1追加」「部品2追加」「部品1修正」等のコミットがあった場合は、
ブランチAをmasterにマージすればこれらのコミット内容も反映されますよね。
しかしこの方法だと、「やっぱりこの機能は外したい」と言った時にどのコミットまで遡れば良いのか混乱してしまいます。
わかりやすく言うと、masterのログには「機能A追加」「修正No110反映」などと言った最終形態？の状態を反映するだけにして、
それぞれの案件内で行ったコミットログなどはmasterには反映させたくないのです。
このような場合はどのように運営していけば良いのでしょうか。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+1
こんにちは。
ブランチ上のコミットをマージする際に一つにまとめるのは--squashオプションを使うことで一発で実現できますが、質問者さんが本当に求めているものは、おそらく--no-ffオプションではないでしょうか。
merge --no-ffは、マージする際にFast-Forwardingを無効にし、常にマージコミットを作成するようにします。これを使用することで「masterからブランチAへ分岐した地点」「ブランチAをmasterにマージした地点」を常にコミットログに残すことが可能になります。
運用方針次第ではありますが、質問の通りに機能単位でコミットを一つにするというのは、masterにマージするような段階で行うのはあんまりオススメできないです。ブランチA上で積み重ねたコミット履歴を捨てていることと同義だからです。gitの持つ「変更履歴」という大きなメリットを活かすことができなくなります。
逆に、コミットの内容がWIP段階である場合や、実験的なブランチを操作する段階ではコミットをまとめたほうが見栄えが良くなるため、そういう場面で--squashは役に立ちます。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.34%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2017/05/24 18:56
>ブランチA上で積み重ねたコミット履歴を捨てていることと同義だからです。gitの持つ「変更履歴」という大きなメリットを活かすことができなくなります。
これが懸念していたところです。
あくまでもブランチA内で行った履歴は残しておいていつでも見れるようにする。
masterでは「ブランチAで機能を追加した」というログだけあればいいかなと思ったのです。
でもそうなると案件ごとにどんどんとブランチが残っていくということになりますよね。
ブランチが残るということは容量が圧迫される、ということにつながります。今更ながらに気づきました。
皆さんはmasterにマージした後は不要なブランチと言うのはどんどん削除していくものなのでしょうか。
もしブランチを削除していくのであれば、masterには全ての履歴が残ったほうが確かに良いかなと思います。
2017/05/24 23:01
まず、gitにはブランチという「実体」は存在しません。gitに存在するものは無数の「コミット」オブジェクトだけであり、コミットが連なった鎖の先端に名前を付けたものをブランチと呼びます。コミットオブジェクトの先頭を変数に格納するようなイメージです。ただの変数がデータサイズにほとんど影響しないことは分かると思います。
ブランチの削除を行うことは、単なるリポジトリの片付けに近いもので、行うかどうかは運用方針次第です。マージしたら即座に削除する運用もあれば、ずっと残し続ける運用もあり得ます。
gitは「変更履歴」を永久に残し続けることが目的の一つなので、あまりにもダーティな履歴を全ては残したくない、という場面以外では、コミット履歴を改ざんするのは好ましくないです。一般的な運用方針であれば、「ブランチA」の履歴はmasterに丸ごと残しておくのが正道だと思います。