エントリーのgitの記事を要約する前に、これらの日は、今の仕事ではgitについてのマイクロブログアプリケーション開発チームの話で私の実務経験と組み合わせる気まぐれ。
集中化と分散
前GitのSVNに比べて、主に、集中型と分散との間の差に反映。主に中央サーバーに頼っ集中、開発者は、基本的に死ぬために役立つ、中央のサーバーから、中央のサーバーに送信、開発が完了した後、中央サーバから最新のコードを取得します。分散バージョン管理システムは、遠位合併を実行するために必要な場合のみ、あなたはコードを提出する開発するための中央サーバーに頼ることはできませんが、地元の倉庫を持っています。
gitの作業領域とバッファゾーン
倉庫内の局所的な仕事だけキャッシュに追加する追加のgitを通じて新しく追加された/更新されたファイルを以下に示し、その後にコミットするのgitリポジトリ経由に提出されているgitの。
これは、操作に関与することができます。
リポジトリの作成
Gitの初期化
ファイルを追加して提出します
gitの追加＆gitのコミット
コミットログを見ます
gitのログ
gitlabリモートリポジトリ
内部商法ので、私たちは、ここで使用してリモート倉庫として、私たちは、コミュニティ版を使用して同様のgitlabをgitlhub、githubのにホスティングしませんでした商用版よりも機能が少ないが、基本的には十分なものの。私たちはここにgitlabとそれぞれが更新リリースする予定、提示をしないソフトウェアのインストールについて。
Gitのワークフロー
オンラインの記事には、大きく次の三つに分け、ワークフローをたくさん説明します。
Gitの流れ
Githubの流れ
Gitlabの流れ
プロジェクトの実際の状況を感じ、わずかに異なっています。次のような方法を取るために私たちのワークフロー：
1. プロジェクトフォーク
私たちのプロジェクトは、一般的に自分のスペースを下げるためにプロジェクトチーム、日々の開発第一主倉庫フォークと提携しています。
2. gitのクローン
gitのことで、自分のローカルディレクトリのクローンを作成するためにあなたのリモートリポジトリにプロジェクトコードのクローンを作成。
3. gitのブランチ＆gitのチェックアウト
创建分支并且切换到分支上面，我们的所有的功能都是基于分支进行开发的，每次有新的功能或者对代码进行改进的时候，我们都会创建一个新的分支进行开发。
4. git add & git commit
有更新或者添加的代码，我们执行git add和git commit 提交到自己本地仓库。
5. git pull
即上面的第5步，这个是同步代码功能，因为你开发功能的时候创建分支开始时，线上的代码也是往前走的，功能开发完，代码可能落后于master的代码，这时你就需要进行同步到最新的代码，检查你的功能代码是否有代码冲突。
6. git push
这一步是把你的代码推送到远端仓库上。
7. create merge request
当接到产品或者业务测试的邮件，确定可以上线的时候，创建个merge request，这时代码就可以进入到待合并状态，如果是常规上线，之后由专人进行合并，QA回归测试，然后上线了。
git remote
上面的工作流中涉及到远程仓库的信息，如：git pull，你的代码是通过你的远程仓库拷贝的，为什么可以从远程项目组仓库进行代码同步呢，在这里说下git remote相关的内容。
我们执行git remote -v 会看到一条通道信息，这个是你本地仓库到远程仓库的通道，origin是它的名字。
然后我们通过git remote add [remote_name] [remote_url] 即可添加一条通道，如上面的upstream（也可以起其他的名字）。这时你本地的仓库就对应两条通道了。
其中upstream是不可以直接push代码的，仅用于同步代码。
git pull upstream master即从远程master上同步最新的代码。
上线
我们之前采用的如下图方式进行上线。
常规上线流程
一条基准线master，master上面的代码都是最新的代码，所有人都通过master同步更新代码。
例えば、今日の11ポイントバー（ライン上の11時00分程度の個人的勧告、それは朝のライン上に、である）、時間のある時点でのテストは問題ありません場合は、マスターに基づいて、この時間は、タグラインを作成するには、我々はrelease.0722.0と名付け、それを置きますラインへ。
online.0723.0：安定した後、我々は次のバージョンなど、masterブランチに基づいてブランチを作成するには、この時間を準備しています。
私たちは、その後、トップブランチにマージされているライン0723.0マージ要求に調製しました。その後、candidate.0722.0としてシミュレーション・マシンをテストするために、このテストタグプッシュをQA回帰テストタグを作成します。
QAテストは問題ありません場合は、私たちはマスターに上記のコードをonline.0723.0ます。この時間をテストメッセージを開発する、新しい遊びのようなrelease.0723.0ライン上の従来のオンラインパッケージのマスターに基づいて、この時間は、マスタを確保します上記は、最新のコードです。
6サイクルの次の段階へのオンラインそこで再び、従来。
緊急のオンラインプロセス
緊急時にオンライン処理の場合には、当社は、このような緊急修復状況のバグ、緊急機能線として、ここではまだ非常に一般的です。
オンラインの緊急時には、まず、この需要は知っているにつながるしなければならない、に対処するための緊急時の手順を持っている必要があります。トラフィックは、その後二乗検定と問題ありません、確認がステップ6に示すように、このコードは、マスターに直接組み込まれ、その後最新マスタコードに基づいてそのようなrelease.0723.1として、タグを作成し、オンラインの場合に問題はありません。この場所は、実際に、これはライン上の緊急事態であるあなたに伝え行に、緊急時の識別を追加することができます。