こんにちは
記事では、gitを介してsvnを使用する方法と、純粋なgitを選択しなかった理由を説明します。
SVN
Subversionは、一元化されたバージョン管理システムです。 これは彼女のメインのマイナスと彼女のメインのプラスです:)
プラスは、一元化により、たとえば、コミットの番号付けが可能になることです。 それらの順序はわかっています。
また、競合を最小限に抑えます（ただし、これは議論の余地があります）。 リポジトリの現在の状態は1であり、誰もが知っています。
svnでは、1つのリポジトリに複数のプロジェクトを保存できます。 一般に、svnのリポジトリインターフェースはファイルシステムに非常に似ており、バージョン管理システムを使用したことがないユーザーに最小エントリのしきい値を提供します。
主なマイナス点はマージです... svnツールと頻繁にマージする人は、私が言っていることを理解しています。
遅い（meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee反応反応）））
どうやら-ソリューションは表面にあり、バージョン管理システムを変更するだけです。 私たちのケースでは、
単に gitに切り替える
ことはできません 。
これにはいくつかの理由があり、それらはすべて遺産によるものです。 今すぐ開発を開始した場合、おそらくgitを選択します。 私たちは約6年間リポジトリを持っていますが、この間に129のプロジェクトを作成し、リビジョンの数は88,000を超えました。
tracはバグトラッカーとして使用します。 今では1万枚以上のチケットがあります。 多くは、修正を確認するコミットへのリンクを持っています。 この豊かな遺産を失いたくありません。
また、svnにはプラスがあります-すべてのプロジェクトは同じリポジトリにあります。 Tracは、彼との作業を大幅に促進する1つのプロジェクトがあると考えています。
言い換えると、svnを放棄することはコストがかかりすぎますが、マージすることは...
解決策
svnをリポジトリ内に配置しますが、全員がgitを使用して作業します。 やりましょう！
- gitおよびgit-svnをインストールします。 インストール方法は、オペレーティングシステムによって異なります。 私の場合、単純な一連のコマンドになります。
apt-get update && apt-get install subversion git git-svn
- 使用する素敵な〜/ .gitconfigを作成します
[user] email = e.kokovikhin@co.wapstart.ru name = Evgeniy V. Kokovikhin [core] editor = vim [alias] co = checkout br = branch ci = commit st = status di = diff
- svnリポジトリのクローンを作成します。
cd /var/www/project.wapstart/ mkdir project && cd project
最後のチームには具体的な時間がかかります。 リポジトリで-4時間。
--stdlayoutは、プロジェクトレイアウトが標準であることを示しています。
project ├── trunk ├── branches │ ├── dovgFeature │ └── dovgAnotheFeature └── tags ├── 3.0.1 └── 3.0.2
実際にはすべて。
トランクは現在マスターと呼ばれ、他のすべてのブランチには通常どおり名前が付けられています。
ブランチでの作業：
git branch -r # git checkout -b dovgBranch dovgBranch # dovgBranch dovgBranch git branch # —
例：
dovg@marvin ~/job/oemdesign/www/plus1.wapstart.loc/plus1 $ git branch dovgUnique experimental * master moderation production referals targetingCountry uniqueCookie uniqueSession ---------
そして今、それをどのように使用するのですか？
- SVNを使用する
git svn rebase # ( ) git svn fetch # git svn dcommit # svn git svn branch <branch-name> # :) git svn help branch git svn info # svn,
- マージ このために私たちはすべてこれを行いました。
git merge --log master # .
マスター（トランク）でマージする場合
git checkout master git merge --no-ff <branch-name>
Merzhiはすぐに合格します。 リモートリポジトリは必要ありません。 もはや彼らを恐れる人はいません。
- Gitの基本
git diff — git commit — «» git commit -a — , , git add — . svn. svn , git , git commit -a git reset
最後に、小さなFAQ：
- ブランチを作成して切り替えます：git svn branch ticket-666 && git svn fetch && git co -b ticket-666 ticket-666
- ブランチをマスターに転送：git co ticket-666 && git merge --log --no-ff master && git svn dcommit && git co master && git merge --log --no-ff ticket-666 && git svn dcommit
- ブランチをテストに渡します（ウィザードから更新してコミットします）：git co ticket-666 && git merge --log --no-ff master && git svn dcommit
リポジトリを定期的に更新：git svn fetch
結論の代わりに
長い間、この記事は
Wapstartの内部wikiに投稿されてい
ました 。 私にとっては、それがコミュニティに役立つと思われました。 結果はあなたの前にあります。 ;）