バージョン管理システムであるVCS （この場合はSubversion）にブランチを作成するメカニズムが助けになります。 ブランチは、1つのドキュメントまたはプロジェクトの異なるバージョンであり、ブランチポイントへの共通の変更履歴とその後の異なる履歴があります。
作成
ブランチは非常に簡単に作成されます：
svn copy svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ -m ' '
これで、開発者への変更がメインの開発トランク（トランク）ではなく、選択されたブランチに保存されるように、彼はこのブランチに切り替える必要があります。
cd ~/web// # svn sw svn://svnserver.ru///branches/_ svn update # , svn:externals
これで、未承認または未検証のソリューションが実稼働に入ることを心配することなく、ブランチで開発を行うことができます。 同時に、開発者はホストLOGIN_RAZrabrabotchika。PROJECT。CLIENT。Devserver.ruで作業します
既製または中間のソリューションを表示するために、このブランチのテストホストが作成されます。 開発者がこれに時間を費やさないように、このプロセスを自動化する必要があります。 マネージャーとテスターは、常にテストホストNAME_VETKI.PROEKT.KLIENT.devserver.ruでのみソリューションをチェックします。 開発者のホストでは何も確認できません。 なぜなら：
- 開発者は、何かをコミットすることを忘れるよう努めています。 このため、同じタスクを使用したり、ソリューションを展開したりする別の開発者は、すべてがどこにあるかを長い間理解していない可能性があります。
- 開発者はコード内のホストにバインディングを残す場合があります。 このため、ソリューションは彼らのためだけに機能し、展開するとすべてが壊れます。
- 多くの、特に経験豊富な開発者は、ある種の修正を「盲目的に」コミットすることをチェックせずに行うのは初めてです。 これにより、実稼働環境でのサービスが低下し、一連の修正プログラムが「Oh shit」というコメントとともにコミットされます
したがって、唯一の良い方法は次のとおりです。
- タスクを完了する
- 変更をコミットする
- それらをテストサーバーにロールします
- 少なくとも一度は自分の目で、すべてが正しく展開されていることを確認してください
- タスクのテストホスト上の問題の場所へのリンクを公開します（メガプランまたは別のタスクトラッカー内）
このリンクがタスクで複数回見つかった場合でも、後者を実行する必要があります。 急ぎまたは不注意のため、説明した5つのアクションのうち4つがスキップされる場合があります。
合併
マネージャーがソリューションをチェックし、エラーが見つからなかったら、ブランチをトランクに挿入する必要があります。
主な開発が進行中のブランチA（トランク）があるとします。 リビジョン100では、ブランチBからブランチ（ブランチ/ TITLE_NAME）（A @ 100、B @ 101）に分岐します。その後、両方のブランチが長時間アクティブに開発され（A @ 167、B @ 189）、それらをマージする必要があります。 「額に」マージする場合（sw A、マージAB）、解決するのが非常に困難な多くの競合があります。
svn switch svn://svnserver.ru///branches/_ # B svn merge -r 101:167 svn://svnserver.ru///trunk . # A ( ** **) svn ci -m 'merge with -r 101:167 trunk' # ( , ) . svn switch svn://svnserver.ru///trunk # A svn merge svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ . # B svn ci -m 'merge with _@190' # , .. A
私はあなたの注意を引きます：ブランチが過去に既にマージされている場合、最初のリビジョンとして新進リビジョンではなく、ブランチが「同じ」であった最後のリビジョンとして取る必要があります。 さらに、これは必ずしもAからBへの変更の注入ではなく、BのAへの注入もあります。
場合によっては、同じコードセクションが異なるブランチで変更された場合、原則として競合が依然として発生します。 それらを解決するための指示があります。 すべての競合で必ずしもあなたの決定が正しいとは限らないことを忘れてはなりません。したがって、マージは両方のマージされたブランチの変更に精通しており、競合を適切に解決できる人が行うことをお勧めします。
統合後、トランクのテストホスト（trunk.PROEKT。CLIENT.devserver.ru）を作成するか、既存のフォルダーを更新する必要があります。 その後、タスクのテストホスト上の問題の場所へのリンクをタスクにスローします。 ブランチホストで変更を確認しただけなので、なぜこれを行うのでしょうか。 トランクに加えられた変更またはトランクに注がれた他の変更は、必要な編集に影響を与える可能性があります。 ほとんどの場合、問題はCSSによって引き起こされます。 単に一般的な規則によって多くのセクションに影響を与えますが、他の状況もあります。 したがって、展開する前にトランクをもう一度確認する必要があります。
不注意なマネージャー
マネージャーはプロジェクトについて気にせず、何よりも自分の心の安らぎを心配することがあります。 したがって、軽い魂で、彼は彼にとって重要ではないと思われるステップをスキップし、タスクに「これを実行してすぐに展開する」と書いています。
そのため、近い将来、彼はクライアントからスティックを受け取ります。「ウェブ上のほとんどの加入者は、IEブラウザーを使用できません。 前回、ユーザーの半数以上がそれを使用していると述べましたので、主にIEですべての改善をテストしてください。 このエラーをできるだけ早く修正してください！」
マネージャーはタスクを「緊急！ エラー!!!」そして次回までチェックを忘れます。
「完了→チェック済み→（修正済み→チェック済み）* n→ロールアウト」アルゴリズムに違反すると、緊急のタスク編集が出現し、開発者のリズムが崩れ、計画されたタスクから気が散り、顧客やユーザーに対する全体的な評判が損なわれ、プロセスがスピードアップしません。