問題タブ [git-flow]

これは壊れています

最終的に（2つの「タブ」の後）機能しますが、「タブ」を押すたびにエラーがスローされます。

何か案は？

1. git-flowをサポートするGit用のGUIフロントエンドはありますか？

私たちのチームは、WindowsとLinuxでEclipseIDEを使用しています。徐々にgit-svnに感染させ、（git-svn-rebase / dcommitではなく）実際の分岐の力を活用するための次のステップを探しています。Git-flowは多かれ少なかれ私たちが今必要としているもののようです。しかし、私たちの中にはまだGUIに依存している人もいます。それにより、すべての販売と立ち上げが容易になります。

したがって、理想的には、Eclipseから簡単にアクセスできる方法を探しています。まだサポートされていないようです—外部ツールとして追加することを検討しています。Eclipseの内外でアイデアを歓迎します。

2. 上記の答えが「いいえ」の場合、それはGUI中毒者にとって問題になる可能性がありますか？

git-flowツールは実際には非常に薄いことを理解しています。GUIの有無にかかわらず、手動で「raw」コマンドを実行することで、実際にスキップするのは簡単です（たとえば、gitでブランチを操作すると便利です）。

一方では、手作業を最小限に抑え、エラーの余地を減らしたいと思います（ここでもチームの経験を考慮します）。OTOH、私の推測では、開発/リリース/ホットフィックスブランチ（後で機能ブランチを導入）のみを使用し始めることができ、この設定では、人々は通常どおりにプル/プッシュする必要があります。彼らはgit-flowの多くを見ることができませんでした-それは単にリリースやものをセットアップする人たち（主に私:)のヘルパーとして機能するでしょう。これは意味がありますか？

注：実際には、git-svn / trunkはまだ存在しています。これは、git以外のユーザーの場合もあります。これを「開発」と同期させることを計画しています（明らかにスカッシュマージによるマージ履歴を無視します）。これがスムーズに進むことを願っています—有名な最後の言葉ですか？

私たちのプロジェクトはsvn から gitに変換されました。開発者は現在 を使用してgit-svnいますが、ボンネットの下でさらに多くの機能を利用したいと考えています。ウィッシュリスト:

• トピック/機能ブランチなどの強力なブランチ
• リリースのメインラインとステージング作業の間の分離、時には複数の並行作業。
• 無駄のない平均的で安定した Jenkins-CI セットアップ - 最小限のメンテナンス (各リリース後にジョブ構成を変更する場合と比べて)
• 短いイテレーション。開発チームは 2 週間ごとに QA にリリースします。必ずしも外ではない
• 同じソースから構築され、個別にリリースされた複数の製品 (P1..P3)。さまざまな圧力で
• 「より大きなチーム」には、よりカジュアルな非 git ユーザーがいます...彼らはS&Uです :).. しかし、少なくとも 1 つのブランチ (トランク) への svn アクセスを彼らに与える必要があります。彼らの貢献はいくつかのディレクトリに制限されているため、ここでは衝突のリスクはあまりありません。

次の戦略は機能しますか?

1. 開発: 開発が行われるメインライン ブランチ、git-flow 風
2. 安定した製品ブランチ: product1 .. product3. これらの 1 つ以上は、開発リリース時にメイン ラインからマージされます。git flow の 'release start 1.4.3' に似ているようですが、これらは永続的なブランチになります。リリースはここでタグ付けされ、開発にマージされます。この時点で、git-flow の master のように、そのうちのいくつかだけが安定します。
3. git-svn を直接使用するのをやめてください - 代わりにミラーにプッシュ/プルしてください。必要に応じて機能ブランチを使用することもできます
4. svn/trunk をマージ -> 開発します。Svn は時折、孤立したチェックインを取得します。そのため、Jenkins ジョブによって自動化することを計画しており、失敗した場合は手動でマージできるように人々に通知します
5. merge development->svn/trunk: 定期的に (例: 毎日)、バッチ モードで。これはおそらく最も不安定な部分です（少なくとも初心者にとって）。リベースやリセットウィザードのようなものを計画しています
6. CI のセットアップは簡単です。たとえば、メインラインからのテストおよび開発ビルド、独自の製品ブランチからの公式製品ビルドなどです。

Git-Flowは魅力的です。主に、うまく記述され、自動化されているためです。しかし、私の場合には完全に一致するようには思えません。主に、並行リリースの可能性、複数の製品ライン、およびCI の側面が原因です。

情報に基づいたご意見をお待ちしております。

Ubuntuを実行している新しいデスクトップがあります。以前のコンピューターから新しいコンピューターに大量のgitリポジトリを同期しました。これらすべてで問題なく押したり引いたりできます。ただし、git clone新しいリポジトリ（gitoliteとgitflowを使用）でを実行すると、git pushハングします。rsyncedプロジェクトを正常にプッシュできたとしても、gitolitegit cloneからプロジェクトを実行することは成功しますが、プッシュできないプロジェクトになります。ファイルは.git/config同一です。

ぼくのコンピュータ：

Gitプッシュ出力（またはstrace出力を読み取る）：

そして、それはTotal 28 (delta...ラインの後に永遠にぶら下がっています。

同じプロジェクトから、ただしrsyncedディレクトリからのプッシュが成功すると、次のようになります。

私が考えることができる唯一の症状（赤いニシン？）はこれです：

それを機能させるには、-Tを追加する必要があります。

繰り返しますが、rsyncedThirdPart-Syncディレクトリにいる場合は正常にプッシュできます。失敗するのは、gitoliteサーバーからそのプロジェクトのクローンを再作成しようとした場合のみです。

更新：それは永遠にハングしないことが判明しました。しばらくすると、次のTotal 28行が表示されます。

Update Running straceは、何が起こっているのかを教えてくれません。レポではプッシュできません：

プッシュできるレポでstraceを実行すると、ほぼ同じ場所からこれが得られます。

gitflow を使用して、既存のリポジトリ (「Production」) から複製したベア git リポジトリ (「Core」) を作成しました。その裸のレポを再び非裸のレポ (「Staged」) にクローンし、Staged で git フローを再初期化しました (裸のリポジトリをクローンしたときに gitflow が見つからなかったように見えるためですか?)

しかし、私は奇妙なことに気づきました。ステージングされたレポの開発ブランチにいて、テキスト ファイル (test.txt) を編集しているとします。実行するgit statusと、test.txt が変更されたことがわかります。素晴らしい。

今、私はコミットもマージもしていませんgit checkout masterが、を使用して master をチェックアウトし、再度実行git statusすると、test.txt が変更されたと表示されます!

私が間違っている場合は訂正してください。ただし、開発ブランチで行った変更は、マスター ブランチにはまったく影響しないはずです。これにより、私の「マスター」ブランチと「開発」ブランチは実際には同じブランチであると信じるようになります。

明らかに、どこかで非常にばかげた間違いを犯しましたが、どこで？わかりません。これは以前に誰かに起こったことがありますか？ここで問題を診断するための指針はありますか? 私が思いつくようなばかげた間違いはありますか?? 救済策はありますか？

(実際には、develop ブランチと master ブランチが必要であることを指摘したいと思います)

更新 開発ブランチで変更をコミットした後、実際にはマスターが正しい状態に戻り、開発が更新された状態になりました。おそらくこれが git の振る舞いなのだろうか？

私は git flow ツールを使用していますが、少し問題が発生しました。私のgitブランチは分岐しています。master ブランチを読んだところ、'origin/master' が分岐しています。分岐を元に戻すには? ローカルリポジトリのマージとリベースの両方を試みて、手順に従おうとしました。

どうすればこの問題から抜け出すことができますか? 私は git flow 機能を使い果たしました。変更をリモートに反映させたいだけです。ありがとう！

私は2、3か月間git flowを使用していて、非常にうまく機能しています。「バンプバージョン」の操作を自動化したいのですが。

プロジェクトはPHPであり、footer.phpには現在のリリースタグに置き換えるトークンがあります。gitログとPHPファイルを少し調整すれば、すべてうまくいくはずですが、誰かが以前にこれを行ったことがあると思います...

何か案は？

クライアント固有の機能を管理し、 Git-flowまたはGit一般のリクエストを変更することをどのように推奨しますか？クライアント固有の機能は、クライアント専用の別のブランチに含める必要がありますか？（各クライアントは開発ブランチから独自のブランチを持っています。）または、それらは別々のリポジトリにあるべきですか？（各クライアントには専用のリポジトリがあり、マスターリポジトリがメインリポジトリです。）

最近gitflowを使い始めたばかりですが、よくわからないことがあります。まず、開発に関して直接何もしません。何かをする場合は、ホットフィックスまたは機能の開始を使用します。

新しい機能（「sequentialUpgrades」）を開始したとき、プラグインはバージョン1.1.5でした。それは4日前でした。過去4日間で、この新機能を完了していませんが、2つの修正プログラムを完了したので、それらをマスターにマージし、完了時に開発しました。もちろん、これらのブランチの両方で、修正プログラムを含む最新の変更があります。バージョン1.1.7で...私が実行した場合git diff master develop、違いはありません。

機能ブランチに戻ってこの新機能の開発を続けたところ、機能ブランチはまだ1.1.5に戻っているため、最新の2つの修正プログラムはありません。

だから私は2つの質問があります：

1. 何かを台無しにすることなく、最新の変更を機能ブランチに取り込む方法があるとしたらどうでしょうか。

開発を機能ブランチにマージすることを考えていましたが、それが正しい方法ではないと思います。しかし、私は本当に、この新機能の開発中にこれらの最後の2つの修正が存在する必要があることをスクラッチしたいと思います。

2. これができない場合、機能を終了したときに、競合することなく、どのように統合して開発に戻すことができますか？これに頭を包むことはできません。

この機能を1.1.5から始めたからです。機能ブランチで、ファイルaccess-level.phpに大幅な変更を加えました。修正プログラムを実行したときに、同じファイルの5〜6行を変更しました。いくつかの重要な変更が加えられた1.1.5に戻ったファイルを、それ以降も変更が加えられた1.1.7の同じファイルにマージするにはどうすればよいですか？

私はプロジェクトに参加しましたが、コードのテストとバージョン管理ソリューションが混乱しているので、それらの実装などを担当しています。

Git に比較的慣れていない私は、http://nvie.com/posts/a-successful-git-branching-model/をどのように実装すればよいのか疑問に思っていました。つまり、次のことを意味します。

• git flow initLAMP サーバー (すべてのテストとバージョン管理が行われる場所)を使用して git リポジトリをセットアップする必要がありますか?
• リモート リポジトリの特定の // ブランチに変更feature_xをプッシュするにはどうすればよいですか?hotfix_yreleas_z
• git flow initローカルのクローン リポジトリで同じ設定を行う必要がありますか?

私はgitの基本的な知識を持っているので、これについてご指導いただければ幸いです。

アップデート

バージョン管理システムを使用して、ローカルからライブおよび/またはテスト環境に同期できる方法について、より良い解決策を知っている場合は、お知らせください...私は喜んで学びます