問題タブ [git-workflow]

リリース、開発、機能、およびバグ修正ブランチで動作する git ワークフロー モデルに関する次の優れたブログ投稿に出くわしました: http://nvie.com/posts/a-successful-git-branching-model/

これは素晴らしいワークフローのように思えます。実際に本番環境で試してみたいと思っていますが、ある段落が私の注意を引き、不思議に思っています。

次のリリースにバージョン番号が割り当てられるのは、リリース ブランチの開始時であり、それ以前ではありません。それまでは開発ブランチに「次のリリース」の変更が反映されていましたが、その「次のリリース」が最終的に 0.3 になるか 1.0 になるかは、リリース ブランチが開始されるまで不明です。その決定は、リリース ブランチの開始時に行われ、バージョン番号バンピングに関するプロジェクトのルールによって実行されます。

この作業方法は、チケット発行およびバグ追跡システムにどのように反映されるのでしょうか? JIRA と BugZilla では、チケットが所属できる「バージョン」を作成します。リリース ブランチに切り替える前に、開発ブランチにある場合、チケットはどのバージョンに属しますか? すべてのブランチのイシュートラッカーにバージョンがありますか?

また、今後のリリースではなく、その後のリリースで実装することがわかっている機能チケットについてはどうでしょうか? この種のチケットの「今後」と「将来」のバージョンを作成する必要がありますか?

この分岐ワークフローがチケット/問題管理にどのように反映されるかについての洞察をいただければ幸いです。

Gitは分散型システムであると想定されていますが、Googleで見つけたすべてのチュートリアルとベストプラクティスワークフローでは、サーバー（通常はGitHub、または独自にセットアップ）を使用することをお勧めします。

私は小規模な個人プロジェクト（2〜3人）にgitを使用しています。ここで、チームメンバーのマシン間で変更を直接同期するためのベストプラクティスワークフローを見つけることができます。

あるいは、なぜこれを避けて代わりに「中央」サーバーをセットアップする必要があるのか​​についての説得力のある議論は何ですか？

私は自分の高官にgitを売ろうとしているところです。とにかく、彼らは私たちがそれについて話すのを聞いています。よくわからないことが1つあります。人々がこれにどのように対処しているかを確認したいと思います。基本的に、私の質問は、ブランチのペアが離れるほど、それらをマージするのが難しくなるという基本的な理解から来ています。

この非常に単純なワークフローを提案することを検討しています。マスター（リリース）ブランチ、開発ブランチ、およびその中のトピックブランチがあるとします。さまざまな開発者が別々のトピックブランチに取り組んでおり、コードが機能していると感じる頻度で、それらのトピックブランチを中央リポジトリにプルおよびプッシュします。定期的に、開発者からそうするように求められた場合、メンテナ（私たちの組織では「テクニカルリード」というタイトルを持っています）は、機能ブランチから開発ブランチにマージされ、ステージングサーバーに配置されてテストされます。テストが完了し、マスターとマージされて本番環境にプッシュされます。

これが私の質問です。開発者はトピックブランチを定期的にマージする必要がありますか？そうすることで、それらがすべてdevにかなりきれいにマージされます（または、少なくとも、手に負えなくなる前に競合を早期にキャッチします）。私のマネージャーがそれについて嫌いになることを私が知っている唯一のことは、それはプロジェクトにコードを提供するために働くのではなく、彼らが彼らのツールをなだめるために彼らがしなければならない仕事です。考え？

私はLaTeXで非常に長い文書を書いています。私は仕事用のコンピューターとラップトップを持っており、両方で作業しています。2台のコンピューター間ですべてのファイルの同期を維持する必要があります。また、リビジョン履歴も保持したいと思います。DVCSとしてgitを選択し、サーバーでリポジトリをホストしています。また、Kile+Okularを使用して編集しています。Kileには統合されたgitプラグインがありません。また、このテキストについては誰とも協力していません。何らかの理由でサーバーにアクセスできない場合は、別のプライベートリポジトリをcodasetに配置することも考えています。

この場合に推奨されるワークフローの方法は何ですか？この作業スキームに分岐をどのように適合させることができますか？同じファイルの2つのバージョンを比較する方法はありますか？隠し場所を使用するのはどうですか？

ソース コードなどのすべてのプロジェクト ファイルをリポジトリの一部にしたい。簡単にするために、すべての作業は開発ブランチで行われます。さらに、pdf ファイルなどの追加のプロジェクト資料を含めたいと考えています。それらを開発ブランチに追加したくありません。これまで、以下の戦略を思いつきました。

• 戦略 1 は、別のブランチマテリアルを作成し、pdf を追加することです。ブランチは、親ブランチと一部の履歴を共有しています。
• 戦略 2 は最初の戦略を適応させますが、マテリアルブランチのコミットを時々開発ブランチにマージします。（これはいらないです、ピタです。）
• 戦略 3 は、たとえば、ソース コードの履歴を共有しない孤立したブランチを作成することです。
• 戦略 4 は、戦略 1 または 3 に従い、さらに「メイン」リポジトリのマテリアルブランチのみを表すサブモジュールを作成することです。これが可能な場合、作業ディレクトリには開発ブランチとマテリアルブランチが同時に表示されます。

すべての戦略の欠点は、別のブランチをチェックアウトしたときに、作業ディレクトリ内のファイルにアクセスできないことです。開発ブランチで作業しながら、作業ディレクトリで資料を
利用できるように するにはどうすればよいですか? 想像しやすいのであれば、資料はドキュメンテーションでもあります。

編集: Seth Robertsonの回答を読んだ後、戦略 4. を追加しました。

現在のプロジェクトでは、オープンソースフォーラム（https://github.com/vanillaforums/Garden）を使用しています。私はこのようなことをすることを計画していました：

このようにして、バニラフォルダーに変更を加え（構成の変更など）、マスターブランチにコミットできます。また、バニラブランチに切り替えて、更新をフェッチすることもできます。私の問題は、ブランチをマージしようとしたときです

問題は、「更新コミット」が私のコミットの上にあり、私の変更を「上書き」することです。アップデートの上にコミットを再生してもらいたいです。それを行う簡単な方法はありますか？私はgitがあまり得意ではないので、これは間違ったアプローチかもしれません。また、自分の歴史とバニラの歴史を混ぜたくありません。

私のクライアントは現在、コードの変更をチェックインするために StarTeam を使用することを要求しています。StarTeam からすべてのコードを取得し、ローカルの Git リポジトリをセットアップして、分岐を利用して一部の JQuery モジュールのアップグレードに取り組みたいと考えています。ローカルの Git リポジトリを使用して StarTeam サーバーに変更をチェックインする方法について、何か提案やアドバイスはありますか?

これは私にとって繰り返しの質問ですが、繰り返したいと思います。

私の状況を簡単に説明してください。私は、git サーバーも、共有パーティションも、コーダー間の共通点もない環境にいます。持たない、持たない、持てない。限目。

私はワークフロー ソリューションを考え出そうとしています。私たちが管理しているその環境でも、担当者が合理的な同期を維持できるようにしています。

私が現在試しているソリューションは、ディスカッション グループを使用してパッチを配布し、2 つのメイン ブランチと一見短いワークフローを使用しています。

• 枝はmarster、yours
• masterは同期ブランチであり、最新の状態に保ち、他の開発者がまだあなたのコードを持っていないものを追跡します。
• yoursが新しいマスターになり、最終的なコードがあるべき場所になります。あなたは で働いていませんmaster。
• 全員がディスカッション リストにパッチを送ります。
• 2 人が同じファイルで作業することはめったにないと考えています。

ワークフローには、次の 2 つの主要なアクションがあります。

パッチを生成します。

1. に行きましたyours
2. master( git format-patch master)からパッチを生成
3. に行くmaster
4. yoursにマージmaster
5. >yoursに進み、作業を続けますyours

パッチを適用します。

1. master支店に行く
2. 受信したパッチを適用する
3. yours支店に行く
4. masterにマージyours
5. >作業を続行yours

masterうまくいけば、ブランチは他のすべての人と合理的に同期するはずです。

ブランチは、yours他の人が持っているものと持っていないものを追跡するためだけのものではありません。

面倒すぎるかどうかを把握しようとしている問題がいくつかあります。

• パッチの適用順序
• 誰かがパッチを逃したことを回避し、検出する方法は?
• 誰かがパッチを見逃した場合、どの程度の問題になる可能性がありますか?
• これが私が考えもしなかった他の問題を引き起こす可能性がありますか?

ありがとう！

私はまだ git で自分の道を見つけようとしているので、しばらくお待ちください。あらゆる場所で分岐と分岐を行うという全体的な慣行により、何が起こっているのか理解するのが少し難しくなります。

ワークフローを進めようとしていますが、ハードルに直面しています。これまでのところ、これは私が持っているものです:

1.フォークプロジェクト

2.フォークをローカルで複製する

3.アップストリームのリモートを追加して、フォークを最新の状態に保つことができるようにします

4クローンのブランチでの作業:

5元の (上流の) プロジェクトのブランチから更新します。

6変更をフォークにコミットしてプッシュする

元のプロジェクトへのフォークの変更を取得するにはどうすればよいですか? プル リクエストがあると言われましたが、それを実現するために実行するコマンドが見つかりません。Google は役に立ちませんでした。

アップストリームからブランチをチェックアウトし、フォークをマージしてプッシュする必要がありますか?

元のプロジェクトを別のディレクトリに複製し、フォークをアップストリームとして追加し、マージしてプッシュする必要がありますか?

次のようなファイル パスを使用して、サーバーに 2 つの裸の git リポジトリをセットアップしました。

/git/project.git/
/git/project2.git/

次に、dev と live の 2 つのブランチを追加しました。次に、各プロジェクトに次の受信後フックを追加しました

これは 1 つのプロジェクトでは機能しますが、他のプロジェクトでは機能しません。2番目のプロジェクトでは、プッシュした最初のファイルでのみ動作するようです.gitignoreファイルです。

つまり、このファイルは、プッシュ時に更新される唯一のファイルです。