5

私はgitが初めてです。私が行ったことは、興味のあるいくつかのリポジトリをフォークし、それらを自分のコンピューターに複製してそれらを操作することです。

元のプロジェクトの一部は、ローカル コピーをいじったために大幅に更新されたり、些細な変更を加えたりする可能性があります。

私が理解していることから、クローンを「リベース」して、元の変更を「プル」することができます。

それは私の変更に何をしますか? たとえばDoSomething.cpp、元のファイルがあるとします。私はそれを修正し、おそらく小さなバグを修正したり、機能を追加したりします. 今！1 年後、元のプロジェクトは多くの改訂を経て、はるかに優れたものになりました。これらの変更をクローンに「プル」したいのですが、変更も保持します。（つまり、これは一種のプッシュの逆です）

これは簡単ですか？もしそうなら、基本的な考え方は何ですか？

私が望むのは、元のクローンからの私のクローンの変更 (私が変更したもの) は上書きされませんが、実際に私の変更を元の (フォーク上の) とマージし、実際にチェックして確認する機能を与えられることです。変更を受け入れます。(たとえば、DoSomething.cppオリジナルが変更された場合、変更を比較して互換性があることを確認する必要があります。

私はフォークの所有者なので、フォークをリベースまたはハードリセットして、ローカルの変更をフォークにプッシュできるので、これは難しくないと思いますか? （バージョン管理の問題が発生する可能性が非常に高いため、機能するかどうかはわかりません）

4

4 に答える 4

1

そうです、リベースはコードを最新の状態に保つための1つの方法であり、そのために非常に一般的に使用されています。

私の経験では、リベースはgit履歴の管理という点でより便利です。それはあなたの歴史を素晴らしくそして直線的に保ちます、それは仕事が並行してではなく連続して起こったように見せます。一方、定期的なマージには、多くの発散/収束コミットが含まれます。git log --graphこの違いを視覚的に確認するために使用できます。

簡単に言うとrebase、コミットを取得してパッチに変換し、リベースするブランチに適用します。競合がある場合、gitは停止し、解決するように求めます。その後、競合を続行できます。ですから、あなたはまだ競合をマージして解決していますが、それは歴史を直線的にする方法です。

于 2013-01-02T00:01:26.103 に答える
0

  1. 現在のブランチを見つけます。これは で行われgit statusます。1 行目または 2 行目にブランチの名前が表示されます。

  2. テストのために、最初に変更を別のブランチに分岐することをお勧めします。

    git checkout -b my-patches

  3. ここで、すべての変更がコミットされていることを確認してください。このために、もう一度 を呼び出しgit statusます。理想的にはWorking directory cleanと表示されるはずですが、そうでない場合は、 を使用git addして変更をインデックスに追加し、git commit最終的にそれらをコミットします。変更をいくつかの異なるパッチセットに分割したい場合 (競合が発生した場合に便利です)、使用方法を読むことをお勧めしますgit commit -p。すべての変更がリストに表示されなくなるまで、これを行いgit statusます。git statusにリストされている、おそらくビルドの結果である、触れていないファイルがいくつかあります。そこに保持したい変更がない場合は、問題ありません。

    ディレクトリのクリーンアップをサポートするメイクファイルなどがある場合 (make cleanたとえば)、すぐに実行します。

  4. 次に、次を使用して元のブランチに戻ります (master手順 1 で見つけたブランチ名に置き換えます)。

    git checkout master

    すべてが機能していることを確認するには、次を実行します。

    git diff my-patches

    フォークで変更した行がリストされているはずです。そうでない場合は、何か問題が発生しています。

  5. 恐ろしい部分が来ます。このブランチに加えられたすべての変更を破棄します。ステップ 3 で説明したように、すべての変更を別のブランチにコミットした場合、それらは問題ないことに注意してください。不明な場合は、リポジトリ フォルダー全体をコピーしてバックアップを作成できます。次に、実行します（ここでも、master以前のものに置き換えます）：

    git fetch
git reset --hard origin/master

  6. 理想的には、ブランチはブランチの正確な状態になっているはずorigin/masterです。すべてが正常に見えることを確認してください。次に、次を使用して変更をマージします。

    git merge my-patches

    Git はできる限り手間がかからないように最善を尽くしますが、競合が発生する可能性があります。Git は、それぞれのファイル内のそれらを>>>>と`<<<<マーカーでマークします。競合を解決するには、インターネットで調査するか、開いている Git Book の Basic Merge Conflicts に関するセクションを読むことをお勧めします。後で必ずマージをコミットしてください。

  7. 難しい部分は終わりました。一時ブランチを削除できるようになりました。

    git branch -d my-patches

    一時ブランチを使用した理由は、リポジトリの状態をマージ試行前の状態に簡単に戻すことができるようにするためです。もちろん、別のブランチでリモート ステータスをチェックアウトすることもできますが、私はこの方法を好みます。

于 2012-11-29T16:15:08.283 に答える
0

分岐したリポジトリに上流のリモートを追加しましたか? これは、フォークをマスターと同期させる最も簡単な方法です。ここでステップ 3です。

于 2013-01-07T20:41:39.317 に答える
0

最初に、「マージ」または「リベース」のどちらを行っても変更が失われることはなく、git は変更をコミットして競合 (存在する場合) を解決し、変更をリモート リポジトリにプッシュする機会を与えることを知っておく必要があります。から引っ張っています。

gitにこれを行うように指示している場合git pull:(プルのデフォルトは「マージ」を使用することです)

リモートからファイルの最新のコピーを取得し、それらをローカルの変更とマージします。自動的に解決できない競合がある場合は、手動で解決するよう通知してください。それは簡単です。

git pull --rebaseこれを行うようにgitに指示しているとき：

ローカル コピー (変更したファイル) から変更を一時的に削除*し、リモートから最新のコピーをプルし、変更をその上にマージします。自動的に解決できない競合がある場合は、解決できるように通知します手動で。(技術的には何も削除されていません。これは、あいまいなロジックをより明確にするためのものです。 )

違いは微妙です。2 番目のケースでは、リモートからプルした最新のコピーの上にこれらの変更を加えたように見えますが、どちらの場合も変更が見られます。間違いなく保持されます（そうでなければ、gitの使用は何ですか！）。

マージまたはリベースする必要がありますか? それは長い議論であり、一方が他方よりも優れている場所があり、これにはベストプラクティスがあります。このページにはいくつかの有用なコメントが既に記載されています。オンラインで検索できる詳細情報については、「git merge vs rebase」と入力するだけで、それに関するページがたくさん表示されます:)

お役に立てれば。

于 2013-04-16T13:44:53.770 に答える