svnbookのブランチに関する記事を読んだ後は、ブランチが必要な理由、ブランチの操作方法、および使用する必要がある場合を既に理解しています。 原則として、この後、カットの下に書かれているものはほとんど必要ないでしょう。 しかし、読むのが面倒だった場合は、以下のテキストに興味があり、ドキュメントの記事を読んでください。 または、svnbookで読んだ内容を理解するのに役立つかもしれません。
これは何のためですか？
1日以上かかるタスクがあるとしましょう。 頻繁なコミットのポリシーは、1日に複数回コミットすることを示唆しています。 これにより、より頻繁に変更を取得し、競合を回避できます。 監査に多くの変更がなければ、競合の可能性は減少します。 また、不可抗力に対しても保証しますが、突然そのうなり声を上げます-1週間の仕事を失うことはありません。
ただし、タスクが長い場合があり、途中でコミットできない場合があります。メインコードに組み込まれている未完了のタスクは、他の開発者の作業を妨げる可能性があるためです。 しかし、数日間コミットしないことも間違っています。 次に、本番環境にコードをアップロードする必要がある場合があります。 未完成のタスクをメインブランチにコミットすると、実稼働になりますが、これはコーシャーではありません。 これにはブランチがあります。 彼らは私たちにとって都合の良いときにいつでもコミットすることができますが、他の人を邪魔しません。 また、ブランチを使用すると、複数のタスクを混合せずに並行して作業できます。
ブランチとは何ですか？
これは、svnディレクトリの単なるコピーです。 より正確には、変更のみを含むいわゆる「ライトコピー」。 同一のファイルはコピーされません。 ブランチには、メインブランチで作成されるまで共通の履歴があります。 一般的な場合、任意の数のブランチがあり、それぞれがブランチできます。 しかし、標準プロジェクトでは、3つの永続的なブランチを持つのが慣習です。
* trunk-開発のメインライン。 現時点で関連するコードは次のとおりです。小さなタスクとバグ修正はここで実行されます。
* ブランチ -開発者向けのブランチ。 他のブランチとのgsutoブランチ。 その中にブランチを作成します。
* tags-タグブランチ。 あらゆる種類のタグがここで作成され、プロジェクトの開発における重要なマイルストーン、つまり、そのバージョンは安定しており、それほどではありません。 常に何らかのバージョンに戻ることができるようにするために必要です。たとえば、「このがらくたが以前に機能してから停止した理由、stsuko」を確認するためです。
プログラマーは、
*プロジェクトが安定して存在するために必要なときにブランチを作成します 。 一般的な場合、タスクが数日（場合によっては1日）以上続くと感じ、この間ずっと1日に少なくとも数回は痛みなくコミットできない場合は、ブランチが必要です。
* ブランチを最新の状態に保ちます -つまり、マージチームに対するパニックの恐怖をできるだけ早く取り除き、コミット以上のマージを行う必要があります。 そうしないと、ブランチをトランクにマージする際の競合を回避できません。
* タスクの完了後にブランチを削除します 。 開発者ブランチは一時的なブランチなので、タスクが完了したら削除する必要があります。 最後の手段として、タスクに大きな間違いがないことを確認するために、彼らはさらに数日間生きることができます。 さらに、ブランチは誰にも必要ではなく、削除することができます。 とにかく、しばらくすると、開発のメインラインから離れすぎてしまい、マージによって関連性を戻すことができなくなります。
ブランチを操作する方法
新しいブランチの作成は非常に簡単です。 Talmudから次のように、これはcopyコマンドで行われます。 特定のプロジェクト-BUMP（Big Afigenny Mega Project）を開発しているとします。 この場合、次のコマンドを実行する必要があります。
svn copy svn://svnserver/var/bump/trunk svn://svnserver/var/bump/branches/my-branch -m="Creating a private branch of /bump/trunk"
新しいブランチに切り替えるには：
s
vn switch svn://svnserver/var/bump/branches/my-branch
vn switch svn://svnserver/var/bump/branches/my-branch
現在どのブランチにいるかを確認するには
svn info
新しいブランチに切り替えると、変更を加えてコミットすることができ、他の人は何にも気付かないでしょう。 ただし、switchコマンドはupdateコマンドに非常に似ていることを覚えておく必要があるため、あるブランチから別のブランチに切り替えると、同じファイルに編集があった場合に競合が発生する可能性があります。 このため、メインブランチからの変更をより頻繁にマージする必要があります。
ブランチ間で変更をコピーする
ブランチを最新の状態に保つには、メインブランチから定期的に変更をコピーする必要があります。 これは、ブランチをマージするとき、またはメインブランチに切り替えるときに競合を回避するために必要です。 したがって、少なくとも1日1回または2回、より頻繁に結婚する必要があります。 あなたはそれをルールにすることができます：各コミットの前に我慢する。 マージコマンドは、おそらく最も難しいsvnコマンドです。 そして問題は、svnは以前のマージ（バージョン1.5まで）を記憶していないということです。 そして、彼が覚えていない場合は、前回のマージ後に既に持っている変更を自分でコピーするリスクがあります。 しかし、この欠陥は簡単に回避できます。 作業コピーに対する変更の各コピーの後に、それらをブランチにコミットする必要があります。 解説で、現在のマージに含まれるリビジョンの範囲を示します。 たとえば、「トランクr1234からマージ：1256」のようになります。 このコメントはあなたへのリマインダーとして機能し、最後に一緒になったのはいつか、最後のリビジョンはいつでも見ることができます。 そのようなコメントを含める必要があります。そうしないと、大きな問題と誤解が生じます。 その他。 すべてがうまくいくことを確認するために、まず、実際のコピーの前にテストを行うことができます。 これを行うには、--dry-runパラメーターを使用します。これは、作業コピーに変更を加えずに出力のみを表示します。
したがって、次のコマンドでトランクからの変更を確認できます。
svn merge -r4106:HEAD svn://svnserver/var/bump/trunk ./ --dry-run
たとえば、次の結論が得られます。
--- Merging r4107 into '.':
U db/queries.txt
U ejb/src/main/java/ru/bump/action/folder/MoveFolderActionLocal.java
U ejb/src/main/java/ru/bump/action/user/UserRegistrationAction.java
これは、r4107リビジョンでは、3つのファイルが変更されたことを意味します。 はい、変更をコピーします。
svn merge -r4106:HEAD svn://svnserver/var/bump/trunk ./
そしてコミット：
svn ci -m "merged from trunk r4106:4108"
番号4108は、現在のリビジョンの番号です。 入手は簡単です。 svn upコマンドを実行するだけです。
この場合、番号4106はブランチの作成の改訂版であることに注意してください。 あなたが最初に怒るとき、あなたはこのリビジョンの番号を見つける必要があります。 簡単です、コマンドを実行するだけです
svn log --stop-on-copy
さらに、この番号は不要になります。 自分のコメントから必要なリビジョンの番号を見つけることができます。 したがって、次回マージするときは、最後のマージのリビジョン番号を見つける必要があります。 たとえば、Linuxでは次のようにします。
#:~/www/bump$ svn log | grep merged
merged from trunk r4106:4108
したがって、再びトランクを取得するには、コマンドを実行する必要があります
svn merge -r4109:HEAD svn://svnserver/var/bump/trunk ./
タスクを完了する
タスクが完了したら、する必要があります
*変更をトランクにマージします
*干渉しないブランチを削除します
同じマージコマンドでトランクにマージします。 これを行うには、ブランチの作成のリビジョンを確認し、トランクに切り替えます。
svn switch svn://svnserver/var/bump/trunk
その後、ブランチから変更をコピーします
#svn up
At revision 4155
#svn merge svn://svnserver/var/bump/trunk@4155 svn://svnserver/var/bump/branches/my-branch@4155
すべてがうまくいった場合、競合はなく、何もする必要はありません。変更をメインブランチにコミットし、ブランチを削除できます。 トランクとまったく違いはありません。必要であれば、いつでも別のブランチを作成できます。 もちろん、ブランチは物理的に削除されるのではなく、単にHEADから削除されることを覚えておく価値がありますが、初期の改訂版では、いつでも見つけることができ、必要に応じて復元できます。 とても大胆：
svn delete svn://svnserver/var/bump/branches/my-btanch -m "Removing my-branch branch."
ちなみに、タスクをトランクにマージした後にブランチを削除することは厳密には必要ありません。 タスクの完了時にブランチを削除することは必須であり、トランクにマージしても、タスクが完全に完了するわけではありません。 理論的には、タスクの作業中に変更を（完全および部分的の両方で）数回マージできます。たとえば、タスクがステージに分割され、各ステージが完全で実行可能である場合などです。 または、たとえば、あなたが行った変更は他の開発者によって必要とされます（または有用かもしれません）が、同時にアプリケーション全体（新しいライブラリ、または既存のライブラリとクラスのインターフェースへの追加）の操作を妨げません。 一般に、トランクに対する変更の最小値に関する決定は、ブランチの所有者であるプログラマー（またはグループ）が行う必要があります。 もちろん、これは疑わしい場合に誰かと相談するオプションを除外しません。
原則として、これがプロジェクトを妨害しない限り、トランクと他のブランチとの間に大きな不一致を許さないようにすることをお勧めします。
おわりに
この記事には、ブランチの操作に関する情報のほんの一部しか含まれていません。 これはリマインダーとして機能しますが、チュートリアルとしては機能しません。 したがって、適切なsvnbookセクションを読むことを強くお勧めします。 これには、この説明に当てはまらない多くの情報が含まれていますが、ブランチの操作方法を理解するために必要です。