1

特に、開発過程で「歴史を失う」ことのマイナス面は何だろうと思っていました。有名な例の1つはもちろんgit rebase -i/ですが、ここで「変更をメインラインに送信する前にコミット履歴をクリーンアップしたい」で説明されているgit merge --squashものもあります。

パッチをエクスポートして別のブランチに適用すると、ブランチの「履歴」が失われることがわかりますが、マージされた後、そのブランチとそのコミット履歴が役立つのはなぜですか？

誰かがそのような技術が「汚い」と見なされる理由を詳しく説明できますか？メインブランチに適用できる限り、最初に変更が最初にコミットされた順序が重要なのはなぜですか？

4

3 に答える 3

1

このことを考慮：

* (master) Merge feature-branch into master
|\
| * (feature-branch) Fix a comment typo
| * Add comments
| * Add feature task 3
| * Consolidate feature tasks 1 and 2
| * Add feature task 2
| * Forgot a semi-colon
| * Add feature task 1
|/
* Older commit on master

対これ：

* (master, feature-branch) Add feature
* Older commit on master

feature-branch最初のものはintoの (--no-ff) マージでmaster、下は on のスカッシュ/リベースですfeature-branch。master1 つ目は非常に詳細で、これにより回帰テストがより焦点を絞ったものになりますが、機能ブランチが多数ある場合は面倒になります。2 つ目は、多数の機能がある場合に読みやすくなりますが、ブランチ定義が失われます。独自の方法は、プロジェクトのサイズ、チームのサイズなどによって異なります。

個人的には、このコミットの経験則を気にする人は誰でも構いません。たとえば、コメントのタイプミスを修正したなど、下流の誰も気にしません。rebase -i通常、プッシュする前に、最初の例を次のように ( を使用して) 変換します。

* (master) Merge feature-branch into master
|\
| * (feature-branch) Add feature task 3
| * Add feature task 2
| * Add feature task 1
|/
* Older commit on master

ブランチ ヒストリの関連部分はまだ明らかで、残りは押しつぶされています。

于 2012-06-10T16:37:18.743 に答える
0

履歴が自分にとって何の役にも立たない場合、マイナス面はありません。実際、多くの開発者は別のブランチ ( ) で新しい機能を作成しfeature/1234、マージする代わりに - ブランチにリベース/スカッシュしdevelopて機能ブランチを削除します。その理由は、通常、機能を実装する場合、後の実装ステップすべてに関心があるのではなく、機能全体に関心があるためです。ただし、コミットを保存するという理由だけで、共通点のないコミットを押しつぶすことは避けてください。コミットが多いことにもマイナス面はありません。

于 2012-06-10T16:25:25.363 に答える
0

製品品質のコードを管理することに加えて、git を製品全体のグローバルで無制限の柔軟な元に戻す機能として扱うことができます。「未公開の履歴」には、タイプミス、うまくいかなかった実験、その時点でそこにいて、後で分割される可能性があるという理由だけで行った、無関係のマイナーな修正などが含まれる可能性があります。元に戻すことに眉をひそめる考え方を理解したことがありません。

書き直したものと書き直したものを比較します。新しいバージョンがあなたのニーズをよりよく満たすなら、それはより良いです. オリジナルの何かが新しいバージョンでは満たさないニーズを満たしている場合、それはマイナス面です. 特に自分のレポに残っている未公開のものについては、そこにあるものはあなたが好きなように扱うことができます。

于 2012-06-10T16:26:35.040 に答える