五、Gitワークフロー

6. 作業エリアと一時保管エリア

7. ファイルのステータスを表示する

八、提出ログを見る

I.はじめに

前の記事「Git ダイアグラム - なぜ Git なのか?」に続きます。ふりをする方法は？次に、Git の一般的に使用されるコマンドを見てみましょう。

2.倉庫を初期化する

Git 操作の前に、バージョン管理のプロジェクトコードを格納するためにウェアハウスを初期化する必要があります。現在、Git ウェアハウスには次の 2 種類があります。

ローカル倉庫: 開発者自身のコンピューター上の倉庫
リモートウェアハウス: リモートサーバー上のウェアハウスです (他のチームメンバーと共有されます。当面はここでは言及しません)。

自分の名前とメールアカウントを設定します。会社では通常、自分の名前のピンインと会社の仕事用メールです。

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

ローカル倉庫を初期化する

git init

コマンドが実行されると、現在のディレクトリの下に追加の.gitディレクトリが作成されます . このディレクトリGitは、コード (ファイル) を追跡および管理するために使用されるローカルウェアハウスです.このディレクトリ内のファイルを手動で変更しないでください. 簡単です変更して、Git倉庫を跳ね上げます。

ここで、一部の友人のコンピューターは非表示のプロジェクトオプションをチェックせず、.git ディレクトリが表示されないことに注意してください。

3. ファイルを追加する

ウェアハウスが初期化されました。ファイルをウェアハウスに追加して管理するにはどうすればよいですか?

ステップ 1: プレーンテキストファイルを作成する

ステップ 2: ファイルをステージング領域に追加する

git add readme.txt

ステップ 3: リポジトリにファイルを追加する

git commit -m "添加了readme.txt文件"

git commitコマンドを簡単に説明します.-m以下の入力はこの送信の説明です. 任意の内容を入力できます. もちろん,意味のあるものにする必要があります. git commitコマンドが正常に実行されると、1 つのファイルが変更されたことが通知されます (新しく追加された readme.txt ファイル)。

拡大

後でさらにファイルを追加する場合は、次のコマンドを使用できます

git add file1.txt
git add file2.txt file3.txt
git add .   当前文件夹下所有文件
git commit -m "add 3 files."

四、Gitプロセス全景

五、Gitワークフロー

6. 作業エリアと一時保管エリア

Git で crud 操作を実行する場合, git add file の操作を実行する必要があります. 基になる操作は操作ファイルをキャッシュ領域と呼ばれる領域のキャッシュに追加します. 操作が完了したら, git commit 操作を使用して実行します.統合された提出、および編集されたファイルは統合され、同期されます。

7. ファイルのステータスを表示する

質問:プロジェクトの現在のステータスを確認するにはどうすればよいですか? しばらくパソコンの前でコードを書き、Git で管理し、途中でトイレに行き、リンゴを食べに行き、仕事に戻るという作業を続けました。 ?

git status # 查看当前git版本库的状态(查看缓存区中的文件内容)

八、提出ログを見る

実際の作業では、何千行もあるファイルの変更内容を毎回頭の中でどのように記憶できるのでしょうか?そうでなければ、バージョン管理システムは何のために必要になるのでしょうか? バージョン管理システムには、履歴を表示できるコマンドが必要です。では、コマンドをGit使用して表示しますgit log

git log

git logこのコマンドは、コミットログを近いものから順に表示します.出力情報が多すぎて目がくらむ場合は、--pretty=onelineパラメータを追加してみてください:

git log --pretty=oneline

長い黄色の文字列は、この送信のコミット ID です。これは、アルゴリズムGitによってSHA-1生成された一意の識別子であり、グローバルに一意であることが保証されています。

九、違いを見る

ファイルが変更されたことがわかっている場合は、何が変更されたかを確認できるとよいでしょう.
たとえば、2 週間の海外旅行から戻ったとき、初日に出勤したときに、次のことができます。前回`readme.txt`をどのように変更したか覚えていないので、コマンド`git diff`を使用して確認する必要があります。

git diff # 查看不同版本之间的文件差异

10. バージョンのロールバック

私たちは常にファイルを変更し、リポジトリにファイルを提出しています。ゲームをプレイするときと同じようにRPG、レベルを通過するたびにゲームの状態が自動的に保存されます.特定のレベルが経過していない場合は、前のレベルの状態を読み取ることも選択できます. Gitファイルがある程度変更されたと感じるときはいつでも、「スナップショットを保存」できます。このスナップショットGitはで呼び出されますcommit。ファイルを台無しにしたり、誤ってファイルを削除したりしても、commit数か月分の作業をすべて失うことなく、最新のものから復元して作業を続けることができます。

以前のバージョンに戻したい場合はどうすればよいですか?

Git現在のバージョンがどのバージョンであるかを知る必要があります. においてGit, use はHEAD現在のバージョンを意味します. 前のバージョンはでありHEAD^, 前のバージョンはですHEAD^^. もちろん, 前の 100 バージョンに 100 ^ を書くことは数えるよりも簡単なので, のように書きます. HEAD~100.

git reset --hard HEAD^

指定したバージョンに戻す

git reset --hard <commit id>

拡大する要件: 最新バージョンにロールバックする方法

11.管理者の変更

Git を使用してファイルを変更するには、議論する必要がある問題があります: 二次変更

操作モード 1:

第一次修改 -> git add -> 第二次修改 -> git commit`

操作方法 2: 推奨

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

注: 各コミットの前に、ファイルが追加されていないかどうかを確認することをお勧めします

12. 変更の取り消し

git checkout -- filename` は、ワークスペース内の変更を破棄できます: -- スペースが続きます

このコマンドgit checkout -- readme.txtの意味はreadme.txtワークスペース内のファイルのすべての変更をキャンセルすることです。ここには 2 つの状況があります: 1. 変更後、ファイルはreadme.txt一時記憶領域 ( ) に配置されていませんgit add。ここで、変更はリポジトリと同じ状態 2:readme.txt一時保存領域に追加された後、変更されています. これで、変更を元に戻すと、一時保存領域に追加された後の状態に戻ります.

つまり、このファイルgit commitをgit add前回の状態に戻すことです。

注: git checkout -- fileコマンド内のは--非常に。これがないと、 「別のブランチに切り替える」--コマンドになります。後でブランチ管理でコマンドにgit checkout

13.ファイルを削除する

通常、不要なファイルはファイルマネージャで直接削除するか、rmコマンドで削除します。

git rm test.txt

この時点で、Gitファイルを削除したことがわかっているため、ワークスペースとバージョンライブラリに一貫性がなく、git statusコマンドは削除されたファイルをすぐに通知します。

削除完了後に必要commit

削除して復元したい場合は、resetバージョン

ステップ 1: 不要なファイルをローカルで削除する (ステータスを確認する)

ステップ 2: 最初に以下を追加します (ステータスを確認し、ステップ 1 と比較します)。

ステップ 3: ファイルを送信して削除する

十四、支店管理

ブランチ管理は Git の魂であり、基本的な操作は開発に不可欠であり、マスターする必要があります。

支部はなぜ存在するのか？プロジェクトの完成品は、開発、テスト、リリース、バグ修正、マルチバージョンリリースなどのプロセスを経るためです。同じプロジェクトの異なるバージョンが同時に開発され、テストされ、開始されます.このような複雑な状況で、プロジェクトが独立して相互に関連していることを確認するにはどうすればよいでしょうか? Git が提供するソリューションはブランチ管理です. 各ステージはブランチであり、互いに独立してマージすることができます.

ブランチを見る

git branch

ブランチを作成

git branch <name>

分岐を切り替える

git checkout <name>

作成 + ブランチの切り替え

git checkout -b <name>

マージブランチ

ブランチを現在のブランチにマージする

git merge <name>

ブランチを削除

git branch -d <name>

15. プロジェクト分岐の運用

簡易版

完全版

master ブランチ: バージョンの更新に使用. 比較的大きな機能を開発または更新する場合、一括リリースがあり、すべてのコードが master にマージされます (一部の企業ではリリースブランチを使用してバージョンをリリースし、原則は同じです）同じもの）;

開発ブランチ: 通常、開発およびテストブランチです. プロジェクトがリリースおよび起動される前に、マスターブランチにプッシュする前に、機能が標準を満たしていること、およびバグがないことを確認するために、開発ブランチで一様にテストされます;

feature branch : サブモジュール機能の開発に使用されます。feature-xxx という名前にすることをお勧めします。モジュールが完成すると、dev ブランチにマージされます。

Hotfix/fixbug ブランチ: オンラインの緊急バグ修正に使用されるブランチで、hotfix-xxx という名前にすることをお勧めします。オンラインで特定のバージョンに問題が発生した場合、対応するバージョンのコードがチェックアウトされ、Hotfix ブランチが作成され、問題が修正された後、dev と master にマージされます。 master にマージする場合、通常、修正後にバージョンにラベルを付ける必要があります。

長文:エレガントな Git ブランチの実践_git ブランチ管理のベストプラクティス_Langfei yes のブログ - CSDN ブログ