問題タブ [branching-strategy]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
tfs - ALM 基本ブランチ計画 - リリース ブランチの目的は?
Microsoft ALM チームは、Basic Branch Plan にはMAIN、DEV、およびRELEASEブランチが必要であると説明しています。
現在、ブランチをまったく使用せずにソース管理を使用している新しいチームにブランチ/マージを導入する作業を行っています。
RELEASE ブランチが実際にどのように使用されているのか気になりました。
DEV ブランチで変更を行ってから、RELEASE ブランチを必要とせずに MAIN ブランチにマージできますか? MAIN は引き続き読み取り専用です。基本的には、本質的に RELEASE ブランチになります。私がこれを言う理由は、それほど多くの変更はありませんが、新しい変更から安定したコードを分離したいからです。いわゆる「リリース」の概念は、まだ明確に定義されていません。私はまだそれに取り組んでいます。
私のチームが RELEASE ブランチを必要としているかどうかはわかりません (特に私たちのニーズを考慮して)。
MAINブランチとDEVブランチだけを持つという戦略についてコメントをいただければ幸いです。
tfs - ソース アイテムの下での TFS 分岐または移動
次のような Team Foundation Server 2013 コード構造があります...
...しかし、リファクタリングしたい...
これにより、「トランク」と同じレベルで「リリース」ブランチを作成することで、分岐とマージの戦略を前進させることができます。
アプリケーション ディレクトリをトランクに分岐または移動しようとすると、次のエラー メッセージが表示されます。
ターゲット アイテム $/TeamProject/Application/Trunk をソース アイテム $/TeamProject/Application の下に置くことはできません。
だから、これが私が従ったプロセスです。それは間違っていると感じており、これを行うためのより効率的な方法があると推測しています.
$/TeamProject/Applicationに名前を変更$/TeamProject/Application-trunk- 新しい
$/TeamProject/Applicationディレクトリを作成する $/TeamProject/Application-trunkに移動$/TeamProject/Application/Trunk
$/TeamProject/Applicationこれを行った後、履歴はnotに関連付けられ$/TeamProject/Application/Trunkます。私の質問はこれです、もっと知っている人はこれをどのように行うでしょうか?
git - 多くの小さな変更を加えながら、チームの一員としてどのように git を操作しますか?
git/ソース コントロールを効果的に操作する方法について、アドバイスや意見を求めています。
私は 5 人の開発者のチームの一員として働いています。私たちの最大のクライアントの1つは、Wordpressで構築された巨大なサイトを持っており、多くのことが進行中です。
リポジトリには Bitbucket を使用し、すべてのコミットとチェックインを処理するには SourceTree を使用します。
同時にサインオフされない非常に小規模なジョブがよくあります。例えば：
- 仕事一。プロジェクト マネージャー 1 は、ページ X のサイドバーを更新する必要があります
- ジョブ 2。プロジェクト マネージャー 2 は、ページ Y のボタンを赤に変更したいと考えています。
多くの場合、これらのジョブは異なる開発者によって行われますが、同じファイルを使用します。準備ができたらコミットをdemoブランチにプッシュし、サインオフを待ちます。場合によっては、プロジェクト マネージャーがジョブ 1を数週間承認しないことがあります。ただし、その間にジョブ 2を稼働させる必要があります。
私たちが常に抱えている問題は、demoブランチ (および対応するサイト) にジョブ 1とジョブ 2demoの両方の作業があるため、ブランチをブランチ (およびライブ サイト)にマージできないことです。demolive
皆さんはこれをどのように管理していますか？一緒に働いている複数の仕事を整理する最善の方法は何ですか? 私たちは小規模な仕事、大規模な仕事、中程度の仕事をすべて同じサイトで同時に行っており、サインオフされていないために準備demoができていないものを押し上げることに常に失敗しています。liveブランチをまとめてマージし、そこにあるはずのないものを追加します。
これがどのように可能かについてのアドバイスがあれば教えてください！
これは私たちのサーバーワークフローです:
ローカル マシン > 開発 > ライブ
git - Git チームでの開発経験が必要
ここでそのような質問をしてよいかわかりませんが、試してみます。私はソフトウェア開発チームで働いており、GIT開発プロセスを管理するために使用しています。プロジェクトが配置されている独自の gitlab があります。また、各開発者は、ローカル マシン上に独自のプロジェクトのクローンを持っています。ファイルに直接アクセスすることはできません。変更をプッシュする必要がある場合は、管理者に master ブランチをリリース バージョンにプッシュするように依頼します (説明が正しければ)。Skype チャットを使用して、管理者に変更のプッシュについて尋ねます。管理者が応答するまでに長い時間がかかる場合があり、重要な変更が更新されずに長い間残ります。
私の質問は、このプロセスをよりスマートに (またはより信頼できるように) するにはどうすればよいかということです。つまり、通常は世界の企業になります。ありがとう
tfs - 開発分離ブランチ戦略: 分岐の起源?
2 つのブランチがあります。開発(開発者が定期的にチェック/統合する) とメイン(開発からのコードがバージョニング/リリースのためにマージされる場所)。
分岐の「戦略」/「ベスト プラクティス」について読むと、DevelopmentはMainの分岐で なければならないと言われています。 開発はMainから分岐する必要があります。
たとえば、VS ALM Ranger のBranching Strategies ドキュメントで Development Isolation について読むと、 「開発ブランチはメイン ブランチの完全な子ブランチにする必要がある」と書かれています。
MainをDevelopmentからの完全なブランチにできないのはなぜですか? 私の理解では、ほとんどの場合、開発にはメインにあるすべてのもの (ホットフィックスを除く) が含まれます。
DevelopmentからMainへのマージは、より一般的なシナリオです。この場合、どちらが「オリジナル」でどちらがブランチであるかは重要ですか?
注: Visual Studio Team Services を使用しています
git - 複数バージョンの Git 戦略
別のソフトウェアのプラグインを開発しています。これまで、このソフトウェアはバージョン 2.xy であり、私の戦略は次のとおりでした。現在作業中の開発ブランチがあり、機能が完成するまで機能ブランチのブランチに使用します。そして、私はリリースブランチを持っていますソフトウェアの各 x バージョン。ときどき、開発ブランチの作業を単一のリリース ブランチにマージしてリリースを行います。それは結構です。また、ソフトウェアは、これらのリリース ブランチの最後のコミットからコードを取得して、プラグインとして利用できるようにします。現在、そのソフトウェアのバージョン 3.0 があります。もちろん、いくつかの大きな変更が含まれています。私はすでにそのバージョンの新しいリリース ブランチを持っていますが、develop ブランチをどうすればよいかわかりません。バージョン3に合わせてもよろしいでしょうか？バージョン 2 からリリース ブランチへの新機能、機能強化、またはバグ修正を問題なく引き継ぐことはできますか? 理論的には、これが進むべき道だと思いますが、そのバージョン変更のために行ったコミットをマージしないようにする必要があります。それは複雑ですか？クリーンで素敵なブランチ構造を維持する方法はありますか?