問題タブ [rebase]

gitとRailsを使用した希望のセットアップについてアドバイスが必要です。

基本的に、最初のRailsアプリケーションでは、GitHubの基本アプリケーションテンプレートを使用しました。その後、大量の変更を加え、かなりカスタマイズされた完全なアプリケーションを作成しました。

これで、ベースアプリケーションテンプレート内のファイルに加えたすべての変更を抽出し、変更をgithubリポジトリのフォークにコミットしました。理想的には、ベースアプリケーションテンプレートをアプリケーションのブランチとして使用し、マスターを使用してリベースしたいと思います。これは実際に可能ですか？

これを実行したい理由：ベースアプリケーションを最新の機能に保ちたいので、次のプロジェクトでは、githubフォークからベースアプリケーションテンプレートのクローンを作成して作業を開始できます。同様に、誰かがベースアプリケーションテンプレートのバグを修正した場合、それらの修正を、ベースアプリケーションテンプレートをブランチとして持っているアプリケーションとマージできますか？

これは可能ですか？これを行うためのより良い/より一般的な方法はありますか？

前もって感謝します！

ありがとう、

ダニー

以下は、私がよく直面するシナリオです。

masterまたはに一連のコミットがあり、ブランチdesignの上に置きたいと思います。production

productionこれらのコミットをチェリーピックしてマージするため、ベースを持つ新しいブランチを作成する傾向がありますproduction

次に、master本番環境にマージすると、変更が同じであっても、チェリーピックのために別のコミットとして登録されるため、マージの競合に直面します。

これに対処するためのいくつかの回避策を見つけましたが、それらはすべて面倒であり、「ハック」と呼ぶことができます。

私はあまりリベースを行っていませんが、それによっても新しいコミット ハッシュが作成されると思います。

チェリーピッキングしている場所でリベースを使用する必要があります。これよりも他にどのような利点がありますか。

私のラップトップと職場、そして自宅のデスクトップの両方で、6 つの異なるブランチとマージで数週間働いた後、私の歴史は少し複雑になりました。たとえば、フェッチを行った後、master を origin/master とマージしました。ここで、git show-branches を実行すると、出力は次のようになります。

これを git rebase でクリーンアップしたいと思います。この目的のために新しいブランチ rebase-master を作成し、このブランチで git rebase <common-ancestor> を試しました。ただし、多くの競合を解決する必要があり、ブランチ rebase-master の最終結果は、既にテスト済みで動作する master の対応するバージョンと一致しなくなりました!

どこかでこれに対する解決策を見たと思ったのですが、もう見つけることができません。誰もこれを行う方法を知っていますか? それとも、既にマージした不要なブランチの削除を開始すると、これらの複雑な参照名はなくなりますか?

私はこのプロジェクトの唯一の開発者であるため、影響を受ける人は他にいません。

git rebase を実行するとき、競合を解決するときに「ローカル」と「リモート」で何が起こっているのかを理解するのが難しいことがよくあります。あるコミットから次のコミットへと側面が入れ替わっているような印象を受けることがあります。

これはおそらく（間違いなく）私がまだきちんと理解していないためです。

リベースするとき、誰が「ローカル」で誰が「リモート」ですか?

(競合を解決するために P4Merge を使用します)

Git を初めて使用するほとんどの人のように、私も git merge と git rebase に適用可能なユース ケースを解読しようとして混乱に陥りました。結果として得られる作業コピーの状態に関しては、同じことが得られると最終的に判断したと思います。また、どちらも同じ競合を引き起こします。これが間違っている場合は、私を啓発するための例を提供してください。

私の見解では、(変更がプッシュまたはプルされていない場合) マージの代わりにリベースを使用する主な利点は、履歴を線形に保つことです。私が本当に理解していないのは、git-rerere を開発する理由です。

マンページから、 git-rerere は、以前に解決した競合を解決しようとしている場合に役立つはずです。これから参照する例は、http://www.kernel.org/pub/software/scm/git/docs/git-rerere.htmlにあります。

プロジェクトのポリシーが、メインラインからトピック ブランチ (Linux カーネルなど) に変更を常にマージしないことである場合、上記の例では、「使い捨て」マージ コミットを作成するように指示されています。基本的に、マスターをトピックにマージし、テストを実行してすべてが機能することを確認してから、「git reset --hard HEAD^」を実行して、本質的にマージ コミットを破棄します。後で、別の「使い捨て」マージ コミットを作成すると、最初の使い捨てマージで既に解決した競合を解決するのに git-rerere が役立ちます。

一時的なマージ コミットを作成するという面倒な作業をすべて行う代わりに、開発者が自分のトピックを master にリベースしない理由を説明してもらえますか? それが git-rebase のポイントではありませんか?変更を取得しますが、マージは避けますか? これは同じことを達成しませんか? また、誰もあなたのトピック ブランチの変更をプルしていないと仮定すると、これははるかに簡単なアプローチではないでしょうか? throw-away-merge+git-rerere ワークフローは本当に、変更がプッシュ/プルされた場合のためのものですか?

最後に 1 つの質問 - Linus は次のように述べていると引用されています。そこにいる...」 定期的なリベースでも、Linus は問題を抱えているでしょうか?

以下は、「git svn rebase」を試したときに表示されるエラーです。

私が実行しているperlのバージョンは次のとおりです。

Web で「Byte order is not compatible」を検索すると、多数のヒットが表示され、次のような Perl ドキュメントが表示されます。

これが意味することは、Unix または Linux で 64 ビット整数で構成された perl 5.6.0 または 5.6.1 で実行されている Storable 1.x によって書き込まれたデータがある場合、デフォルトでこの Storable はそれを読み取ることを拒否し、エラー Byte order を与えることです。互換性がありません。そのようなデータがある場合は、$Storable::interwork_56_64bit を true 値に設定して、この Storable が古いヘッダーでファイルを読み書きできるようにする必要があります。また、データ、または通信している古い perl を、この現在のバージョンの Storable に移行する必要があります。

私が知らないのは、この「$Storable::interwork_56_64bit」を true に設定する方法です。やり方を教えてください。

これがわかりません:「git pull --rebase リモート ブランチ」を実行すると、HEAD が共有ルートに戻り、その間に発生したすべてのリモート コミットの再生が開始されます。これらのコミットが時々失敗するのはなぜですか? それらはクリーンなワークスペースでのクリーンなコミットですか? それはほとんどリベースのポイントではありませんか？

この方法でブランチをマージしやすくなり、競合が少なくなります。

トランクを新しいブランチにコピーし、機能ブランチとマージします。完了したら、新しいブランチをトランクにマージします。この手法は、MercurialやGitのリベースによく似ています。

以前は、トランクから機能ブランチに変更されたものをマージしていました。しかし、後で機能ブランチをトランクにマージすると、トランクからの一部が再びトランクにマージされ、多くの競合が発生しました。再統合マージの選択肢がありますが、それは私にはうまくいかなかったようです。

誰かが同様の破壊リベースをしますか？私は最近これを始めたばかりで、副作用は見られませんでした。これにより、予期しない問題が発生しますか？

私は、Rails サイトの一部の git ブランチで作業しています。反復中にスキーマに多くのランダムな変更を加え、以前の移行を元に戻して列などを追加するいくつかの移行を行いました。このような冗長な移行 (つまり、互いに逆になっている移行のペア) を削除しても問題ありませんか? 他の誰もこのブランチで作業していないため、なぜ問題が発生するのかわかりません。最終結果は同じになります。このまま進めば何かトラブルはありませんか？

私は毎日の作業をすべてgit-svnで行い、チェックインをキューに入れ、狂った男のようにリベースします:)これの欠点は、2、3日の作業がキューに入れられることが多いことです（私が知っているtisk tisk）。一箇所だけで緊張します。git-svnを使用せず、常にリベースを行っていなかった場合は、変更を別のコンピューターにプッシュして、愚かでデータが不足している場合はクローンを作成します。

頻繁にリベースされるgitリポジトリをプッシュすることについてのあなたのアドバイスは何ですか？