問題タブ [git-branch]

ほぼ毎日更新およびリリースする Web アプリがあります。VCS として git を使用しており、現在の分岐戦略は非常に単純で壊れています。マスター ブランチがあり、「良いと思う」変更をそこにチェックします。これは機能しますが、重大な変更をチェックインするまでのみです。

次の要件を満たす、小規模なチーム向けのお気に入りの git ブランチ戦略を持っている人はいますか?

1. 2 ～ 3 人の開発者のチームに適しています
2. 軽量で、プロセスが多すぎない
3. 開発者は、バグ修正やより大きな機能の作業を簡単に分離できます
4. 安定したブランチを維持できる

理想的には、開発者が新しいバグに取り組んでいる段階的なプロセスを見てみたいです

2つのブランチを持つgitリポジトリがあります。リポジトリのクローンを作成すると、マスターブランチしか表示されません。私は両方の支店を最新の状態にしています。問題は、マージと分岐を完全に理解していないことです。くそー！

私の例はここで見ることができます：

http://github.com/rimian/rimian/network

誰かがこれを通常に戻す方法を教えてもらえますか？

プッシュはブランチではなく引数としてのみユーザーIDを認識できるため、GIT更新フックにロックスクリプトを配置することにより、ユーザーがファイルをプッシュすることからリポジトリをロックするという考えがあります。したがって、ディレクトリをロックしているだけのレポ全体をロックできます。

GIT で特定のブランチをロックする方法はありますか?

または、ユーザーがプッシュしているブランチと、コードがプッシュされているブランチを Update Hook が識別できる方法はありますか?

私は現在 ClearCase に取り組んでおり、現在 GIT に移行しています。しかし、すべての作業が GIT で行われ、データが ClearCase ストリームに同期されるように、この移行が必要です。GIT と CC の両方で同じブランチ名とストリーム名を使用するため、スクリプト作成は問題になりません。ここでの問題は、

CCとGITを同期するのに最適なモデルを提案できますか

1. CC のすべての Vob を GIT の単一リポジトリとして保持し、CC の主要なストリームを GIT のさまざまなブランチとして保持します。- 単一の GIT リポジトリ (VOBS) と多数のブランチ (CC ストリーム)。- VOB が多くのブランチを持つ単一のレポとして保持されるため、これはより少ないスペースを占有します。

2. 重要な CC ブランチを独立した GIT リポジトリとして配置し、各リポジトリにすべての CC VOB を配置します。- 多数の CC ブランチ用の多数の GIT リポジトリ - VOB が複製されるため、これは多くのスペースを占有します。

ClearCase との同期を維持するための最良の方法はどれだと思いますか?

次のシナリオがあります。

3つのブランチ：
-マスター
-システムの新機能を開発する目的でマスターから
分岐したMyBranch-ブランチのローカルコピーとしてMyBranchから分岐したMyBranchLocal

MyBranchは、他の開発者（私と同じ機能に取り組んでいる）に対してリベースされ、プッシュされています。

MyBranchブランチの所有者として、リベースしてマスターとの同期を維持したいと思います。また、MyBranchLocalに加えた変更をMyBranchとマージする必要があります。

それを行うための良い方法は何ですか？

私がこれまでに試したいくつかの可能なシナリオ：

I.1.MyBranchLocalへの
変更をコミットします
2.マスター
に対してMyBranchをリベースします3.MyBranchに対してMyBranchLocal
をリベースします4.MyBranchをMyBranchLocalとマージします

II。
1.MyBranchLocalへの変更をコミットします
2.MyBranchをMyBranchLocalとマージし
ます3.MyBranchをマスターに対してリベースします
4.MyBranchLocalをMyBranchに対してリベースします

III。
1.変更をMyBranchLocalにコミットします
2.MyBranchをマスターに対して
リベースします3.MyBranchをMyBranchLocalとマージします4.MyBranchLocalを
MyBranchに対してリベースします

シナリオIIIがコミット履歴を大幅に混乱させ、コミットを複製する可能性があることはすでに知っています。

あなたの経験は何ですか？マージの労力を最小限に抑え、履歴をクリーンに保つために、どのようなシナリオをお勧めしますか？

git-new-workdirを見てきましたが、ブランチにはrelease-mainの関係があるため、履歴を共有したくありません。つまり、リリースブランチの変更をメインラインに伝達したいのですが、メインラインの変更をリリースラインに反映させたくないのです。

私の一般的なパターンは、リリースラインのバグを修正し、それをメインラインに統合してから、両方のブランチで同時にビルドを開始することです。

git-new-workdirでこれを行う方法はありますか、クローンを作成する必要がありますか、それともより良い解決策がありますか？

ありがとう

私は次のことができるようになりたいです：

1. 他の（リモートまたはローカル）ブランチに基づいてローカルブランチを作成します（git branchまたはを介してgit checkout -b）

2. ローカルブランチをリモートリポジトリにプッシュします（公開）が、追跡可能にしてgit pullすぐgit pushに機能します。

それ、どうやったら出来るの？

--set-upstream私はGit1.7で知っていますが、それは作成後のアクションです。ブランチをリモートリポジトリにプッシュするときに、同様の変更を加える方法を見つけたいと思います。

n個のコミットがある場合、n-3コミットからどのように分岐できますか？

すべてのコミットのハッシュを見ることができます。

実際、マージの競合に関するレポートを取得しようとしています。誰がどの行を変更したかを「git Blame」で確認したのですが、ブランチやリポジトリ名の情報がわかりませんでした。

マージの競合が発生するたびに、そのファイル/行に触れた作成者に電子メールを送信できるように、「git Blame」またはコミット ID からファイルのリポジトリ名、ブランチ名、作成者名を見つける方法はありますか?それを解決するために。