問題タブ [rebase]

リベースはチームメイトの小さな変更用であり、マージは大きな変更用であるというスレッドを知っています。

私は 3 人のチームメイトの 3 つの Git を次のディレクトリ構造に保持しています。ここでは、全員が同じ初期コードを持っています。

ブランチは同じ Git 内にありません。これは、リベースとマージを使用できないことを意味します。チームメイト間の変更を同期するために vimdiff を使用しました。ただし、これには時間がかかります。

すべてのブランチが 1 つの Git の下にある次のディレクトリ構造を作成しようとして失敗しました。

ただし、私とチームメイトのために clone コマンドを実行します。

チームメイトの 2 番目のクローンを実行した後、エラー メッセージが表示されます

コマンドを使用できるようにrebase、3 人のチームでどのディレクトリ構造を使用すればよいですか?merge

git-rebase のドキュメントを読むたびに、迷子になります。私には、一種の低レベルの操作のように感じます (読む: 闇の魔法)。

ドキュメントの引用：

次の履歴が存在し、現在のブランチが「トピック」であると仮定します。

この時点から、次のいずれかのコマンドの結果:

だろう：

問題は、なぜそのようなことをしたいのかということです。

1 つには、分岐が別の時点で開始されたかのように、履歴を「書き換える」ように見えます。基本的に、コミット履歴は「嘘の束」になります。

別のポイントは、安全ではないと感じることです。私は一度それを試してみましたが、たくさんの衝突があり、すべての地獄が解き放たれました. その地獄をどのように解決したか正確には覚えていませんが、記憶が正しければ、一時的なテストブランチかそのようなものでした。

もう 1 つの質問:使用方法がわからないために、非常に優れた/時間を節約できる一連の機能を見逃していませんgit-rebaseか?

編集：

関連する質問: git rebase の取り消し

git での日常的な開発作業用のローカル ブランチがあります。私のワークフローは次のとおりです。

1. local_branch で処理を行い、コミットします
2. オリジン/マスターを取得
3. origin/master からの新しいものに追いつくために local_branch をリベースします

すべて正常に動作しますが、私が遭遇した推奨事項のほとんどは、リベースが定期的に実行されるプライベート ブランチを「プッシュ」すべきではないと述べています。

ここでの問題は、この場合、ローカル ブランチがサーバーにバックアップされておらず、作業を保存する唯一の方法は、それを「プッシュ可能な」ブランチ (つまり、オリジン/マスター) にマージすることです。

この場合のワークフローに関する推奨事項は何ですか?

ありがとう！

更新：私が持っていた元の要件の1つ（外部ユーティリティの使用を避ける）は、不必要な制限であることに気付きました。

私の現在の解決策は、すべてのリポジトリをクラウド同期フォルダーに保存することです。これにより、無料でバックアップを取得できます。

複製した中央の git リポジトリを使用しており、ローカル ブランチで作業しています。

変更を中央リポジトリで利用できるようにしたい場合は、次のコマンドを発行する必要があります ( からmybranch)。

同じ目標を達成するために、より少ない git コマンドを使用できるかどうかを知りたいです。masterとの間のいくつかの切り替えmybranchは特に煩わしいものです。これは、リポジトリがかなり大きいため、時間がかかるためです。

私の個人的な WordPress インストールは、GitHubのwordpress git ミラーから複製されています。2.7.1 タグをブランチ "stable" ( ) にチェックアウトしたところ、git checkout -b stable 2.7.1それ以来正常に動作しています。WordPress 2.8 がリリースされたので、安定版ブランチを 2.8 タグに移動したいと考えています。

次のことを試しました（すべて安定版ブランチで）が、コミットごとに適用しようとすると競合が発生し、何かが正しくないようです。安定版ブランチでローカルの変更やコミットを行っていません。

安定版ブランチを 2.8 タグに「移動」するにはどうすればよいですか?

現在svnで追跡されているWebサイトプロジェクトに取り組んでいますが、他の誰かが新しいサーバーなどをセットアップする時間があれば、gitに移動します。長い話になりますが、それまでの間、私が持っていたコードから独自の git リポジトリを作成し、かなりの作業を行いました。私は海外にいて、インターネット接続が奇妙でHTTPのプロキシが必要で、git svnが通過できないように見えるため、git svn cloneを使用しませんでした。いずれにせよ、私は自分の git リポジトリで開発を行ってきましたが、最終的にプロジェクトが実際に適切にインポートされたら、自分の作業を git-svn のクローンにリベースする必要があります。git rebaseこれは適切に機能しますか？

問題の 1 つは、私が実際に仮想マシンで作業していて、多くのコミットで、user.name と user.email の構成エントリを設定していなかったことを認識していなかったため、コミットが vm のローカル ユーザーからのものであったことです。奇妙なの。すべての変更を diff ファイルにまとめて、作成された新しいブランチの上に適用する方がよいでしょうか?

もう 1 つの問題は、以前の SVN の使用が中途半端だったことです。そのため、実稼働サーバーには、私が持っていなかったコミットされていない変更が実際にありました。実際には、SVN ヘッドでさえないコードの古いリビジョンを最初に持っていたので、その上にいくつかのものが欠けていました。続行する最良の方法は何ですか?

最後の質問の 1 つは、SVN リポジトリを経由してインポートした場合git svn(チェックしたところ、現在は機能しているようです)、作成者ファイルを追加しない場合、後で適切にインポートされたブランチに変更をリベースできるかどうかです。著者ファイルで？

ああ、新しい合併症。私は を使用して SVN リポジトリを自分でインポートしましたgit svn。これは、この遅い接続で 2 日間の大半を費やした大変なプロセスでした。しかし、最終的にクローンを作成した後、SVN リポジトリではコードがすべてサブディレクトリにあることに気付きましたが、私の git リポジトリではリポジトリのルートがディレクトリのルートでもありました。これが少し混乱している場合、基本的にはこのようなものです

SVN:

\dir\codez

ギット：

\codez

2 つのリポジトリを結合するにはどうすればよいですか? リベースを引き続き使用できることを願っていますが、これは非常に奇妙な状況のようです。サブモジュールに似ているように聞こえますが、それは私が必要としているものではないと思います。

マスターからリポジトリの1つ内の「デプロイ」ブランチへのリベースに問題があります。

私のリポジトリは次のように設定されています。

一般的に私のワークフローは次のとおりです。

1. マスターブランチで開発を行います...テスト、笑顔、コミットします。
2. deployブランチをチェックアウト
3. デプロイブランチで実行git rebase masterします-これは問題なく機能していました
4. リモートにプッシュして実行しますcap deploy
5. リラックス

私が今抱えている問題はgit rebase master、デプロイブランチで実行すると、3方向のマージ/手動マージが必要なエラーが発生することです（エラーメッセージは、投稿するのに十分なほど一般的ではないと思います）。Gitは、マージを実行してgit rebase --continueから終了するように指示しますが、これは機能しません。

私が見つけたのは、「実行中」の作業でgit rebase master --interactive、選択リストをクリーンアップし（5回ほど繰り返される「コミット」がありますが、このリストには異なる参照番号（同じメッセージ）があるため、そのうちの1つを選択します）。手動でマージを実行します。コミットごとにこれを実行したら、リベースを続行でき、すべてが幸せになります...

次回まで、リベースを実行する必要があります。

それで、誰かが何が幸せかもしれないか知っていますか？プロジェクトは実際には「秘密」ではないので、必要に応じてメッセージ、ログ、ブランチグラフなどを投稿できます。

ありがとう

インテグレーターのワークフローを使用して git リポジトリを管理しています。言い換えれば、私は同僚からコミットをプルし、それらを祝福されたリポジトリにプッシュします。

ほとんどの場合、コミット履歴を線形に保ちたいので、変更を統合するときにa のrebase代わりに aを実行しても問題ありませんか? merge次に例を示します。

彼らが次にgit pull. git はこれを処理できますか、それともでのコミットの順序が異なるため、 でcoworkerリポジトリが失敗しますか?pullorigin

更新:私は元々、「マスター」から「同僚」ブランチをリベースする例を持っていました。私が意図したのは反対で、「同僚」コミットをマスターの上に置くことでした。だから私は例を更新しました。