一部の現代のプログラマーには、Git以外のバージョン管理システムはありませんが、実際には、Subversionは依然として需要があり、Mercurialには熱心なサポーターがいます。 援軍のクイック検索 。
その結果、非モノプロジェクト企業のDevOpsは、非常に異なるシステムで作業を自動化する必要に直面しています。 同時に、それぞれに独自のニュアンスがあり、必然的に、最も不適切な瞬間に撮影するシナリオに隠れたエラーがあります。 たくさんの可能性ではなく、最小限の「柔軟性」を備えた予測可能な動作が必要です。
インターフェース
FutoIn CIDを紹介する記事では、さまざまなVCSの暗黙的な作業について既に説明しています。 バージョンv0.7では、明示的なコマンドインターフェイスと、ブランチの作成とマージを自動化するための新しい機能が追加されました。
一般的に、以下のコメントを含むインターフェース自体：
cid vcs checkout [<vcs_ref>] [--vcsRepo=<vcs_repo>] [--wcDir=<wc_dir>] cid vcs commit <commit_msg> [<commit_files>...] [--wcDir=<wc_dir>] cid vcs merge <vcs_ref> [--no-cleanup] [--wcDir=<wc_dir>] cid vcs branch <vcs_ref> [--wcDir=<wc_dir>] cid vcs delete <vcs_ref> [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs export <vcs_ref> <dst_dir> [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs tags [<tag_pattern>] [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs branches [<branch_pattern>] [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs reset [--wcDir=<wc_dir>] cid vcs ismerged <vcs_ref> [--wcDir=<wc_dir>]
分散型バージョン管理システムのイデオロギー的優位性に関するスローガンから離れると、裕福なプロジェクトの開発における最終結果は、クライアント側に追加のプラスを加えた同じクライアント/サーバーモデルになります。 2番目の明らかな点は、分散システムでのクライアントサーバーモデルの問題のない「エミュレーション」と、反対の実装の難しさです。 これが作業ロジックの理由です-サーバーとの強制的な暗黙的な同期。
これは一致するテーブルを意味します：
| シド | Git | マーキュリアル | 転覆 |
|---|
cid vcs checkout | git clone/fetch + git checkout | hg pull + hg checkout | svn checkout/switch |
cid vcs commit | git commit + git push | hg commit + hg push | svn commit |
cid vcs merge | git merge + git push | hg merge + hg push | svn merge + svn commit |
cid vcs branch | git checkout -b + git push | hg branch + hg push | svn copy |
cid vcs delete | git branch -D + git push -f --delete | hg checkout + hg commit --close-branch + hg push | svn remove |
cid vcs export | git fetch/clone --mirror --depth=1 + git archive | tar git archive | tar | hg archive --type files + .hg*クリーンアップ | svn export |
cid vcs tags | git ls-remote | hg tags | svn ls {repo}/tags |
cid vcs branches | git ls-remote | hg branches | svn ls {repo}/branches |
cid vcs reset | git merge --abort + git reset --hard | hg update --clean + hg purge -I **/*.orig hg update --clean | svn revert -R . |
cid vcs ismerged | git branch -r --merged HEAD | hg merge --preview | svn mergeinfo --show-revs eligible |
それはすべての簡潔さで非常に明確なようです。 以下にのみ注意してください：
- SVNは、明示的な改訂指示なしのマージに依存しています-「何をしているのかを知る」。
- Hgにはブランチの削除はなく、ブックマークは松葉杖に似ています。
- もちろん、これらの3つのシステム上で光が一緒になったとしても、プラグインメカニズムを介して他のサポートを追加する機会があります。
いくつかの例
面倒なことのないすべての例：小さなコメント、一連のコマンドそのまま、そして視覚的な結果。
>準備作業
繰り返しますが、純粋なDebian Jessieを使用します。 Gitリポジトリを作成し、README.txtファイルとLICENSEファイルを追加して、2番目の開発ブランチを作成しましょう。
sudo apt-get install -y python-pip sudo pip install futoin-cid VCS_REPO_DIR=${HOME}/repo VCS_REPO=git:${VCS_REPO_DIR} function prep_cache_dir() { local repo=$1 local cache_dir=$(echo $repo | sed -e 's,[/:@],_,g') [ -d $cache_dir ] && cid vcs reset --wcDir=$cache_dir 1>&2 echo $cache_dir }
>ジョブストーリーNo. 1：新しい機能で作業を開始するとき、名前を合理化するために自動ブランチ作成が必要
注：開発者は自分でブランチを作成できないか、これは歓迎されず、トリガーはトラッカーで機能することが理解されています。
function on_feature_start() { local repo="$1" local feature="$2" local cache_dir=$(prep_cache_dir $repo) cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir cid vcs branch feature-${feature} --wcDir=$cache_dir } function list_branches() {
>ジョブストーリーNo. 2：毎晩（コミットごと）、開発（リリース）ブランチを機能（開発）ブランチにマージして、矛盾を避け、プロセスが尊重されるようにする必要があります。
注：このワークフローは、イデオロギー的に正しい（および安全な）と見なされますが、リベースはより不毛で理解しやすいストーリーになります。
ブランチの準備：
cid vcs checkout develop --wcDir=wc echo 'Info 2' > wc/README.txt cid vcs commit 'Commit 2' --wcDir=wc cid vcs checkout feature-234_two --wcDir=wc echo 'Info 3' > wc/README.txt cid vcs commit 'Conflict 3' --wcDir=wc
function sync_branches() { local repo="$1" local cache_dir=$(prep_cache_dir $repo) local logfile=$(realpath $2) cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir pushd $cache_dir
予想されるエラー-競合を明確に作成しましたが、タイプミスがあります-いいえ。 次のリリースで修正される予定です。
> Job Story No. 3：リリース後、含まれているすべての機能ブランチを削除して、ネームスペースを詰まらせない
注：HgとSVNの場合、まったく心配する必要はありませんが、Gitの場合、コミットを失うリスクがあります。したがって、ストーリーの読み取り専用ミラーを持つことをお勧めします。
function remove_merged() { local repo="$1" local cache_dir=$(prep_cache_dir $repo) local logfile=$(realpath $2) cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir pushd $cache_dir echo >$logfile
>ジョブストーリーNo. 4：一定の頻度で、ファイルを生成し、VCSに送信して完全な変更履歴を取得する
例：a）商用ブログまたはニュースサイトにファイルをダウンロードすると、Subversionの整合性と効率を高めるために特定の価値がありますSubversionは非常に適切になりますb） アクティブな攻撃のアドレスの絶えず更新されるブラックリストの例、FutoIn CIDの参加なし
function update_file() { local repo="$1" local cache_dir=$(prep_cache_dir $repo) cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir pushd $cache_dir date > Timestamp.txt cid vcs commit 'Updated timestamp' Timestamp.txt popd } update_file "${VCS_REPO}"
>ジョブストーリーNo. 5：毎晩、常に最新バージョンを使用するために、すべてのプロジェクトの依存関係を更新する必要があります
注：プロジェクトリストの自動処理には、他にも多数のバリエーションがある場合があります。
function update_project_deps() { local repo="$1" local cache_dir=$(prep_cache_dir $repo) cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir pushd $cache_dir date > Timestamp.txt for t in $(cid tool detect); do case $t in npm*|composer*|bundler*) cid tool exec $t -- update ;; esac done cid vcs commit 'Updated dependencies' popd } update_project_deps "${VCS_REPO}"
乱雑にならないように、npm / composer / bundlerファイルはサンプルに追加されていません。
おわりに
一般に、FutoIn CIDは技術的なプロセスを一切課しませんが、管理者、DevOps、さらにはコマンドラインの開発者の創造性のために、VCS / SCMへの単一の軽量インターフェースのみを提供します。
もちろん、インターフェースはまだ完全に落ち着いていません;後方互換性のある変更が可能です。 見つかった問題、提案、提案は大歓迎です。