1.GITをインストールする
公式 Web サイトから GIT をダウンロードします: https://git-scm.com/downloads
2.倉庫を作成する
リポジトリを作成したいフォルダの空白部分を右クリックし、
ポップアップメニューの「GIT Bash Here」をクリックし、リポジトリを初期化します。
$ git init
成功すると、フォルダー内に追加の ".git" 隠しフォルダーが作成されます。このディレクトリは、バージョンの追跡と管理に GIT によって使用されます。このディレクトリ内のファイルを手動で変更しないでください。変更しないと、git ウェアハウスが破壊されます。 。
.git は隠しフォルダーなので、表示するには事前に隠しフォルダーを表示するように設定する必要があります。
1. フォルダーオプションを開く
または
2. 隠しファイルを
表示するように設定する ただし、.git フォルダーが存在することを確認するだけで、内容をむやみに変更しないでください。
3. GIT パーティショニングとワークフロー
- ワークスペース: ワークスペース
はプログラマーがコードを編集する場所です。これは、.git (ウェアハウス) が配置されているディレクトリです (.git 内ではありません)。すべての変更はこの領域で行われ、最初にこの領域で直接有効になります。 - インデックス / ステージ:
一時ストレージ領域内の変更されたファイルが一時的に保存される場所。ウェアハウスに送信されるすべての変更 (ワークスペース内のファイルの追加、削除、変更) は、最初にここに追加 (追加) する必要があります。送信されました (コミット)。もちろん、ワークスペースをチェックアウトすることもできます。
リポジトリ: ウェアハウス エリア (またはローカル ウェアハウス) 内の各送信はバージョンです。ウェアハウス エリアには、以前に送信された各バージョンが保存されます。リモート ウェアハウスにプッシュしたり、ワークスペースに復元 (リセット、元に戻し、チェックアウト) したりすることができます。- リモート: リモート ウェアハウス リモート
ウェアハウスには、1 人以上の作成者がローカル ウェアハウスからプッシュしたさまざまなバージョンとブランチが保存されます。各作成者は、最新バージョンのマスター (マスター ブランチ) をローカルにプルし、自分の変更をマージして、それをリモート ウェアハウスのマスター ブランチにプッシュして他のユーザーが使用できるようにします。全員が自分のパートに責任を持ち、自分の結果を master ブランチにマージするので、分業が容易になります。
4. 一時記憶領域にファイルを追加する
4.1 まずは倉庫の現状を確認する
$ git status
赤色のファイルは、ステージング領域に追加されていないファイルです。新しく作成されたウェアハウスの場合、フォルダー内のすべてのファイルは、git status の後に赤色になります。これは、これらのファイルがステージング領域に追加されておらず、すべて "追跡されていないファイル」（追跡されていないファイル）。
4.2 単一のファイルを一時記憶領域に追加する
$ git add source1.c
4.3 複数のファイルを一時記憶領域に追加する
$ git add source1.c source2.c source3.c
4.4 すべてのファイルを一時記憶領域に追加する
$ git add .
ステージングエリアに追加後、ウェアハウスのステータスを確認すると、追加されたファイルが緑色に変わります。
5. 一時保存領域に追加されていないファイルをクリアします
新しく追加されたファイル、またはこれまで追跡されたことのないファイル (一時記憶領域に追加されたファイル) をクリアする場合は、次のコマンドを使用できます。
たとえば、source4.c とsource5.c が追加されているか、ローカル ウェアハウスを作成した後にステージング領域に追加されていないため、それを削除したいと考えています。
5.1 クリーンアップで削除されるファイルを確認する
$ git clean -n
5.2 現在のディレクトリ内の追跡されていないファイルをすべて削除します。.gitignore ファイルで指定されたフォルダーとファイルは削除されません。
$ git clean -f
実行後、フォルダー内のsource4.cとsource5.cは削除されますが、再度git statusを実行(ウェアハウスの状態を確認)すると、これら2つのファイルのリマインダーは表示されなくなります。
5.3 指定されたパス内の追跡されていないファイルを削除する
$ git clean -f <路径>
5.4 現在のディレクトリ内の追跡されていないファイルとフォルダーを削除する
$ git clean -df
5.5 .gitignore ファイルで指定されたフォルダーやファイルであるかどうかに関係なく、現在のディレクトリ内の追跡されていないファイルをすべて削除します。
$ git clean -xf
5.6 .gitignore ファイルの追加
一般に、Git で管理する必要がなく、追加したり送信したりする必要のないファイルが常に存在します。また、それらのファイルが追跡されていないファイル リストに常に表示されることは望ましくありません。通常、これらはログ ファイルなどの自動的に生成されるファイルや、コンパイル プロセス中に作成される一時ファイルです。
たとえば、file1.txt という一時ファイルがあり、コンパイル プロセス中に生成されたアセンブリ ファイル (*.o) がありますが、これは無視します。
.gitignore ファイルがない場合、ステータスを表示するとこの追跡されていないファイルが表示されます。
5.6.1 .gitignore ファイルの作成
まず window の下に作成された状況を見てみましょう
. 新しいドキュメントを作成すると、次のファイルが表示されます。
名前を変更します。
何か問題が発生しました! 空の名前と .gitignore サフィックスを持つファイルを作成したいので、ウィンドウで作成されたファイルには名前が必要です。
それを修正するにはどうすればよいですか?
まだメソッドはあります。git Base のブラック ボックスで作成できます。次に、vim または vi エディターを使用して編集するか、ディレクトリ内をダブルクリックして編集を開きます。
.gitignore ファイルを作成して編集した後 (編集プロセスはこのセクションの最後にあります)、ウェアハウスのステータスを確認してみましょう。
以前は追跡されていないとして表示されていたファイルが無視されていることがわかります。
次に、.gitignore を追加して送信すると、最新バージョンの .gitignore ファイルが作成されます。
ただし、ファイルがすでにリポジトリにある場合は、無視しても効果はありません。
たとえば、source1.c はすでにウェアハウスにあるファイルであり、newfile.txt はステージング領域に追加された新しく作成されたファイルですが、ここでは無視します。
無視することは無効であることがわかります。source1.c が変更された後も、対応するリマインダーが表示されます。一時記憶領域の newfile.txt はまだ存在しており、newfile.txt への変更を続けると、対応するリマインダーが表示されます。
ファイルを無視したい場合は、まずそのファイルが現時点でウェアハウスおよびステージング領域にないことを確認する必要があることがわかります。
それらがすでに倉庫や中継エリアにある場合、唯一の方法はそれらを一掃することです。
以下に示すように:
以下はvimエディタでの編集手順です。
$vim .gitignore コマンドを実行した後、vim エディターは .gitignore ファイル (空のファイル) を開きます。これは vim エディターの通常モードです。i をクリックして挿入モード (編集可能) に入ります。
5.6.2 gitignore ファイルの書き方
1. すべての空行またはコメント記号 # で始まる行は、Git によって無視されます。
2. 標準のグロブ パターン マッチングを使用できます。
3. バックスラッシュ (/) が続く一致パターンは、ディレクトリが無視されることを示します。
4. 指定したパターンの外にあるファイルまたはディレクトリを無視するには、パターンの前に感嘆符 (!) を追加してパターンを無効にします。
いわゆるグロブ パターンは、シェルで使用される簡略化された正規表現を指します。
- アスタリスク (*) は 0 個以上の任意の文字と一致します。
- [abc] は、角括弧内にリストされている任意の文字に一致します (この例は、a、b、または c のいずれかに一致します)。
- 疑問符 (?) は任意の 1 文字のみに一致します。
- ダッシュを使用して角かっこ内の 2 つの文字を区切ると、これら 2 つの文字の範囲内のすべてが一致する可能性があることを意味します (たとえば、[0-9] は 0 から 9 までのすべての数字が一致することを意味します)。
例えば：
# 此为注释 – 将被 Git 忽略
*.a # 忽略所有 .a 结尾的文件
!lib.a # 但 lib.a 除外
/TODO # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/ # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
/、/*および!
/OBJ/ は、
OBJ ディレクトリ内のすべてのファイルが無視されることを示します。
/OBJ/
!/OBJ/UWB.sct * は
、OBJ ディレクトリ内のファイルが UWB.sct を除いて無視されることを示します。
「!」はトレースを復元するために使用されますが、ファイルが存在するディレクトリが無視されると、ファイルを再度トレースすることはできません。
*および**
/a/*/b は、a の第 2 レベルのサブディレクトリ (a/x/b など) にある b のみと一致します。 /a/
**/b は、a など、a の任意のレベルのサブディレクトリにある b と一致します。 /b 、a/x/b、a/x/y/b …
6. ウェアハウス内のファイルを削除する
6.1 ウェアハウス内のファイルを一時ストレージ領域に削除するリクエストを追加し、ファイルの追跡をキャンセルしますが、ソース ファイルは削除しません
$ git rm --cached source1.c
注意: 複数のファイルをクリアしたい場合は、後でリストするだけです。
実行後:
ウェアハウス内のファイルの削除リクエストは一時ストレージ領域に追加され、送信後に有効になります。
ファイルの追跡をキャンセルし、すぐに有効になります
。ワークスペース内のファイルとその変更はまだ存在しますが、変更はステージング領域には追加されません。
6.2 ウェアハウス内のファイルの削除リクエストを一時保存領域に追加し、ソースファイルを削除する
$ git rm source1.c
注意: 複数のファイルをクリアしたい場合は、後でリストするだけです。
コマンドの実行後:
ソース ファイルはすぐに削除され、ウェアハウス内のファイルの削除は送信後にのみ有効になります。
7. ワークスペース内の追跡ファイルの変更を元に戻す
7.1 まずは倉庫の現状を確認する
$ git status
これは、ワークスペースで変更された追跡ファイルです。
7.2 追跡されたファイルに対する特定の変更を表示する
$ git diff
7.3 追跡されたファイルのどのコンテンツが変更されたかを確認する
$ git diff soure1.c
注意: 複数のファイルを表示したい場合は、後でリストするだけです。
赤は削除されたコンテンツ、緑は追加されたコンテンツです。
7.4 特定のタイプの追跡ファイルによってどのコンテンツが変更されたかを確認する
場合によっては 1 つまたは 2 つのファイルのみが変更されることがありますが、コンパイル後、git status では多数のファイルが変更されたことがわかります (赤でマーク) git diff を直接使用すると、次の内容は人生を疑うようなものになります。したがって、特定の種類のファイルの変更を調べることもできます。
注意: 複数のカテゴリを表示したい場合は、後でリストするだけです。
$ git diff *.c *.h
もちろん、より良い方法は、.gitignore ファイルを使用してこれらの中間ファイルを無視し、トレースしないことです。具体的な操作については、セクション 5.6.1 を参照してください。
7.5 ワークスペース内の追跡ファイルの変更を元に戻す
$ git checkout -- source1.c
注意: 複数のファイルをクリアしたい場合は、後でリストするだけです。
例: 上の図の「modified: source1.c」は、一時記憶領域内のファイル source1.c が変更されていることを示しています。$ git checkout – source1.c を使用して、この変更を破棄できます。
7.6 ワークスペース内の追跡ファイルに対するすべての変更を元に戻す
$ git checkout .
7.7 最後の git add 後にローカル ワークスペース内の追跡されたファイルに対するすべての変更 (追加、削除、変更) をキャンセルし、追跡されていないファイルを削除する
$ git checkout . && git clean -df
例: 現在のディレクトリには、source1.c、source2.c、source3.c が含まれており、これらはすべて前回一時記憶領域に追加されました。
その後、source4.c が追加され、source3.c の内容は 333 に変更されました。
ウェアハウスのステータスを確認すると、現在のディレクトリが最後にステージング領域に追加されたとき (git add) と比較して、現在のディレクトリ内のすべての変更を確認できます。
これらの変更を破棄したい場合は、 $ git checkout . && git clean -df
上記の内容に従って、
$ git checkout . は、source3 の変更など、ワークスペース内の追跡されているファイルの変更を破棄します。 .c 上記
$ git clean -df は追跡されていないファイルを破棄します。たとえば、
上記の 2 つの新しく追加されたsource4.c コマンドを実行した後、追跡されたファイルを最後の git add 後の状態に復元できます。
8. 地元の倉庫に提出する
8.1 送信する前に、ウェアハウスのステータスをチェックして、一時保管領域内のファイルが変更されていないことを確認してください。
$ git status
上の図で、「modified: source1.c」はファイルが変更されていることを意味しており、送信する前にこのプロンプトに対処する必要があります。
方法 1 この変更をステージング領域に更新するには、次を使用できます。
$ git add source1.c "或 "$ git add .
方法 2 この変更を破棄するには、次のコマンドを使用できます。
$ git checkout -- source1.c
8.2 一時記憶領域に変更されたファイルがある場合は、まず add コマンドを使用してそれらのファイルを一時記憶領域に更新する必要があります。
$ git add sorce1.c //把source1.c加到暂存区
或
$ git add . //把当前目录中所有文件加到暂存区
8.3 ファイルの送信 (次の –m はコメントです)
$ git commit –m “注释内容”
これはローカル ウェアハウスにのみ送信されます。リモート ウェアハウス (github) にプッシュして保存するには、次の条件または操作を満たす必要があります: 1. github アカウントを持っている 2. github ウェアハウスを作成する 3. SSH KEY
を
作成
する4. ローカルリポジトリ
と github リポジトリ間の関連付けを確立する
8.4 最近送信されたコメントを変更する
$ git commit --amend
8.5 以前に 1 回以上送信されたコメントを変更する
$ git rebase -i HEAD~2 //修改最近两次提交的注释
以下は git rebase -i HEAD~2 コマンドを実行した後に表示されるウィンドウです。上に表示されたウィンドウはまだ編集できません。「i」をクリックして編集モードに入ります。
指示を編集した後、コメントを変更するステップに進みます。
8.6タップ
頻繁にコミットを行うと、高密度のコミット レコードの長いリストが作成されます。プロジェクトに問題が発生し、特定のノードのコードの問題をチェックする必要がある場合、少し頭の痛い作業になります。コミットメッセージはあるものの、見つけにくい、説明がわかりにくいなどの問題がまだあります。
ほとんどの VCS と同様に、Git は特定の時点のバージョンにタグを付けることもできます。特定のソフトウェア バージョン (v1.0 など) をリリースするときにこれを行うことがよくあります。
タグ付けの目的は、プロジェクトの開発ノードにセマンティック名、つまり機能バージョンのエイリアスを追加することです。タグ名と付随する情報を追加すると、プロジェクトの将来のメンテナンス中に後戻りやレビューが容易になります。さらに、タグ レコードを使用して、現在のプロジェクトの下位互換性、API の変更、イテレーションを大まかに理解することもできます。
8.6.1 現在のバージョンにタグを付ける
git tag コマンドの後にタグ名を指定して、タグを直接作成します。
$ git tag v1.0
-a パラメータを追加してコメント付きのタグを作成することもできます。コメント情報は -m で指定されます。
$ git tag -a v1.0 -m "备注信息"
8.6.2 指定したコミット番号にラベルを付ける
タグは先頭にある必要はなく、以前のバージョンに付けることもできます。
8.6.3 既存のタグの一覧表示
$ git tag
8.6.4 タグの詳細を表示する
$ git show v1.0 //查看v1.0标签的详细信息
8.6.5 特定のタグに対応するバージョンに切り替える
$ git checkout v1.0 //切换到v1.0标签对应的版本
v0.5 バージョンにさらに変更を加えたい場合は、v0.5 バージョンに入った後、フリー状態になります。この状態で、新しいブランチを作成して切り替え、その後、ブランチを保存できます。変更と提出。
8.6.6 タグをリモートウェアハウスに同期する
$ git push origin v1.0 //将本地v1.0标签同步到远程仓库
8.6.7 タグの削除
8.6.7.1 ローカルタグの削除
$ git tag -d v1.0 //删除本地的v1.0标签
8.6.7.2 リモート倉庫のタグの削除
リモート ウェアハウスのタグを削除する場合は、まず対応するローカル タグを削除してから、リモート ウェアハウスのタグを削除する必要があります。削除しないと無効になります。
$ git push origin :refs/tags/v1.0 //删除远程仓库的v1.0标签
ヒント: リモート倉庫の詳細については、以下の講義 9 と 10 を参照してください。
9. アカウントの登録、ウェアハウスの作成、SSH キーの作成
9.1 まず、公式 Web サイトにアクセスして github アカウントを登録します: https://github.com/
9.2 Githubリポジトリの作成
9.3 SSHキーの作成
ローカル Git リポジトリと github リポジトリ間の転送は SSH を介して暗号化されるため、ローカルで SSH キーを作成し、github 許可リストに追加する必要があります。
9.3.1 SSH があるかどうかを確認する SSH が作成されていない場合は、存在しないはずです。
$ cd ~/.ssh
$ ls
id_rsa.pub または id_dsa.pub ファイルがすでに存在するかどうかを確認し、存在する場合は、すでに SSH が存在します。
9.3.2 SSHキーの作成
$ ssh-keygen -t rsa -C "注释文字"
コマンドパラメータの意味:
-t キーの種類を指定します。デフォルトは rsa で省略可能です。
-C は、電子メール アドレスなどのコメント テキストを設定します。
-f にはキーファイル格納ファイル名を指定します。
上記のコードでは -f パラメータが省略されているため、上記のコマンドを実行した後、生成された SSH キー コードを保存するためのファイル名の入力を求められます。
9.3.3 id_rsa.pub ファイルの内容をコピーする
$ clip < ~/.ssh/id_rsa.pub
このコマンドを実行すると、SSH KEYの公開鍵がペーストボードにコピーされているので、githubに貼り付けることができます。
9.3.4 github に移動して設定を開きます
9.3.5 SSHの追加
任意のタイトルを入力し、id_rsa.pub ファイルの内容を [キー] テキスト ボックスに貼り付けます。
9.3.6 リモートライブラリのアドレスをコピーする
githubリポジトリをクリックします
10. 遠隔倉庫に関連する
10.1. リモートライブラリ情報の表示
$ git remote
$ git remote –v （-v显示对应的克隆地址）
リモートウェアハウスが関連付けられていない場合、実行後は何も表示されません。
10.2.リモートライブラリの関連付け
$ git remote add heater_mainboard [email protected]:wuzulie/Demo_hub.git
リモート ライブラリの名前は、Git のデフォルト名であるorigin ですが、他の名前に変更することもできますが、origin という名前が一目でリモート ライブラリであることがわかります。
関連付け後、git Remote を使用してリモート ウェアハウスの情報を確認すると内容が得られます。fetch はフェッチ アドレス、push はプッシュ アドレスに対応します。
10.3 リモートライブラリの削除
$ git remote rm origin
削除後にリモートライブラリを確認するとコンテンツがなくなっています。
11. ブランチの作成とマージ
ほとんどすべてのバージョン管理システムは、何らかの形式での分岐をサポートしています。ブランチを使用するということは、メインの開発ラインの安定バージョンに影響を与えないように、メインの開発ラインから作業を分離できることを意味します。
まず、新しいバージョンをリリースするために使用される master ブランチは非常に安定している必要があり、通常の状況ではこのブランチでの作業は許可されません。
通常、作業は新しく作成された dev (develop) ブランチで行われ、dev ブランチに追加された新機能はデバッグおよび安定化された後、配布のために main ブランチ マスターにマージされます。
突然バグを見つけた場合は、マスター ブランチから新しいブランチを作成してバグを修正できます。パッチが完了したら、それを master ブランチにマージして戻します。一般に、開発ブランチやその他の新機能開発ブランチではバグはパッチされません。これらのブランチのコードは通常、編集プロセス中に完成しておらず、新しいバグが存在する可能性が高いためです。一時的に実行できなくなります。
現時点では、ブランチは master ブランチ 1 つだけです。HEAD は、現在のブランチの最新バージョンを指します。
11.1 ブランチ戦略
上の例では、master ブランチと dev ブランチのみを使用しました。実際の開発では、ブランチを 2 つだけ持つことは不可能です。他にどのようなブランチがあるべきでしょうか?また、これらのブランチ間の違いは何ですか?
- プロジェクト内の 2 つの長年にわたるブランチ
master : オンライン バージョンの反復を記録するメイン ブランチ。このブランチのコードはオンライン コードと完全に一致しています。
Development(dev) : 比較的安定したバージョンを記録する開発ブランチ、およびすべての機能ブランチとバグ修正ブランチはこのブランチから作成されます。
- 他のブランチは短期ブランチであり、機能開発が完了したら削除する必要があります。
feature : feature (function) ブランチ、新しい関数の開発に使用されます。異なる関数は異なる関数ブランチを作成します。関数ブランチが開発されて自己テストされた後、開発ブランチにマージしてから削除する必要があります。
bugfix : 緊急でないバグを修正するために使用されるバグ修正ブランチ。通常のバグの場合は、開発用にバグ修正ブランチを作成する必要があります。開発が完了し、セルフテストに問題がなければ、開発ブランチにマージして削除しますブランチ。
release : リリース ブランチ。コードをオンラインにする準備に使用されます。このブランチは開発ブランチから作成されます。作成後、テストのためにテスト生によってテスト環境にリリースされます。テスト中に見つかったバグは、開発者がバグを修正する必要があります。リリース ブランチ。すべてのバグが修正されました。完了後、オンラインになる前に、リリース ブランチをマスター ブランチおよび開発ブランチにマージする必要があります。
hotfix : 緊急バグ修正ブランチ。このブランチは緊急時にのみ使用されます。マスター ブランチから作成され、オンラインバグを緊急に修正するために使用されます。修復が完了した後、オンラインにするにはブランチをマスター ブランチにマージする必要があります。であり、develop ブランチにマージする必要があります。
11.2 現在のすべてのブランチを表示する
$ git branch
11.3 ブランチの作成
バグを修正したり、新しい機能を追加したりする場合、多くの場合、変更とテスト用のブランチを作成します。目標を達成した後、それをメイン ブランチにマージし直すと、それに応じてメイン ブランチのバージョンが変更されます。
$ git branch dev //创建分支dev
作成後の新しいブランチは、倉庫エリア、ステージングエリア、作業エリア、送信レコードを含め、メインブランチとまったく同じになります。
11.4 ブランチの切り替え
$ git checkout dev
注: ブランチを切り替えるときにステージング領域とワークスペースが変更されると、切り替えエラーが発生したり、ファイルが失われる可能性があります。
変更を加えてブランチを切り替える場合、次の 5 つの状況が考えられます。
1. ウェアハウス内のファイルは変更されておらず、ステージング領域およびワークスペース内の変更されたファイルはコミットされていません。この場合、任意の
ブランチに切り替えることができ、ステージング領域およびワークスペース内の変更もコミットされます。切り替え後は共有されます。共有と言っているのは、切り替え後は一時記憶領域とワークスペースの内容が同じになるからです。さらに、いずれかのブランチのステージング領域またはワークスペースにあるコミットされていないファイルに変更を加えた場合、その変更は他のブランチにも反映されます。
2. ウェアハウス内のファイルは変更されていますが、切り替え前後のブランチ間でファイルの内容に矛盾はありませんが、この場合も
一時保存領域やワークスペースの変更は切り替え可能です。切り替え後も共有されます。この共有については上記と同じですので、詳細は省略します。
3. ウェアハウス内のファイルが変更されており、切り替え前後の分岐のファイル内容が競合している場合、
以下のように切り替え時にエラーが発生します。
4. 現在のブランチの新しいファイルは、切り替え対象のブランチ ウェアハウスのファイルと同じ名前ですが、内容が異なるか、ファイルがステージング領域に追加されていない場合、切り替えは失敗します
。 、以下に示すように。
注: 一時保存領域に同名のファイルが追加されていない場合、内容が同じであっても切り替えはエラーとなります。
5. 現ブランチの新規ファイルは、切り替え対象のブランチ倉庫のファイルと同名、内容も同一（同一ファイルとみなせる）であり、一時記憶領域にも追加されます。この場合、
以下に示すように、ファイルは失われます。
したがって、ブランチを切り替える前に特別な注意を払い、一時保管領域がきれいであることを確認する必要があります。ファイルがある場合、状況によっては、ファイルを切り替えることができず、最初に送信する必要があります。それ以外の場合（一時保管場所のファイルが切替後の支店倉庫にも存在し、内容は以前と同じ）、ファイルが失われます。
もちろん、作成切り替えコマンド「$ git checkout –b dev」を使用すると、ステージングエリアやワークエリアの状態がクリーンであろうとなかろうと、エラーは発生しません。競合の可能性がないため、作成して切り替えた後、新しいブランチのウェアハウスエリア、ステージングエリア、ワークエリアの内容は作成時のマスターブランチと同じになります。
詳細については、次のセクション (11.5) を参照してください。
11.5 新しいブランチを作成し、このブランチに切り替える
$ git checkout –b dev
これは、次の 2 つのコマンドを実行するのと同じです。
$ git branch dev //创建新分支dev
$ git checkout dev //切换到分支dev
ブランチを表示する場合、「*」が付いたブランチは現在のブランチを示します。
スイッチの作成前にステージング領域とワークスペースがクリーンな場合 (最新バージョンと比較して変更なし)、スイッチの作成前のワークスペースもクリーンです。
しかし、切り替える前のワークスペースがクリーンな状態ではない場合はどうなるのでしょうか?
スイッチ作成時の新しいブランチとマスター ブランチのワークスペースのステータスが同じであることがわかります。
セクション 11.4 で述べたように、通常にブランチを切り替えるとき (作成や切り替えとは異なります)、ステージング領域内のファイルが最新バージョンで追跡されているファイルでない場合、切り替え後に削除されます。
では、作成して切り替えた場合、同じ状況にどのように対処すればよいでしょうか?
作成して切り替えると、新しいブランチのウェアハウス、ステージング領域、ワークスペースの内容は同じであるため、安全であり、ファイルが失われることはないことがわかります。
ただし、ここで特に注意していただきたいのは、切り替える場合でも、作成して切り替える場合でも、変更されたコンテンツを操作しないようにしてください。異なるブランチの機能とタスクは異なるため、このブランチで変更した内容はこのブランチに送信する必要があります。別のブランチに切り替えると、他のブランチでの変更により、前のブランチでの変更が破棄されます。別のブランチに送信した場合でも、前のブランチの一時保存領域は空になり、以前の変更はこのブランチには影響しません。
したがって、ブランチを切り替える前にすべての変更に対処する習慣を身に付けることをお勧めします。そうしないと、大きな問題が発生する可能性があります。
11.6 保管
作業中には、次の 2 つの状況が発生する可能性があります。
1. 特定のブランチの変更が途中までしか完了していないため、送信記録が乱雑になるのを避けるため、まだ送信したくない場合があります。ただし、現時点では早急に修正する必要があるバグがあるか、コードの別の部分を別のブランチに記述したい場合があります。
2. dev ブランチに書かれるべきコードが master ブランチに書かれていました。dev ブランチに移動して書き直すのではなく、master ブランチに書き込まれた変更を dev ブランチに移動します。
何か方法はありますか？本当にそうなのです。魔法のストレージ機能を見てみましょう。
11.6.1 現在のワークサイトの保存
$ git stash //储藏当前工作现场，不加注释
$ git stash save "注释内容" //储藏当前工作现场，带注释
11.6.2 既存のストレージの表示
$ git stash list //查看现有的储藏
11.6.3 特定の保存項目と現在の内容との差分を確認する
$ git stash show //查看最近的储藏与当前内容的改动概况
$ git stash show -p //查看最近的储藏与当前内容的具体改动
$ git stash show stash@{0} -p //查看编号为0的储藏与当前内容的具体改动
11.6.4 復旧した作業現場
$ git stash pop stash@{index} //恢复储藏的工作现场，并删除该储藏记录
$ git stash apply stash@{index} //恢复储藏的工作现场，但保留该储藏记录
数値を指定せずに $ git stash Pop を直接使用すると、最新の stash レコードが復元されます。
注: 番号は変更されるため、どのストレージであるかを判断するためにストレージ番号を使用しないでください。保存されているブランチとコメントに基づいて判断してください。
11.6.5 保存されたワークサイトの削除
$ git stash drop stash@{index} //删除储藏的工作现场
番号を指定せずに $ git stash Drop を直接使用すると、最新の stash レコードが削除されます。
11.6.6 リポジトリからの新しいブランチの作成
$ git stash branch newbranch
注: 番号は変更されるため、どのストレージであるかを判断するためにストレージ番号を使用しないでください。保存されているブランチとコメントに基づいて判断してください。
11.7 異なるブランチの内容は独立しています
1 つのブランチに加えられた変更は、現在のブランチにのみ有効であり、他のブランチには影響しません。
各ブランチの変更はそのブランチに固有です。変更をマスター ブランチに適用する場合、またはマスター ブランチの変更を現在のブランチに更新する場合は、ブランチのマージを使用する必要があります。詳細については、次の 2 つのセクションを参照してください。
各ブランチの送信レコードについては、最初に作成されたときに、その時点のマスター ブランチのすべての送信レコードが含まれます。ただし、その前に、master ブランチと各小さなブランチによって追加されたコミット レコードは、各ブランチの変更にマージされない限り共有されません。
11.8 現在のブランチに他のブランチをマージする
$ git merge dev
dev ブランチを現在のブランチにマージします。現在のブランチは、master ブランチまたは他のブランチにすることができます。
前にも述べたように、分業と協力を目的として新しいブランチを作成しますが、通常、異なるブランチは異なる機能モジュールを担当します。バグを修正したり機能を追加したりするために、新しいブランチが作成されることがあります。いずれの場合も、変更を master ブランチにマージして戻す必要があります。
もう 1 つの状況は、特定のブランチの変更プロセス中に、他のブランチの変更を現在のブランチに更新する必要がある場合です。
たとえば、特定のブランチの変更プロセス中に、メイン ブランチの変更を現在のブランチに更新する必要がある場合、メイン ブランチを現在のブランチにマージする必要があります。
注: 複数人による共同開発のプロセスで、master ブランチ上の他のプログラマの変更を現在のブランチに更新したい場合は、まずリモート ウェアハウスにある master ブランチの最新バージョンをローカル ウェアハウスに取得する必要があります。 、それをマージします。
複数人でのコラボレーションで変更をリモート ウェアハウスにプッシュする場合は、まず最新のマスター バージョンを取得し、次に現在のブランチで変更をマージし、最後にリモート ウェアハウスにプッシュする必要があります。それ以外の場合は、ローカル マスター ブランチ バージョンリモート ウェアハウスのマスター ブランチのバージョンよりも大きくなります。古いためプッシュできません。
上記の合併はすべて理想的でスムーズですが、そうでない場合もあります。
前回の合併は一方の当事者のみが変更を行った場合にのみ実行されたため、両方の当事者が変更を行った場合はどうなるでしょうか?
11.9 ブランチをマージする際の競合の解決
双方が同じファイルの異なる部分を変更した場合はどうなりますか?
そこで問題は、両者が同じファイルの同じ場所に変更を加えた場合はどうなるかということです。
ご覧のとおり、マージは実際に競合しています。ただし、マージは完了しましたが、送信されていない競合があることに注意してください。つまり、master ブランチは、競合するsource1.c の内容を含む dev ブランチの内容をマージしました。
では、競合するsource1.cがマージされるとどうなるでしょうか?
競合を処理する方法は、両側の変更を保持し、固定識別子を使用して異なるブランチの変更をマークすることであることがわかります。
「<<<<<<< HEAD」は現在のブランチを表します。メイン ブランチである必要はありません。
「=======」は区切り文字です。
「>>>>>>>> dev」: dev ブランチを表します。これは現在のブランチに相対的なものです。ブランチは他のブランチです
この時点で送信しても間違いはありませんが、内容は確実に希望通りではありません。ファイル内の競合部分には 2 つのブランチの変更が含まれるため、ブランチ識別子と区切り文字も含まれます。
これがプログラムだったら、コンパイルは間違いなく失敗します。
したがって、送信する前に、まず競合を解決する必要があります。同じ場所で、両方のブランチが変更を行っているため、2 つの変更のうち 1 つを選択し、それらの固定識別子を削除する必要があります。
明らかに、マシンはどの変更を保持したいかわからないため、これは手動でのみ解決できます。
解決策 1: ディレクトリに移動し、source1.c を開いて編集します。
競合が発生した場合に、dev ブランチの変更を選択した場合。次に、上の取り消し線の部分を削除して保存します。
これは変更されたコンテンツです。ステージング領域に追加して送信します。
解決策 2: GIT のコマンド ウィンドウで、vi または vim エディターで開いて編集します。
$ vim source1.c 或 $ vi source1.c
コマンドの実行後、vim (または vi) エディターは、source1.c のウィンドウを開きます。これは、上に示したように、vim エディターの通常モードです。
「i」をクリックすると、上に示すように、vim エディターは挿入モード (編集可能) に入ります。
編集後、「Esc」をクリックすると通常モードに戻ります。次に、英語の文字「:」を入力してコマンドモードに入ります。wq (write Quit) と入力して保存して終了し、ステージング領域に追加して送信します。
11.A 一般的に使用されるマージ方法
11.A.1 --ff与–no-ff
$ git merge --ff dev //使用“Fast forward”（快进）模式合并，默认的，可以不写
$ git merge --no-ff dev //禁用快进模式
通常、ブランチをマージする場合、git は通常「早送り」モードを使用します。このモードでは、ブランチの変更のみがマージされます。つまり、マージされたブランチのコミット レコードがマージされ、最新バージョンを指す HEAD がマージされたブランチの最新のコミット レコードを指します。このプロセス中にコミットは作成されませんが、HEAD はマージされた最新のコミット レコードを指します。
たとえば、master ブランチにコミット レコードが 2 つしかない場合は、dev ブランチを作成します。dev を変更して 4 をコミットしたら、それを master ブランチにマージして戻します。
上の図は、dev ブランチが 4 回送信されたことを示しています。最初は、source1.c の内容が 111111111 に変更され、そのたびに数字の行が追加されました。
上の図は、マージ時に -ff (高速転送モード) がデフォルトで使用され、dev ブランチに追加されたコミットをマージし、HEAD が最新のコミットを指すことを示しています。マージ中に新しいコミットは送信されません。
以前のバージョンにロールバックした場合、以前のバージョンはマージされたバージョンの前のバージョンになります。
このことを思い出させる理由は、早送りモードが無効になっている場合、つまり -no-ff の場合、HEAD はマージ中に送信されたバージョンを指すためです。以前のバージョンをロールバックすると、マージされたバージョンではなく、マスターがロールバックされます。マージ前のブランチの最新バージョン。
–no-ff (早送りモードを無効にする) とマージした場合にどのような違いが生じるかを見てみましょう。
おそらく誰でも、その違いがまさに上記のテキストに記載されているとおりであることがわかるでしょう。
ただし、早送りモードには条件があることに注意してください。つまり、ブランチの作成時と比較すると、マージされたブランチのみが変更され、現在のブランチは変更されていません。
マージ前に現在のブランチに変更があり、依然として -ff (早送りモード) を指定した場合はどうなりますか?
両側に変更がある場合、-ff (早送りモード) を指定してマージしても無駄であることがわかります。システムは依然として -no-ff (早送りモードの無効化) を使用してマージします。
つまり、早送りモードは、マージされたブランチに一方的な変更があった場合にのみ有効であり、-ff および -no-ff を使用するのが合理的です。それ以外の場合、どちらを指定しても、システムはマージに –no-ff モードを使用します。
現在のブランチに変更があるかどうかに関係なく、マージには –no-ff モードを使用することをお勧めします。次の 2 つの利点があります: 1. マージ中に
新しい送信が行われます (もちろん、競合がある場合) , システムは自動的にそれを送信しないため、競合を手動で解決する必要があります。手動で送信)、コメントまたはグラフ モード ($ git log -graph) を見ると、このバージョンが後でマージされたことがわかります。
2. バージョンのロールバック ルートがよりクリーンになり、ブランチ内の乱雑なコミット レコードを心配する必要がなくなります。マージはバージョンであり、以前のバージョンのロールバックはマージ前のバージョンです。
11.A.2 -- スカッシュとリベース
上記のマージから、-ff モードでも -no-ff モードでも、マージ後はマージされたブランチのコミット レコードがメイン ブランチのコミット レコードに統合されることがわかります。マージされたブランチのコミット レコードが非常に汚い場合、メイン ブランチのコミット レコードもマージ後に非常に汚くなります。
マージ後にメイン ブランチにコミット レコードを 1 つだけ増やす方法はありますか?
はい、次の 2 つの方法を試してください。
11.A.2.1 --スカッシュ
マージの際、マージされたブランチの送信レコードはマージされず、マージされたブランチの最終変更のみが現在のブランチのワークスペースとステージング領域にマージされます。マージ後は自動的に送信されないため、プログラマが手動で送信する必要があります。
使用方法は –ff および –no-ff と同じです。効果を見てみましょう:
マージ後、master ブランチの送信レコードが dev ブランチの送信レコードに統合されていないことがわかります。また、システムはマージされたバージョンの送信を自動的に開始しません。
したがって、マージ後にバージョンを手動で送信するか、送信する前に適切な変更を加えることができます。
しかし、別の問題があります。それは、マスターの送信レコードには、dev ブランチの変更とマージの痕跡が見られないということです。dev によって送信された履歴バージョンはなく、どのバージョンが dev ブランチのマージされた変更であるかわかりません。
これは良くないようです。解決する方法はありますか?
はい、実際にはまだこのように行うことができます。次のセクションを参照してください。
11.A.2.2 リベース
Rebase は、特定の線形送信履歴を編集、削除、コピー、貼り付け、マージできるため、rebase コマンドを適切に使用すると、送信履歴をクリーンで簡潔にすることができます。
したがって、ブランチをマージする前に、リベースを使用して、マージされたブランチのコミット レコードを、大きな変更を加えた 1 つまたは複数に派生できます。
通常は1つに合成することができます。
たとえば、source1.c ファイルを一方的に変更して 3 回送信する dev ブランチを作成します。
一般的なマージ方法を使用する場合:
方法 1.$ git merge dev (詳細は 11.8.1 を参照)
master ブランチは変更されておらず、すべてが早送り (-ff) モードでマージされ、3 つのコミット レコードが追加されます。 master ブランチのコミット レコード、つまり dev ブランチによって送信された 3 つです。
方法 2.$ git merge --no-ff dev (詳細は 11.A.1 を参照)
早送り (-no-ff) モードがマージされるように指定されているため、マスター ブランチのコミット レコードを除くすべてのコミット レコードがマージされます。 dev ブランチに追加 3 つのレコードと 1 つの新しいレコードが送信され、合計 4 つのレコードが追加されます。
方法 3.$ git merge --squash dev (詳細は 11.A.2.1 を参照)
マージ後は自動レコード送信は行われないので、手動でレコードを送信できます。ただし、備考に明確に記載されていない限り、master ブランチの送信記録には dev ブランチの変更やマージの痕跡はありません。
それでは、次のようにするとどうなるかを見てみましょう。
dev ブランチは 3 回変更され、送信されました。これら 3 つのコミットを 1 つに結合し、派生したコミットをメイン ブランチにマージしたいと考えています。次に、master ブランチのコミット レコードで、マージされたレコードは、dev ブランチによって変更および送信されたことを明確に示します。
まず rebase コマンドを実行し、現在の master ブランチをベースラインとして指定します。つまり、master ブランチ上の変更を同期してから、このベンチマーク上の開発変更レコードを編集します。
つまり、dev ブランチが確立された後の master ブランチの変更はマージされます。次に、このベースライン上の現在のブランチのすべてのコミット レコードを編集、削除、コピー、貼り付け、マージします。次に、マージ、つまりリベースを行います。
上記コマンドを実行すると、以下のコマンド編集ウィンドウが表示されます。
- pick: コミットを維持する (省略形: p)
- 言い換え: コミットは保持しますが、コミットのコメントを変更する必要があります (略語: r)
- edit: コミットは保持しますが、コミットを停止して (コメントだけでなく) 変更したい (省略形: e)
- squash: このコミットを前のコミットとマージします (省略形: s)
- 修正: このコミットを前のコミットとマージしますが、コミットのコメント情報を保持したくありません (省略形: f)
- exec: シェルコマンドの実行(略称:x)
- Drop: このコミットをドロップしたい (略称: d)
これを 1 つの送信レコードに派生させたいので、送信レコードは 1 つだけ存在できます。つまり、1 つを残して (選択し)、スカッシュを使用して他のレコードをマージします。
最初のコミット レコードを保持し (squash は前のレコードとマージされるため、最初のコミット レコードを保持し、残りには squash を使用できます)、squash を使用して残りをマージします。
コマンドを編集し、保存して終了すると、システムは 3 つの送信を 1 つずつ処理します。
1. 最初の送信を、この時点で master ブランチから同期されている変更とマージします
。 2. 2 番目の送信を上記の結果とマージします
。 3. マージします。 3 番目の送信コミットは上記の結果とマージされます
上記の各ステップで、競合がチェックされます。
提出物が保留される場合（ピックなど）、備考の修正も求められます。
最初のレコードが最初に処理され、まず競合がチェックされます。
矛盾がない場合は、このレコード送信のメモ編集ウィンドウに入ります。
最初に各レコードの競合がチェックされ、競合がない場合はメモ編集ウィンドウに入ります。競合がある場合は停止し、競合を手動で解決できるようになります。競合を解決した後、手動で追加する必要があり (git add)、続行し (git rebase --contiune)、レコードのメモの編集ウィンドウに入ります。追加後にコミットする必要はなく、続行するだけであることに注意してください。保存して終了したら、次のレコードのマージを開始します。
下の写真は4番目のレコードを編集するためのメモです。
関連するコメントを変更します (最後のコメントを編集するときに、すべてのコメントを変更しても問題ありません)。下の図は最後のノート編集ウィンドウを示しており、保存して終了するとリベースは完了です。提案を完了する前に、このリベース送信のメモとして先頭にメモを追加してください。送信レコードを 1 行で表示すると (git log --pretty=oneline)、最初のレコードが表示されます。一般的なコメントを前に追加しない場合、それを 1 行で表示すると (git log --pretty=oneline)、最初のコミット レコードのコメントが表示されます (行を追加: 22222)。不適切。
先ほどは提出レコードを 1 つだけ保持 (選択) したため、提出のコメントは 1 回だけ編集することに注意してください。複数の提出記録 (ピックなど) を保持している場合、このステップが複数回繰り返され、提出ごとにメモが書き込まれます。もちろん、プロセス中に特定の送信が競合した場合は停止しますが、解決、追加、続行した後は、次の送信のためのメモの編集ウィンドウが引き続きポップアップ表示されます。
rebase が成功すると、以下のメッセージが表示され、rebase コマンドは完了です。
マージして見てみましょう。
すべての変更がマージされ、マスター ブランチに追加された送信レコードは 1 つだけです。このレコードは、変更送信の「作成者」も示します。
上記はdev側の一方的な変更で行われましたが、masterブランチにも変更があった場合はどうなるでしょうか？
明らかに、マージ後はそれ以上の記録はありません。さらに、提出記録はロールバックライン上にありませんが、これに慣れていない友人もいます。
解決する方法はありますか？
はい、3 つの方法があります:
1. まず、dev のすべての変更と提出の記録を 1 つに結合します (マスターをベースとして使用しないでください。そうしないと、内容が競合すると非常に面倒になります。dev の変更と提出が増えるほど、さらに面倒になります)、 git rebase -i master を使用して変更を master ブランチに同期し、最後にそれらを master ブランチにマージします。
2. まず、master の変更を dev ブランチにマージし、次に dev ブランチの変更コミット レコードを 1 つにマージし、最後にそれらを master にマージします。現時点でのマージは早送りモードで実行できます。新しいレコードは送信されません。開発リベースの送信されたレコードのみがマージされます。
3. まず、dev のすべての変更送信レコードを 1 つにマージし、次に master ブランチの変更をマージします。双方が変更を行っているため、このマージでは間違いなく新しいコミット レコードが追加され、すべてを 1 つにリベースし、最終的にマスター ブランチにマージし直す必要があります。(推奨されません)
方法 1 を使用することをお勧めします。リベースされたバージョン (git ログ情報) には、開発の変更の追跡のみが含まれます。
方法 2 も可能ですが、リベースされたバージョンにはマスターをマージした痕跡が残ります (最後のコミット レコードはマスターをマージしています)。
方法 3 は少し愚かで、面倒なだけでなく、マスターをマージした跡が残るため、お勧めできません。
方法 1 を以下に示します。
11.A ブランチの削除
11.A.1 ローカル倉庫のブランチを削除する
$ git branch –d 分支名称 （如果该分支没有被合并，会出错并提示：The branch '***' is not fully merged.）
$ git branch –D 分支名称（强制删除分支）
11.A.2 リモート倉庫のブランチを削除する
$ git push origin --delete 分支名称
12. リモート倉庫へのプッシュ
12.1 ローカル ブランチの更新をリモート ホストにプッシュする
$ git push <远程仓库名> <本地分支名>:<远程分支名> （与git pull命令相仿）
ブランチのプッシュ順序は <source>:<destination> として記述されるため、git pull は <リモート ブランチ>:<ローカル ブランチ>、git Push は <ローカル ブランチ>:<リモート ブランチ> となることに注意してください。
リモート ブランチ名が省略された場合は、ローカル ブランチが「追跡関係」を持つリモート ブランチにプッシュされることを意味します (通常、両方とも同じ名前を持ちます)。リモート ブランチが存在しない場合は、作成した。
ローカル ブランチ名を省略した場合、指定されたリモート ブランチが削除されることを意味します。これは、空のローカル ブランチをリモート ブランチにプッシュするのと同じためです。
$ git push origin :master
に相当
$ git push origin --delete master
現在のブランチに追跡ブランチが 1 つだけある場合は、ホスト名を省略できます。
$ git push
例: 現在の master ブランチをリモート ライブラリにプッシュします。
$ git push –u(第一次要用-u 以后不需要) origin master
リモート ライブラリは空なので、最初にマスター ブランチをプッシュするときに、-u パラメーターを追加します。Git はローカルのマスター ブランチのコンテンツをリモートの新しいマスター ブランチにプッシュするだけでなく、ローカルのマスター ブランチをmaster ブランチを関連付けることにより、将来プッシュまたはプルする際のコマンドを簡素化できます。
上記のコマンドは、ローカルのマスター ブランチを Demo_hub ホストにプッシュし、Demo_hub をデフォルトのホストとして指定します。その後、パラメーターを追加せずに $git Push を使用できます。
12.2 対応するリモート ブランチがあるかどうかに関係なく、すべてのローカル ブランチをリモート ホストにプッシュします
$ git push --all origin
13. リモートからローカルに最新バージョンを取得する
リモート ウェアハウスのバージョンがローカル ウェアハウスのバージョンより新しい場合は、次の 2 つのコマンドを使用してそれをプルできます。
$ git fetch origin master //将远程仓库中master分支的更新拉取到本地，但不合并
$ git pull origin master //将远程仓库中master分支的更新本拉取到本地，而且自动合并
使い方はプッシュと同様ですが、具体的な操作については15.1.3.1項で説明します。
14. バージョンのロールバック
14.1 すべてのコミットの履歴を表示する
$ git log
git log の後に多くのパラメータを追加できます。一般的に使用されるパラメータは次のとおりです:
-p: パッチごとの各更新間の差異を表示します。これは、次の - -stat コマンドよりも完全です。
-stat: 変更されたパッチの統計情報を表示します。各コミットには、変更されたファイル、追加および削除された行数、最後に追加および削除されたすべての行の小計がリストされます –abbrev-commit : SHA-1 の最初の数文字のみが表示されます
。全 40 文字の
–graph: ASCII グラフィックスで表現されたブランチ マージ履歴を表示
–pretty=oneline: 1 行表示、ハッシュ値とコミットの説明のみが表示されます (–online 自体を別の属性として使用することもできます)
-n: 表示n ログ前
14.2 すべてのブランチのすべての操作レコードの表示 (削除されたコミット レコードとリセット操作を含む)
14.3 以前のバージョンにロールバックすると、そのバージョン以降に送信されたバージョンはすべて破棄されます。
DEAD を使用してリカバリ バージョンを指定することも、バージョン ID 番号を使用してリカバリ バージョンを指定することもできます。バージョン ID 番号を使用する場合、コミット レコード (git log) の ID 番号または操作レコード (git reflog) の ID 番号のいずれかを使用できます。
14.3.1 HEAD を使用してリカバリバージョンを指定する
$ git reset --hard HEAD
HEAD: 現在のバージョン
HEAD^: 以前のバージョン
HEAD^^: 以前のバージョン
HEAD~100: 100 番目のバージョン
14.3.2 バージョン ID 番号を使用したバージョンの復元
$ git reset --hard bf5b760d5a18246d516e7fa62853c6c151623e21
リセットを使用して復元すると、ID 番号「ba36bfe75e5d7b3c275acd2f0b7928801bf98fd0」のバージョンがなくなっていることがわかります。
14.4 ファイルを過去のバージョンに復元する
14.4.1 特定のファイルを履歴バージョンに復元し、現在のワークスペースおよび一時記憶領域に上書きして戻す
$ git checkout 7a655ee57a031c4387d38e2a9042ea9411dd881c -- source4.c
14.4.2 ファイルを履歴バージョンに復元し、現在の一時記憶領域に上書きして戻す
$ git reset HEAD -- source1.c
14.5 コミットを元に戻します (このバージョンはマージ タイプではありません)、このバージョンの変更を元に戻しますが、以前のバージョンはすべて保持したい
git revert はコミットを元に戻します。送信前後のコミット記録 ($ git log で表示) と履歴レコード ($ git reflog で表示) が保持され、この取り消しは最新の送信とみなされます。
Git revert は、新しいバージョンを送信し、元に戻す必要があるバージョンの内容を逆に変更することです。バージョンはインクリメントされ、git revert 前に送信されたバージョンには影響しません。
例: 以前に 3 回送信し、最新の送信ではsource5.c を追加しました。後で、source5.c が冗長であることが判明したため、この送信をキャンセルしたいと考えました。
ヒント: 最新のものを元に戻すだけでなく、コミット レコード ($ git log で表示) や履歴レコード ($ git reflog で表示) も元に戻すことができ、操作は同じです。
「:wq」を入力するときは、必ず英語の入力方法に切り替えてください。そうしないと、「:」を入力するとコマンド ウィンドウが白く点滅し、これが中国語と英語の入力方法の問題であることに気づかない可能性があります。他にプロンプトが表示されないため、何が問題であるかわからない場合があります。
完了後、コミットされたバージョンを確認すると、以前に送信されたバージョンはすべて存在しますが、新しいバージョンが作成されていることがわかります。
リセットとの違い:
1. リセットを使用して特定のバージョンに復元すると、このバージョンより新しいバージョンはすべてクリアされます。revert を使用して特定のバージョンの送信をキャンセルすると、以前のすべてのバージョンが保持され、新しいバージョンが作成されます。
2. リセットを使用して特定のバージョンに復元すると、内容はそのバージョンとまったく同じになります。revert を使用して送信の特定のバージョンで行われた変更を元に戻すと、コンテンツは現在のバージョンに基づいて逆に変更されます。例えば、このバージョンではsource5.cを追加して修正していますが、このバージョンを元に戻すと、現在のバージョンではsource5.cが削除されるという内容になります。
ディレクトリを見ると、source5.c が削除されていることがわかります。
最近送信された変更を元に戻したい場合は、次のコマンドを直接使用できます。
$ git revert HEAD //HEAD指向最近一次提交
例: 先ほど、最後の提出を取り消し、その結果、source5.c が削除されました。その後、突然、source5.c がまだ有用であることがわかり、最新の提出の変更を取り消すことができます。というのは、前回の失効を取り消した後、それも提出したので、これも提出記録になります。完了後、この提出記録に基づいて再度提出することができます。
$ git revert の共通パラメータの説明:
$ git revert --no-edit //不启动提交消息编辑器，就是不需要写提交备注
$ git revert -n 或 $ git revert --no-commit //不提交，只是恢复到暂存区
git revert のその他のパラメータについては、公式ドキュメントを参照してください: https://git-scm.com/docs/git-revert
15. 多人数共同開発の3つの方法
今日のプロジェクトはますます大規模になり、機能も増えており、開発チームが必要になっています。複数の開発者が一緒にプロジェクトを開発する場合、どのように協力するのでしょうか?
GitHub で複数人で共同開発する 3 つの方法:
- フォークメソッド
- 組織、チームアプローチ
- パートナーモード
15.1 フォークメソッド
おおよそのプロセス:
1. プロジェクト リーダーは、オリジンと呼ばれるプロジェクトの元のウェアハウスを構築します。
ソース ウェアハウスには 2 つの機能があります:
1. プロジェクトに参加しているさまざまな開発者のコードを要約するため
; 2. 安定したリリース可能なコードを保存するため. ソース ウェアハウスは保護されるべきであり、開発者は直接開発すべきではありません。プロジェクト マネージャーのみが、それに対してより高いレベルの操作を実行できます。
2. 開発者フォークソースリポジトリ
ソース ウェアハウスを直接操作する開発者はいないため、ソース ウェアハウスの確立後、各開発者が行う必要があるのは、ソース ウェアハウスのコピーを日々の開発用のウェアハウスとして「コピー」することです。このコピーはフォークです。
3. フォークされたウェアハウスをローカルにクローン作成する
4. 開発用の機能ブランチを構築する
5. プルリクエストを管理者に送信します
自分が担当する機能を完了した後 (もちろん、プロセス中に何度も開発をマージした可能性があります)、テスト後に問題がないと思われる場合は、管理者に開発ブランチをマージするように依頼できます。自分のウェアハウスをソース ウェアハウスの開発ブランチに移動します。
6. 管理者のテストとマージ
管理者は gitlab にログインし、開発者によってソース リポジトリに対して開始されたプル リクエストを確認しました。管理者が行う必要があることは次のとおりです。
1. 開発者のコードを確認します。
2. ローカル テストで新しいテスト ブランチを作成し、開発者のコードをテストし、それをソース ウェアハウスの開発にマージすることに同意するかどうかを判断します。
上記の 6 つのステップのうち、その多くは前の章で説明されており、その他のフォーク、クローン、およびプル リクエストのステップについては以下で説明します。
15.1.1 フォーク
以下はプロジェクトリーダーが管理する倉庫です。
このウェアハウスはまだ誰もフォーク (コピー) していません。次の開発者 "kejirenshen" がコピー操作を実行します。
フォークが完了すると、プロジェクトは kejirenshen の倉庫で利用できるようになります。
GitHub ウェアハウス リストでは、フォークされたウェアハウスも確認できます。
15.1.2 リモート リポジトリのクローンをローカルに作成する
クローンとは、各ブランチ、提出レコード、およびすべてのファイルを含む、リモート ウェアハウスのウェアハウスをローカル ウェアハウスにコピーすることです。これはゼロからのプロセスであり、通常はコンピューターが変更された場合や、ローカルの倉庫が紛失した場合に行われます。
クローン作成手順:
1. ローカル SSH KEY が github 許可リストに追加されていることを確認します (詳細については、セクション 9.3 を参照してください)。
2. ウェアハウスを保存する場所を右クリックし、Git Base ブラック ボックスを開きます。
3. クローンコマンドを入力します。
コマンドの形式は次のとおりです。
$ git clone <版本库的网址> <本地目录名（可省略）>
のように：
方法一（用SSH协议）：$ git clone [email protected]:wuzulie/Demo_hub.git（速度最快）
方法二（用HTTPS协议）：$ git clone https://github.com/wuzulie/Demo_hub.git
SSH と HTTPS の使用の違い:
- 初心者にとっては、https url を使用してクローンを作成する方が便利です。https url をコピーし、
git Bash の clone コマンドを使用してローカルにクローンを作成します。ただし、コードをフェッチしてプッシュするたびにアカウントとパスワードを入力する必要があります。これもトラブルのhttps方式です。 - SSH URL を使用してクローンを作成するには、クローンを作成する前に SSH キーを構成して追加する必要があるため、SSH URL を使用してクローンを作成する場合は、このプロジェクトの所有者である必要があります。そうしないと、SSH キーを追加できません。また、デフォルトでは、SSH はコードを取得してプッシュするたびにアカウントとパスワードを入力する必要はありません。毎回アカウントとパスワードを入力したい場合は、フェッチとプッシュを個別に設定することもできます。
次に、開発者「wuzulie」がプロジェクトを自分の github リポジトリにフォークしたと仮定し、開発用にローカルでクローンを作成できます。
この時点で、リモート ウェアハウスのクローンが作成され、次の開発を実行できるようになります。
現在のディレクトリ内のファイルの表示 (ls -a) やコミット レコードの表示 (git log) などの操作は必須の手順ではありません。特定の操作の効果を強調したいだけです。
注:
他の人のコンピュータを使用している場合、または自分のコンピュータに GIT のデフォルトのユーザー名を設定していない場合は、さまざまなユーザーからの送信を識別しやすくするために、最初にそれを設定する必要があります。
$ git config --global user.name "wuzulie" //设置用户名为：wuzulie
$ git config --global user.email "[email protected]" //设置用户邮箱为：[email protected]
このパラメーターを使用すると、マシン上のすべての Git ウェアハウスがこの構成を使用することになります。もちろん、特定のウェアハウスに別のユーザー名と電子メールを指定することもできます。構成するときに –global を削除するだけです。 system の場合は、 –system を使用します。
さらに、上記のオリジン/マスターは、デフォルト (つまりクローン作成時) でどのブランチが選択されるかを示します。デフォルトでは、origin/HEAD は、origin/HEAD ->origin/master のように、origin/master ブランチを指します。
デフォルト ブランチとしてマークされたリモート ブランチは、削除または変更できます。
クローンを作成すると、デフォルト ブランチ (デフォルトではマスター) がローカルに自動的に作成されます。他のブランチ (dev など) は自動的には作成されませんが、対応するリモート ブランチ (origin/dev など) はローカルに複製されているため、このブランチを作成して、リモート ブランチ内の対応するブランチを追跡させることができます。
$ git branch dev origin/dev //创建dev分支，同让其跟踪远程的dev分支
$ git checkout -b dev origin/dev //创建并切换到dev分支，同时让其跟踪远程的dev分支
$ git checkout dev //如果你确定有这个远程分支，可以直接切换过去，系统会自己创建、切换和跟踪。
リモート ウェアハウス名は必ずしも原点であるとは限らないことに注意してください。ローカル リポジトリがリモート リポジトリからクローンされた場合、リモート リポジトリ名はデフォルトでorigin になります。ただし、ウェアハウスがクローンされていない場合、この名前はリモート ウェアハウスを追加した後に付けられます (git Remote add xxx)。通常はoriginという名前になりますが、別の名前(myhubなど)に名前を付けるか変更すると、上記コマンドのorigin/devがmyhub/devに変更されます。
上記は、クローン作成を使用して何かをゼロから実現するプロセスですが、ローカル ウェアハウスが既に存在するが、それが最新バージョンではない可能性がある場合でも、クローン作成を使用しますか? 次のセクションを参照してください。
15.1.3 リモートウェアハウスから最新バージョンをプルする
チーム共同開発では、全員がリモート ウェアハウスのコードを常に更新しているため、ローカル バージョンが最新ではない可能性があります。
場合によっては、最新のコード バージョンを取得する必要があります。
- たとえば、私たちが担当する高度なプロセスでは、他人の修正結果を使用する必要があります。
- 別の例として、現在のブランチの変更結果をリモート ウェアハウスにプッシュする場合は、まずリモート ウェアハウスで最新バージョンを取得し、それをローカルで現在のブランチとマージしてからプッシュする必要があります。直接プッシュする場合、他の同僚があなたより前にいくつかのバージョンを更新している可能性が非常に高くなります。現在変更しているバージョンは、現在のリモート ウェアハウスにあるバージョンよりも古いため、プッシュ時にエラーが発生します。強制的にプッシュすると、他の人の変更が上書きされてしまい、大きな問題が発生します。
リモート倉庫から取得する手順を確認してください。
$ git fetch origin master //将远程仓库中master分支的更新拉取到本地，但不合并
$ git pull origin master //将远程仓库中master分支的更新本拉取到本地，而且自动合并
最後にリモート リポジトリがローカルにクローンされて以来、他の同僚が更新バージョンをリモート リポジトリにプッシュしたとします。現時点で、最新バージョンをローカルにプルしたい場合は、上記の 2 つの命令を使用する必要があります。
15.1.3.1 プル
プルの自動マージによって競合が発生し、競合を解決せずにマージをキャンセルしたい場合は、次のコマンドを使用できます。
$ git merge --abort //取消合并
ただし、通常、マージはキャンセルされず、競合が解決され、送信が追加されて、ローカル リポジトリが最新の状態に更新されます。
15.1.3.2 フェッチ
マージする前に、プルされた更新の現在のバージョンへの変更を確認することもできます。
フェッチした後、次の 2 つの方法でマージできます。
1.$ git merge FETCH_HEAD //将FETCH_HEAD指向的版本合并到当前分支
2.$ git merge origin/master //将远程仓库的master分支合并到当前分支
ただし、FETHC_HEAD は必ずしもリモート ウェアハウスのマスター ブランチを指しているわけではありません。
フェッチを理解する鍵は、FETCH_HEAD を理解することです。FETCH_HEAD は、サーバー上の特定のブランチの最新ステータスを指します。
一般に、次の 2 つの状況があります。
1. リモート ブランチが明示的に指定されていない場合、リモート ブランチのマスターがデフォルトの FETCH_HEAD として使用されます。
2. リモート ブランチが指定されている場合は、このリモート ブランチを FETCH_HEAD として使用します。
git fetch を使用するには 4 つの方法があります。
1.$ git fetch
このステップでは実際に 2 つの重要な操作を実行します。
1. すべてのリモート ブランチのローカル リモート ブランチを作成および更新します。
2. 現在のブランチの FETCH_HEAD をリモート サーバーの master ブランチに設定します (上記の最初のケース)。
プッシュとは異なり、フェッチはリモートの「新しく追加された」ブランチを自動的に取得することに注意してください。
2.$ git fetch origin
リモートが原点として手動で指定されることを除いて、上記と同じです。
3.$ git fetch origin master
現在のブランチの FETCH_HEAD をリモート サーバーの master ブランチの最新バージョンに設定します。
このコマンドは、リモート ホストのリモート ブランチが存在するかどうかをテストするために使用することもできます。存在する場合は 0 を返し、存在しない場合は 128 を返し、例外をスローします。
4.$ git fetch origin master:dev
これは、リモート ウェアハウスのマスター ブランチをローカルの dev ブランチに更新しますが、そこに切り替えるわけではないことを意味します。ローカルの dev ブランチが存在しない場合は、自動的に作成されます。
git fetchorigin :dev は、git fetchorigin master:dev
と同等です。
15.1.4 変更してリモートウェアハウスにプッシュするプロセス
プロジェクトのコラボレーションが始まったばかりで、初期バージョンがリモートの倉庫に保存され、各プログラマーが自分の担当部分を開始すると仮定します。
15.1.4.1 xiaming (非標準) の修正と提出
xiaming が変更と送信を完了すると、ローカルの dev ブランチのみが変更されます。この変更をリモート ウェアハウスのマスター ブランチに更新したい場合は、どうすればよいでしょうか?
友人の中には、次のように、dev ブランチの変更を master ブランチにマージしてプッシュアップするだけで、非常に簡単だと言う人もいるかもしれません。プッシュして、リモート ウェアハウスでどのような変更が起こるかを確認してください
。
提出レコードをクリックすると、この提出の詳細を表示できます。
この時点で、修正バージョンの xiaming がリモート ウェアハウスに更新され、他の同僚がそれを表示して使用できるようになります。
上記の動作プロセスは問題ないように見えますが、実際には非常に不規則な動作になります。
1. リモート ウェアハウスの最新バージョンは、プッシュする前にローカルで抽出およびマージされないため、リモート ウェアハウスに新しいバージョンがある場合、エラーが発生します。
2. master ブランチのみがプッシュされ、dev ブランチの関連レコードはプッシュされません。リモート ウェアハウスの dev ブランチのレコードを確認してみましょう。xiaming は
後にこの問題を発見し、補足プッシュを行いました。dev
ブランチのレコードは補足されました。ただし、上記のプッシュ操作は、開発レコードが他の同僚によって更新されていない場合にのみ正常にプッシュアップされることに注意してください。dev ブランチが更新されている場合、プッシュは失敗します。強制的にプッシュすると (git Pushorigin dev --force)、他の同僚の更新が上書きされます。最初にブランチをローカルにプルし、それをマージしてからプッシュする場合を除きます。
つまり、xiaming の変更と新しいバージョンのプッシュの運営は非常に不規則です。では、標準化された業務プロセスはどうあるべきなのでしょうか？次のセクションで xiahua の操作を見てみましょう。
15.1.4.2 xiahua（仕様）の修正と提出
プッシュは成功しました。リモート ウェアハウスの変更を見てみましょう。
要約すると、リモート ウェアハウスを変更および更新する標準的な操作は次のとおりです。
- 1. リモート リポジトリのクローンをローカルに作成します。
- 2. ローカル開発または他のブランチで開発する
- 3. リモート リポジトリから更新を取得し、ローカルの master ブランチにマージします。
- 4. すべてのローカル変更レコードを 1 つのレコードに派生します。
- 5. master ブランチの更新を dev ブランチのリベース レコードと同期します。
- 6. 同期された dev ブランチを master ブランチにマージします。
- 7. マージされた master ブランチと dev ブランチをリモート ウェアハウスにプッシュします
最初のステップはプロジェクトファイルを初めて取得するときに使用され、その後の開発ではステップ 2 ～ 7 が継続的に繰り返されます。
したがって、一般的に使用される命令は次のとおりです。
$ git checkout dev //切换分支
$ git pull origin //拉取远程仓库的更新
$ git rebase -i HEAD~n //编辑最近n条提交记录，一般是衍合成一条
$ git rebase -i master //同步master分支上的更新，并编辑master之外的所有记录
$ git merge dev //合并dev分支到当前（master）分支
$ git push origin master(或dev) //推送master分支和dev分支到远程仓库
15.1.5 プルリクエスト
15.2 パートナー方式
15.2.1 共同作業者の追加
まず、協力して開発する必要があるウェアハウスを開き、「設定」で協力者を追加できます。ユーザー名またはメールアドレスを入力して追加できます。
現在、GitHub の無料個人アカウントのプライベート ライブラリではコラボレーターは 3 人までしか追加できず、さらにコラボレーターを追加したい場合は有料アカウントを使用するか、オープンソースのパブリック ライブラリを使用する必要があります。
[コラボレーターを追加] をクリックすると、招待者にリンクが記載された招待メールが届きます。リンクをクリックすることで承認または拒否できます。
招待者は、下の図の「招待リンクをコピー」をクリックして招待リンクをコピーし、招待者に送信することもできます。招待者は、クリック後にそれを承認または拒否できます。
招待者が同意すると、リポジトリが彼の github リポジトリ リストに追加されます。
15.2.2 コラボレーターのプロセス
以降の開発手順はプルリクエストを使用しない点を除けばフォーク方式と同様ですが、具体的な操作手順については15.1.2～15.1.4を参照してください。
15.3 組織とチームのアプローチ
15.3.1 組織の作成
github の右上隅にある「+」記号をクリックし、「新しい組織」をクリックします。
step1、組織関連情報を入力します。
有料タイプの場合は支払い方法などの入力も必要ですが、無料タイプの場合は入力する必要はありません。
ステップ1が完了したら、ステップ2に進みます。
ステップ 3 では、調査を行います。これは必須ではないため、スキップできます。
この時点で、組織は正常に作成されました。
15.3.2 組織への倉庫の追加と削除
15.3.2.1 組織に倉庫を追加する
15.3.2.2 組織内のリポジトリの削除
倉庫を削除したい場合は、通常の倉庫と同様の方法で削除できます。
次に、ページの一番下までスクロールします。
15.3.3 組織にメンバーを追加する
招待ウィンドウが表示されたら、招待するユーザー名または電子メールを入力します。
このメンバーの役割を設定します。
ユーザーにはURLが添付された招待メールが届き、入力後に承諾または拒否することができます。
相手が承諾すると、以下のようにあなたの組織に参加します。
チームからメンバーを削除したい場合は、上の画像の×印をクリックするだけでさらに簡単です。
15.3.4 組織のチームを作成する
チーム関連の情報を入力します。
作成が成功すると、以下のようになります。
チームが所属する組織を入力して表示することもできます。
チームが多くのタスクを担当する場合は、複数のチームに分割することもできます。例えば、「アビオニクスシステム」チームは、「飛行制御システム」、「表示システム」、「通信システム」、「レーダーシステム」などのチームに分けることもでき、それらはすべて「アビオニクスシステム」チームによって管理されます。 。
サブチームを作成する場合は、作成時に親チームを選択するだけで、その他の手順は上記と変わりません。親チーム内で [新規] をクリックした場合は、親チームを選択する必要さえありません。
15.3.5 チームにリポジトリを追加する
倉庫名を入力します。
15.3.6 チーム権限の設定
5つの権限の説明はすべて英語ですので、わからない場合は翻訳してください。
15.3.7 チームメンバーの追加と削除
15.3.7.1 チームメンバーの追加
次にリマインダーがあります。
追加後、GitHub は追加されたユーザーに通知メールを送信します。ユーザーはすでに組織のメンバーであり、管理者がどのチームを追加するかを決定する権利を持っているため、この追加プロセスには追加される人の同意は必要ありません。
その後、チームとチームのウェアハウスも、追加される人の github ホームページで確認できます。
15.3.7.2 チームメンバーの削除
リマインダーが続きます。
15.3.8 チームメンバーの権限を設定する
前のセクションの方法を使用して、最初にチェックボックスをオンにして、ドロップダウン メニューの [役割の変更] をクリックして権限を設定できます。
メンバーの名前をクリックしてメンバーのページにアクセスしたり、役割、つまり権限を設定したりすることもできます。
権限を変更すると、メンバーに通知メールが届きます。
15.3.9 チーム開発
各メンバーは、自分の github 上でチームのリポジトリを参照でき、リポジトリをローカルに複製して、担当するコードの作成を開始できます。
後は、チームメンバーそれぞれが通常通りに開発を行うことができます。開発プロセスは、プルリクエストが必要ない点を除けば、フォーク方式と同様です。具体的な操作プロセスについては、15.1.2～15.1項を参照してください。 .4。
15.3.A 通信機能について議論する
コンテンツが送信されると、各メンバーに次のようなメールが届きます。
各メンバーは、github チームの「ディスカッション」でもコンテンツを確認でき、ここでディスカッションや交換に参加できます。
もちろん深夜のディナーデートは冗談であり、ここで語られる内容はプロジェクトに関わるものである。WeChat、QQ などを使用してディスカッションを行うこともできますが、ここではいくつかの重要なディスカッションをお勧めします。というのも、ここで議論しておけば、議論の記録はプロジェクトデータとしてウェアハウスごとgithubに保存でき、後から簡単に見ることができるからです。
ここまでで、gitに関する内容はほぼ紹介できました。興味のある友人は、Gitlab について詳しく学ぶことができます。さらに、GitHub DesktopやGitflowなど、git関連の補助ツールソフトウェアについても学ぶことができます。