問題タブ [git-branch]

Gitリポジトリの既存のブランチの名前を変更するにはどうすればよいですか？

現在のブランチに新しい名前を付けたい。

私の学校のプロジェクトでは、特定のプロジェクト用にいくつかのサブディレクトリを持つ1つの大きなリポジトリを持っていました。時間がなかったので、私はいつもブランチに何かをコミットしましたmaster。

問題は、古いコミットを元に戻したり、メッセージを読んでいないときにどのコミットが何に属しているかを把握することがますます困難になるため、これは実用的ではないことが判明することです。

現在、次のようになっています。

Dir-tree：

レポ：

ほとんどすべてのコミット（手動で修正できる約5つを除く）は、これらのフォルダーの1つにあるファイルを変更するだけであることがわかりました。

プロジェクトにコミットを自動的に割り当てて別のブランチを作成するという面倒な作業を行う簡単な（自動化された？）方法（スクリプト？）はありますか？私は最後にこのようなものが欲しいです：

レポ：

私はGitが初めてで、現在この状況にあります：

• 4 つのブランチ (マスター、b1、b2、および b3) があります。
• b1-b3 に取り組んだ後、他のすべてのブランチにあるはずのブランチ マスターを変更する必要があることに気付きました。
• 必要なものを変更しましたmaster...ここに私の問題があります：

master他のすべてのブランチをブランチ コードで更新するにはどうすればよいですか?

まず、これが重複していたら申し訳ありませんが、検索してみましたが、Git でブランチを作成する方法などに関するものしか見つかりませんでした。それは私が探しているものではありません。私は、さまざまな人々がワークフローに合わせて Git ブランチをセットアップする方法を理解しようとしています。

私たちの会社がどのようにそれを行うかの例を挙げましょう：

1. 開発者は自分のブランチにローカルでコミットします
2. 開発者はコミットをリモートにプッシュし、そこで継続的なビルド システムがそれをチェックし、別の開発者がそれをレビューします
3. レビュー/ビルドが合格した場合、コミットは QA ブランチにマージされます (失敗した場合、レビュー/ビルドが合格するまでさらにコミットが行われます)
4. コミットが QA に失敗した場合、元に戻すコミットが行われます。
5. 十分な QA コミットの準備ができたら、マスター ブランチがコミットを取得します (QA ブランチはマスター ブランチに基づいているため、マージは必要ありません)。
6. マスター ブランチから定期的にブランチが取得され、「野生に」リリースするために使用されます。ここで問題が見つかった場合は、元に戻すコミットを使用してコードを削除します
7. リリース後、開発者は自分のブランチをマスター ブランチにリベースします (以前のコミットと他の開発者のコ​​ミットの両方を取得します)。

さて、このシステムにはいくつかの問題があります。コメントでいくつかメモしますが、「私たちのシステムを修正してください」を実際に探しているわけではありません。代わりに使用できる他の分岐オプションを確認しようとしているだけです。さまざまな可能性。

したがって、Git を使用する複数の企業で働いたことがある場合 (または、Git のセットアップを大量に見たコンサルタントの場合はなおさらです) を共有していただけますか?それらの間で）開発のさまざまな段階を容易にするために...できるだけ迷惑を最小限に抑えようとしていますか？いくつかの一般的なパターンがあるに違いないと確信しています...しかし、それらが何であるかはわかりません。

PS Git のセットアップを 1 つしか見ていないが、興味深いと思われる場合は、ぜひ投稿してください。ただし、考えられるオプションの内訳を最もよく示してくれる人に答えを与えたいと思います。それは、いくつかの Git セットアップを見た人から来ると思います。

私のタスクは簡単だろうと考えて、マスターブランチの作業を開始しました。しばらくすると、もっと多くの作業が必要になることに気づき、このすべての作業を新しいブランチで行いたいと考えました。

masterを汚さずに新しいブランチを作成し、これらすべての変更を持ち込むにはどうすればよいですか?

gitosis の新しいインスタンスをインストールしましたが、古いインスタンスもあります。

リポジトリを古いサーバーから新しいサーバーに移動するにはどうすればよいですか? 新しいサーバーで複製しますか?

リモート ブランチを切り替えるには、開発者のコ​​ンピューターで何を変更する必要がありますか? それとも、再度クローンを作成する必要がありますか?

私はGitに移行しているSVNのプロジェクトを持っています。プロジェクトは「コア」製品（トランクの下）で構成され、同じリポジトリ内で分岐され、製品をロールアウトする個々のクライアントごとにカスタマイズするための開始点として使用されます。

これらはトランクにマージされることは決してないため、実際のブランチではないように思われます。また、「トランク」リポジトリにリンクしている履歴とプルする機能を備えた独自のリポジトリに住んでいる方がよいでしょう。必要に応じてトランクからの変更で（もちろんgitで簡単に実行できます）。

少し複雑なのは、あるクライアントが独自のプロジェクトのブランチを持っていることです。これは、ある時点でそのクライアントのメインブランチにマージされるという意味で「実際の」ブランチです。

うまくいけば、物事をより明確にするために、SVN構造は次のとおりです。

• 「プロジェクト」リポジトリ
  • トランク
  • ブランチ
    • Client1（Trunk v100から分岐）
    • Client2（Trunk v150から分岐）
    • Client2-ブランチ（Client2 v200から分岐）
    • Client3（Trunk v150から分岐）

そして、私が行きたい構造は

• 「プロジェクト」リポジトリ

• Client1リポジトリ（SHA123からフォーク）

• Client2リポジトリ（SHA456からフォーク）

  • Client2-ブランチ（SHA456789から分岐）

• Client3リポジトリ（SHA789からフォーク）

誰かがこれを行うための良い方法をお勧めできますか？私はGitの初心者ではなく、フィルターブランチを知っています。この構造を取得し、可能な限り多くの履歴を保持するためにどのような方法をとるべきかわかりません。

ありがとう

Pretend I branched from my master branch to a topic branch, and then I did a few commits on my topic branch. Is there a command that tells me the commit hash on the master branch that my topic branch originated from?

Ideally, I wouldn't have to know how many commits I've made ( trying to avoid HEAD^5 ).

I've googled and SO'd around and can't seem to land on the answer. Thanks!

私がよく遭遇する一般的なワークフローのハードルは次のとおりです。

masterは「安定した」ブランチです

ブランチにモジュールを作成する

マスターまたは他のブランチで作業する

次の数週間で、より多くのコードが直接、または他のブランチによってマスターされる予定です。このfoo期間、ブランチは変更されません。

作業を再開し、fooブランチを更新します

大野！fooは大幅に時代遅れです! 理由は理解できますが、同期を戻す必要があります。

質問

masterブランチから最新のコンテンツを取得するにはどうすればよいですか?

新しい機能を追加したかったので、master からブランチ A を作成しました。機能を完成させた時点で、ここまでのすべてをコミットしました。しかし、その後、私はブランチで作業を続けましたが、そのコミット以降に行ったすべてのことは、マスターから離れた新しいブランチ (それを B と呼びます) でより論理的に意味があることに気付きました。

これで、変更を A にコミットし、それを master にプルし、次にブランチ マスターにプルし、それを B と呼び、続行することができます。しかし、本当に物事をきれいに保ちたいと思っていて、最後のコミットを A から master にプルし、ブランチ B を作成して、現在 A にあるコミットされていない変更をプルしたい場合はどうすればよいでしょうか?