2

git を使用しながら、開発とバグ修正にアプローチするための最良の方法について、誰かがアドバイスできるかどうか疑問に思っています。私の会社は最近、集中リポジトリを維持するために github に移行しました。通常、本番サイトにあるマスター ブランチがあります。次に、将来の更新をマスター ブランチに保持するために使用する開発ブランチがあり、各コーダーには独自のブランチ セットがあり (正直なところ、セットは通常 1 より大きくありません)、変更が完了すると開発にマージされます。承認済み。

事は、開発のほかに、たまにバグ修正をしなければならないということです。

通常、私の作業ブランチはかなり汚れていて、多くの変更されたファイルがあるため、常に開発ブランチにあるリポジトリの別のコピーを保持しているため、バグ修正の際にブランチを隠したり変更したりすることを心配する必要はありません。しかし、これにアプローチする方法についてアドバイスがあるかどうか疑問に思っていましたか?

基本的に、私が見つけた唯一の方法は、変更を隠してからブランチを変更することですが、私はそれが好きではありません。

これを入力するときに SO が提供するいくつかの提案を確認しましたが、近いものはありませんでした。

ありがとう。

4

1 に答える 1

2

個人的には、変更されたファイルがたくさんあることは良いことだとは思いません。私は多くの小さなコミットを好みますが、コミットするのを忘れるという問題に興奮することもあります (しかし、より大きな機能の場合はそれ以上です)。

そのような場合は、ブランチを隠して切り替えます。変更されたデータのサイズや種類のためにそれができない場合は、一時ストレージ ブランチを作成し、現在そこにあるすべてのものをチェックインするだけでコミットすることもできます。元のブランチに戻って再チェックアウトするときに、そのコミットを元に戻すことができgit resetます (または、作業中のブランチでまったく同じことを行うだけです)。これにより、(stash とは対照的に) まだインデックスにないファイルもチェックインできます。拡張スタッシュと考えてください。

一時ストレージ ブランチの利点は、それをリモートにもプッシュできることです。たとえば、別のデバイスで作業を続けることができます (開発を中止して別のデバイスで続行する必要がある場合に、デバイス間でダーティ ワーキング ツリーを同期するために使用します)。 .

git-flowは、バグ修正ブランチなどのクリーンなブランチ ワークフローを維持するための優れたヘルパーです。ただし、上記の提案には従わないと思います。

一方、(バグの原因が明らかでない場合) バグハンティング用にクリーンなリポジトリを用意しておくと役立つ場合があることに注意してください。報告ユーザーが持っているバージョンと比較して、微妙な変更が忍び寄る場合があります。

于 2012-12-12T21:36:11.050 に答える