これらの壊れたものと私のGit - コード管理

1. Gitのそれとは何ですか？

プログラム猿として、私たちは、多かれ少なかれ分散型バージョン管理ソフトウェアをgit--ためにさらされていると思います。

いくつかは、それは世界で最も先進的な分散型バージョン管理システムであると言う、私は最も先進的かどうかを知っているが、本当に使いやすいと実用的ではないん、と言うでしょう。

人気のグローバルなソフトウェアとして、その歴史に言及しなければなりませんでした。

- 最初当初はLinuxカーネルの開発と設計のより良い管理のために、Linus Torvalds氏の作成と2005年までにリリースされ、広く使用されてきた今、あまりにも良いたかった、とありません。

2.私たちは何をするのGitを使用することができますか？

分散バージョン管理ソフトウェアとして、それはグレードにハイエンドの雰囲気に聞こえるが、それは分かりやすく、プロジェクトコード管理ツールです。

3.どのようにGitが正しい使用するには？

Gitはとても使いやすいですので、もちろん、プロジェクトコード管理ツールとして、このソフトウェアを使用して、世界の大手企業のほとんど。

ちょうどビジネススクールに入るとき、私はまだ覚えて、私は会社のコードは次のようセレナの猿のルックスを管理されていることがわかりました。もちろん、恐怖の食事のために慎重に操作とともに虎、サツマイモを販売するERR家として熾烈を動作させます。。

接触、悪徳、knifedフーシャオで長年のベテランとして、本当に幸せ。真話す、それは実行しないの羨望の的になります~~

実際には、プロセスの正しい動作を知っている誰もが、次の知識、あなたも大胆なことができ、あなたが値します！！

4.プロジェクト管理

まあ、そこゴシップ停止、または実際に乾燥していることにします。

私たちは、文を聞いていなければならないと考えている：安定した製品として、我々はプロジェクトが4ナインを実行していることを確認する必要があります。聞くがた、疑いの表情の下で。実際には、プロジェクトがあること、高可用性が別の引数である（つまり、1逃げたため、ご存知のように）99.99％の動作を保証することを意図しています。

高可用性のプロジェクトを確保するために、製品ラインは、厳密に一定の手続きを遵守しなければなりません。

ここにあなたの会社が同じではないと言うことがあり、いくつかの概念を、言及するが、私はそれが新しい名前であると信じて、あなたは本質、屁理屈する必要はありませんを味わうことができます。

Gitのブランチ：

マスター -分岐が一般的にバックアップとして使用され、コードは一般的に最も安定しています。
DEV -開発ブランチとしてブランチ、持続的な開発、継続的インテグレーション。
機能は -ブランチとしてのブランチは、需要の完全なライフサイクルを作成するには、開発する必要があります。
リリース -ブランチとしてリリースブランチ。
修正プログラム -バグ修正の枝などの枝、重要な欠陥があり、枝から修正プログラムバージョンによって発行されたブランチをバージョン、プルをリリースします。

導入環境：

DEV /ローカル環境 -ローカル環境。一般的に言って、プログラムの猿は（もちろん、懐の深い企業がDEVをテストするための特殊な環境を準備することができる）その試験終了後、ローカル環境としてここでいう、地域の発展になり、新たな需要を受けました。
QA環境 -同じ構成（シングルインスタンス）と生産ライン環境。地元需要でテストした後、QA環境にデプロイ、QAでテストされています。QA環境が頻繁に展開するので、マルチインスタンスの展開は、リソースと時間の無駄になります場合。
BTS環境 -生産ライン環境（分散）と一致しています。リリース前に、BTSは、環境、環境とまったく同じ生産ライン環境に展開しました。通常、UAT（ユーザー受け入れテスト）を行い、環境への放出前に3日間で展開。
PROD環境 -分散システム。生産ライン環境。

4.1新しい要件：

開発プロセス：

チームは新たな需要を受けた場合、通常はこの機能を開発するために、1匹のまたは複数のプログラム猿を手配。要件と設計を理解した後、開発はコードのすべての要件に対応する機能ブランチはブランチ上で開発される引き抜きます。
開発したとき、検証の実現可能性は、コードによって局部的に必要なテストAPEに対応するプログラムは、DEVブランチにフィットします。
ジェンキンスは、DEVのブランチからパッケージ化した後、フルタイムのQAチームによってQA環境、機能テストに配備使用します。試験は、上記のステップが繰り返され、通過しません。需要の終わりでテストします。

ローカルテストに合格し、なぜQA環境に渡されていない状態でここで、いくつかの小さなパートナーは、聞いてきますか？

一般的に、同時に複数の要件にアクセスするチームは、それはそれはバグにつながる、他の要件や影響を受ける他の要件に影響を与える可能性があり、DEVに収まるようにコードを平行します。

Gitの詳細なプロセス：

新バージョン4.2リリース

開発プロセス：

当发布新版本时，以时间或需求结束点为节点，打对应tag（方便以后回溯）。从该tag拉出release分支，Jenkins从release分支打包。
将包部署到QA环境，由专职QA进行测试。
- 如果测试不通过，从release分支中拉出hotfix分支，在hotfix分支上进行bug修复，本地测试完毕，Jenkins从hotfix分支打包，部署到QA环境测试。
- 测试通过，下一步。
将包部署到BTS环境，由专职QA进行测试。测试不通过，判断当前分支，若为release分支，则从该分支拉出hotfix分支，在hotfix修复bug后；若为hotfix分支，则直接修改bug，本地测试完毕，Jenkins打包hotfix分支，部署到QA测试。
将包部署到PROD环境，由专职QA进行测试，测试不通过，判断当前分支，若为release分支，则从该分支拉出hotfix分支，在hotfix修复bug后；若为hotfix分支，则直接修改bug，本地测试完毕，Jenkins打包hotfix分支，部署到QA测试。

Git详细流程：

上述的内容，仅为个人多年开发经验总结，或许与标准流程有一定的出入。

如有错误之处，忘各位大佬不吝斧正。

作者：吴家二少

博客地址：https://www.cnblogs.com/cloudman-open/

本文欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接