「インターネットアーキテクチャ」ソフトウェアアーキテクチャ-Gitサービスの構築と使用（4）

私のように10年以上内部開発を行っている同僚の多くは、内部エンタープライズ開発を行っています。現在もsvnを使用しています。gitについてみんなと話すと、svnはプロジェクトで使用されてから変わっていないことをみんな知っています。。これは時間の問題だと思います。私が最初に始めたとき、sshがまだstruts1で休止状態だったように、Gitは近い将来使用されるでしょう。gitはインターネットに近く、より便利です。古いアイアンが上場企業であり、コード全体の管理を担当するR＆Dセンターがsvn本社にあると私に言ったとき、svnサーバーがダウンしていて、以前のバージョンのためにバージョンをロールバックすることはできません。コードはローカルに保存されません。gitの場合、これらは問題ではないことをお伝えします。これが分散型と集中型の違いです。実際、従来の業界は依然としてsvnのより広い範囲を占めており、gitの使用にはまだある程度の時間がかかることは理解できます。ツールに時間を費やしたくないことは理解できます。ソースコード：https：//github.com/limingios/netFutureの git

GITとSVNの原則の違い

開発の歴史
2000年2月、彼らは「CVSによるオープンソース開発」（Coriolis、1999）の著者であるKarl Fogelに連絡し、この新しいプロジェクトに参加する意思があるかどうかを尋ねました。偶然にも、カールは友人のジム・ブランディと新しいバージョン管理システムの設計についてすでに話し合っていました。1995年に、2人はCVSの商用サポートを提供するソフトウェア会社であるCyclicSoftwareを設立しました。彼らはビジネスサービスを運営していますが、それでも毎日仕事でCVSを使用しています。CVSを使用することへの不満により、ジムはデータを管理するためのより良い方法を真剣に考えました。彼は「Subversion」という名前を確認しただけでなく、Subversionアーカイブの基本設計も完了しました。CollabNetの場合電話がかかってきたとき、カールはすぐにプロジェクトに参加することに同意し、ジムは雇用主のRedHatSoftwareにプロジェクトに不定期に取り組むことに同意するように依頼しました。CollabNetはKarlとBenCollins-Sussmanを雇い、5月に詳細な設計作業を開始しました。CollabNet（WebDAV / DeltaV仕様プロセスでアクティブなフリーランスプログラマー）のBrian Behlendorf、Jason Robbins、Greg Steinの多くのアイデアの助けを借りて、Subversionはすぐにアクティブな開発者コミュニティの注目を集めました。このプロジェクトのために何かをするためにCVSにも不満を持っている多くのメンバーを見つけて歓迎します。Subversionの元の設計チームは、いくつかの簡単な目標を設定しました。CVSで機能的に交換可能である必要があります。つまり、CVSで実行できるすべてのことを実行できる必要があります。最も明らかな欠陥を修正する一方で、同じ開発モデルを維持する必要があります。また、SubversionはCVSと非常によく似ているはずです。CVSユーザーなら誰でも少しの努力ですぐに始めることができます。14か月のコーディングの後、Subversionは2001年8月31日に「自己管理」を開始しました。言い換えると、開発者はCVSを使用してSubversionコードを管理するのではなく、Subversion自体を管理します。

SVN（Subversion）は集中管理バージョン管理者であり、Gitは分散管理バージョン管理者です！これが2つの主な違いです。SVNには、ファイルのすべてのリビジョンを保存する単一の集中管理サーバーしかなく、一緒に作業する人々は、クライアントを介してこのサーバーに接続し、最新のファイルを取得したり、更新を送信したりします。

バージョンライブラリは中央サーバーに一元的に保存されており、作業時には自分のコンピューターを使用するため、最初に中央サーバーから最新バージョンを取得してから作業を開始する必要があります。中央サーバーにプッシュします。中央サーバーは図書館のようなものです。本を変更したい場合は、まず図書館から借りて、家に帰って自分で変更し、変更後に図書館に戻す必要があります。

集中型バージョン管理システムの最大の問題は、機能するためにインターネットに接続する必要があることです。ローカルエリアネットワークで問題がない場合、帯域幅は十分に大きく、速度は十分に速いですが、遅い場合はインターネット上のネットワーク速度では、10Mのファイルを提出する必要があるかもしれません。5分、これは人々を窒息させるのに十分ではありません。
複数の人が共同で開発し、svnサーバーがハングアップした場合、他の誰もそれを送信できません。彼らはsvnサーバーが起動するのを待つだけで、共同開発を完了することはできません。ローカル関数の場合、バージョン番号を区別するためにブランチを作成し続けることしかできません。

GIT <英語はおにぎり、ばかを意味する>

歴史の発展

Linusが1991年にオープンソースのLinuxを作成したことは多くの人が知っています。それ以来、Linuxシステムは開発を続け、最大のサーバーシステムソフトウェアになりました。LinusはLinuxを作成しましたが、Linuxの成長は、世界中からの熱心なボランティアの参加にかかっています。世界中の多くの人々がLinuxのコードを作成していますが、Linuxのコードはどのように管理されていますか。事実、2002年以前は、世界中のボランティアがソースコードファイルをdiff経由でLinusに送信し、Linus自身がコードを手動でマージしていました。なぜLinusはLinuxコードをバージョン管理システムに入れないのかとお考えかもしれません。CVSやSVNのような無料のバージョン管理システムはありませんか？LinusはCVSとSVNに強く反対しているため、これらの集中型バージョン管理システムは低速であるだけでなく、使用するにはインターネットに接続する必要があります。いくつかの商用バージョン管理システムがあります。CVSやSVNよりも使いやすいですが、有料であり、Linuxのオープンソース精神に沿っていません。しかし、2002年までにLinuxシステムは10年間開発されていました。コードベースのサイズにより、Linusが手動で管理し続けることは困難でした。コミュニティの兄弟もこのアプローチに強い不満を表明したため、Linusはビジネスバージョン管理システムBitKeeperの所有者であるBitMoverは、人道的精神から、Linuxコミュニティにこのバージョン管理システムを無料で使用することを許可しました。Linuxコミュニティに優れた才能が集まったことで、涼山イ族の英雄たちの社会的習慣が必然的に汚染されたため、安定性と団結という素晴らしい状況は2005年に崩壊しました。Sambaの開発者であるAndrewは、BitKeeperプロトコルを解読しようとしましたが（これを行ったのはそれだけではありませんでした）、BitMoverによって発見されたため（監視はうまくいきました！）、BitMoverは怒り、無料使用を取り戻したいと考えました。 Linuxコミュニティの権利。ライナスはビットムーバーに謝罪し、将来的に兄弟を厳しく懲戒することを約束することができます。まあ、これは不可能です。BitKeeperを開発した営利企業は、Linuxカーネルオープンソースコミュニティとのパートナーシップを終了し、BitKeeperを無料で使用する権利を取り戻しました。これにより、Linuxオープンソースコミュニティ（特にLinuxの作成者であるLinus Torvalds）が強制されます。）レッスンを学ぶ必要がありましたが、独自のバージョン管理システムを開発するだけでは、同じ過ちを繰り返すことはありません。彼らは新しいシステムにいくつかの目標を設定しました。

速度

シンプルなデザイン

非線形開発モードの強力なサポート（数千の並列開発ブランチを可能にする）

完全に配布

Linuxカーネルのような超大規模プロジェクトを効率的に管理する機能（速度とデータ量）

結局のところ、実際の状況は次のようになります。Linusは2週間かけてCで分散バージョン管理システムを作成しました。これがGitです。1か月以内に、LinuxシステムのソースコードはGitによって管理されました。牛はどのように定義されていますか？あなたはそれを感じることができます。

gitライフサイクル

gitとsvnの違い

SVNの特徴は単純ですが、コードを置く場所が必要な場合は問題ありません。
Gitバージョン管理の特性は、ネットワークに依存せずに何でも実行でき、分岐とマージをより適切にサポートします（これは開発者にとって最も懸念される場所と見なす必要があります）。

gitコマンドコレクション

gitlabをビルドして使用する

上記の内容を学ぶだけで十分ですが、兵士ではなくテクニカルマネージャーの場合は、上記の知識の基本的なコマンドを理解して習得するだけでなく、プライベートサーバーのgitlab環境全体を構築する必要があります。

歴史gitlab

当初、この製品はGitLabという名前でした。これは、MITライセンスの下で配布された完全に無料のオープンソースソフトウェアでした。
2013年7月、製品はGitLabCE（Community Edition）とGitLabEE（Enterprise Edition）に分割されました。当時、GitLabCEとGitLabEEのライセンスは無料であり、MITライセンスの下でオープンソースソフトウェアが配布されていました。
2014年2月、GitLabはオープンコアビジネスモデルの採用を発表しました。GitLabEEは独自のライセンスの下で設定されており、CEバージョンには存在しない機能が含まれています。
2015年7月、同社はさらに150万ドルのシード資金を調達しました。2015年現在のクライアントには、Alibaba Group、IBM、SpaceXが含まれます。
2015年9月、GitLabはKhoslaVenturesからシリーズAの資金で400万米ドルを調達しました。
2016年7月、GitLabCEOは同社のオープンコア機能を確認しました。
2016年9月、GitLabはAugustCapitalや他の企業からシリーズBの資金で2,000万米ドルを調達しました。
Gitlabは、2017年1月31日に一連の緊急通知を発行し、オランダのシステム管理者が操作エラーのために310GBの製品データを含むフォルダーを削除し、削除をキャンセルした後、4.5GBしか残っていなかったと述べました。運用および保守担当者は後で確認し、Webサイトで主張および装備されている複数のバックアップ手段が適切に機能していないか、使用が困難であることに気付きました。Gitlabは、データを復元するプロセスをYouTubeでライブ配信しました。Webサイトは、最終的に過去6時間のデータベースデータ（質問、マージリクエスト、コメント、スニペットなどを含み、コードベースを除く）を失いました。

gitlabプライベートサーバーの構築

このgitlabのインストールでは、dockerを直接使用して、多くの複雑な構成を削除しました。
通常のgitlabに従ってインストールする場合は、構成する必要があります（面倒）：

RAM 2G

Nginx

Redis

こする

Progsql
は、ソースコードから仮想マシンを生成し、作業の準備をします。Vagrantは対応するDockerをインストールしました。
dockerを使用してnexusをインストールすると、環境変数やユーザー認証などの複雑な操作を回避できます。
vagrantのさまざまなシステムをインストールする方法については、mac install vgarantを参照してください：https
：//idig8.com/2018/07/29/docker-zhongji-07/ window install vgaranthttps：//idig8.com/2018/07/ 29 / docker-zhongji-08 /

システムタイプ	IPアドレス	ノードの役割	CPU	記憶	ホスト名
Centos7	192.168.66.100	ギット	2	2G	ギット

（1）仮想マシンのvagrantがインストール手順を指示します

（2）マシンウィンドウ/マックはrootユーザーの下でリモートログインを可能にします

su -
# 密码
vagrant
#设置 PasswordAuthentication yes
vi /etc/ssh/sshd_config
sudo systemctl restart sshd

（3）gitlabをインストールします

シェルスクリプトhttps://hub.docker.com/r/sonatype/nexus/を実行します

mkdir gitlab
cd gitlab
mkdir postgresql
mkdir redis
mkdir gitlab
chown -R 200 data
pwd
ll
vi start.sh

image.png

start.sh設定したユーザー名：rootパスワード123456789qwe

#!/bin/bash
cur_dir=`pwd`
docker stop gitlab-postgresql
docker rm gitlab-postgresql
docker stop gitlab-redis
docker rm gitlab-redis
docker stop gitlab
docker rm gitlab
docker run --name gitlab-postgresql -d \
    --env 'DB_NAME=gitlabhq_production' \
    --env 'DB_USER=gitlab' --env 'DB_PASS=password' \
    --env 'DB_EXTENSION=pg_trgm' \
    --volume ${cur_dir}/postgresql:/var/lib/postgresql \
    sameersbn/postgresql:10
docker run --name gitlab-redis -d \
    --volume ${cur_dir}/redis:/var/lib/redis \
    sameersbn/redis:4.0.9-1
docker run --name gitlab -d \
    --link gitlab-postgresql:postgresql --link gitlab-redis:redisio \
    --publish 10022:22 --publish 10080:80 \
    --env 'GITLAB_PORT=10080' --env 'GITLAB_SSH_PORT=10022' \
    --env 'GITLAB_ROOT_PASSWORD=123456789qwe' \
    --env 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' \
    --env 'GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string' \
    --env 'GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-string' \
    --volume ${cur_dir}/gitlab:/home/git/data \
    sameersbn/gitlab

シェルスクリプトを実行する

sh start.sh

最初はhttp://192.168.66.100:10080/でしたが、gitlabが初期化された後は正常でした。

管理者：rootパスワード：123456789qwe

gitを使用するためのヒント

.gitignore追加無視ファイル、追加および送信時に自動的に無視
開発時に、開発者が5人（A、B、C、D、E）の場合、バージョンは2018年12月12日にリリースされ、Aはプロジェクトチームリーダーであり、ブランチリリース20181212はマスターを通じて確立されます。 5人のブランチは、task_A_relase20181212、task_B_relase20181212、task_C_relase20181212、task_D_relase20181212、task_E_relase20181212です。それぞれの開発が完了した後、それらはマージ方法によってrelease20181212にマージされ、Aはrelease20181212でテストされます。B（緊急の問題がある）の場合、Bはそれを修正するためにrelease20181212に切り替えます。全員が修復された後、release201212はAからマスターブランチにマージされます。
競合の解決：近接ブランチ、最後のコミットに戻り、最新のコードをプルし、現在のブランチとマージしてからコミットします。

PS：gitの素晴らしさを感じることができないかもしれません。比較的小さな会社の場合、特に誰もがgitに慣れていない場合は、svnを使用することをお勧めします。今では会社が比較的大きいときです。プロジェクトの開発たとえば、現在開発中のプロジェクトには毎週ブランチがあり、4日ごとに新しいバージョンが提出されると、並行開発中の古いアイアンがたくさんあります。Svnは間違いなく管理できませんが、 git、gitlab、ブランチ管理、提出ツリーには多くの機能があります。非常に強力です。実際の開発では非常に厄介で厄介です。すべての行です。svnでは考えられないでしょう。 gitではなくローカル提出の問題であるだけでなく、それが良いかどうかという問題だけでなく、選択する問題があるかどうかという問題は、私たちが選択するテクノロジーまたはテクノロジーを選択します。会社がgitを使用している場合は、svnを使用する必要がありますよね？さらに、私は中国人によって書かれた比較的素晴らしいgitサービス管理ツールであるgogsをお勧めします。

「インターネットアーキテクチャ」ソフトウェアアーキテクチャ-Gitサービスの構築と使用（4）

GITとSVNの原則の違い

おすすめ