NASMソースファイルからいくつかのPerlプログラムを書き直し始めました。私はすでに自分の作業コピーに対していくつかのコミットを実行しましたが、実行する必要があったのであれば、実行する代わりに実行する必要があるのではgit pullないかと考えていgit rebaseました。
私は自分がやるべきだとほぼ決心しましたがgit rebase、その効果を達成するために、あるいはそれが可能であるとしても、リポジトリを作り直す方法がわかりません。
質問する
8473 次
5 に答える
6
それは可能であり、Git Magicチュートリアルでその方法を説明します。しかし、他の誰かがあなたのブランチを見た場合、それは安全ではありません。他の誰もあなたのブランチを見ていないとしても、再考するように促します.
なぜリベースがあるのですか？プル/マージしないのはなぜですか？
リベースの目的は、履歴を書き換えて、ソフトウェアが実際に進化した方法ではなく、ソフトウェアが進化したはずだと信じている方法をリポジトリが反映するようにすることです。これはいつ重要ですか？あなたが分散型開発チームのジュニア メンバーであり、コミット権限を持っていない場合、できることはゲートキーパーにパッチを提出し、それが受け入れられることを願うことだけです。受け入れられる可能性を最大化するには、履歴を書き直して、パッチをできるだけクリーンで明確にする必要があります。開発モデルは聞き覚えがありますか?
Manoj Srivastava は、 rebase-vs-merge のかなり思慮深い分析を書いています。
于 2009-05-10T20:28:52.917 に答える
2
過去に次の方法で成功しました。
このメソッドには、次のエイリアスを追加しました。
up = pull --rebase origin
- マスターブランチを「dev」などに分岐します
- 開発で働く
- 変更の追加とコミットが完了したら
- マスターを片付ける
- マスターに切り替える
- gitマージ開発
- ギットプッシュ
リモート リポジトリから変更を取り込む場合:
- マスターに切り替える
- 立ち上がる
- 開発者に切り替える
- マスターを片付ける
YMMV
于 2009-05-10T18:31:25.853 に答える
2
- 現在のコミットがマージ コミットであることを確認します。
git log - 最初に、マスターを以前のコミット (マージの直前のもの) に再設定します。
git reset HEAD^- HEAD^の意味: 「HEAD によって参照されるコミットの前のコミット」
- これで、通常のリベースを実行できます: git rebase origin/master
次回は、git fetchステップ 3 としてリベースを実行することをお勧めします。
リベースが失敗した場合に備えて、現在の git リポジトリの小さな tarball を作成することをお勧めします。自信が持てるようになると、それほど頻繁に行うことはなくなります (通常、git でほぼすべてを修正できますが、tarball の方が速い場合もあります)。
于 2009-05-10T20:57:13.290 に答える
0
次のようにブランチを変更することで、最後のマージを取り消すことができるはずです。
git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master
その後、リベースを試すことができます。
于 2009-05-10T20:50:12.553 に答える
-1
ダスティンの返信のフォローアップとして、「git config --global branch.master.rebase true」にする必要があります。
于 2009-08-26T18:53:53.763 に答える