gitee チュートリアルの詳細な説明 (非常に詳しいので、この記事を読んでください!)

1. git の概要

1 はじめに

Git は現在、世界で最も先進的な分散バージョン管理システムです。オープンソース プロジェクトに無料の Git ストレージを提供しており、jQuery、PHP、Ruby など、無数のオープンソース プロジェクトが GitHub に移行し始めています。

では、バージョン管理システムとは何でしょうか?

バージョン管理システムは、すべてのファイル変更を自動的に記録するだけでなく、他のユーザーが共同で編集できるようにするため、大量の類似したファイルを自分で管理する必要も、ファイルを転送する必要もありません。特定の変更を確認したい場合は、すべてのファイル変更を記録できるソフトウェアで確認するだけです。

何が配布されているのでしょうか？

CVS と SVN はどちらも集中型バージョン管理システムですが、Git は分散型バージョン管理システムです。集中型バージョン管理システムと分散型バージョン管理システムの違いは何ですか?

集中バージョン管理システムでは、バージョン ライブラリは中央サーバーに保存されます。作業するときは自分のコンピュータを使用するため、まず中央サーバーから最新バージョンを取得してから作業を開始し、その後作業を完了する必要があります。コンテンツは中央サーバーにプッシュされます。中央サーバーは図書館のようなもので、本を修正したい場合は、まず図書館で借りて、家に帰って自分で修正し、修正したら図書館に戻します。

集中バージョン管理システムの致命的な問題は、動作するにはインターネットに接続する必要があることです。ローカル エリア ネットワークでは問題ありません。帯域幅は十分に大きく、速度も十分に速いですが、インターネット上では問題ありません。 、ネットワーク速度が遅い場合、10M ファイルを送信するのに 5 分かかることがあります。分、遅すぎます。

そして、分散バージョン管理システムには「中央サーバー」がまったくありません。誰のコンピュータにも完全なバージョン ライブラリがあるため、この方法で作業する場合、バージョン ライブラリは自分のコンピュータ上にあるため、インターネットに接続する必要はありません。誰もが自分のコンピュータ上に完全なリポジトリを持っているのに、複数人で共同作業するにはどうすればよいでしょうか? たとえば、あなたが自分のコンピュータ上のファイル A を変更し、同僚も自分のコンピュータ上のファイル A を変更したとします。このとき、2 人はお互いに変更をプッシュするだけで、お互いの変更を確認できます。(実際に分散バージョン管理システムを使用している場合、2 人の間でコンピュータ上のバージョン ライブラリのリビジョンをプッシュすることはほとんどありません。おそらく 2 人は同じローカル エリア ネットワーク内にいないため、2 台のコンピュータは相互にアクセスできないか、同僚 A が病気で、コンピュータの電源がまったく入っていません。したがって、分散バージョン管理システムには通常、「中央サーバー」として機能するコンピュータもありますが、このサーバーの役割は次のとおりです。全員の変更の「交換」を容易にするためだけであり、それなしでは誰もが同じように機能しますが、交換や変更が不便なだけです。)

集中型バージョン管理システムと比較すると、分散型バージョン管理システムは、全員が自分のコンピュータ上に完全なバージョン ライブラリを持っているため、はるかに安全です。ある人のコンピュータが壊れていても関係ありません。他の人からコピーするだけで済みます。それだけです。また、集中バージョン管理システムの中央サーバーに問題が発生すると、全員が作業できなくなります。

 2. インストール

Git は Linux、Unix、Mac、Windows 上で適切に動作します

(1) LinuxにGitをインストールする

$ git

gitシステムに Git がインストールされているかどうかを確認するには、次のコマンドを入力します。次のコマンドが表示された場合は、インストールされていないことを意味します。

プログラム「git」は現在インストールされていません。
sudo apt-get install gitと入力してインストールできます。

1. 新しいバージョンの Debian または Ubuntu Linux の実行

sudo apt-get install git

2. 古いバージョンの Debian または Ubuntu Linux の実行

sudo apt-get install git-core

3. 他のバージョンは、ソース コードから直接インストールできます。まず、Git 公式 Web サイトからソース コードをダウンロードして解凍し、次のように入力します。 、 と入力すると./config、makeこれらsudo make installのコマンドがインストールされます。

./config

make

sudo make install

(2) Mac OS XにGitをインストールする

最初は homebrew をインストールし、次に homebrew を通じて Git をインストールします。具体的な方法については、homebrew のドキュメントを参照してください: Homebrew — The Missing Package Manager for macOS (or Linux) The Missing Package Manager for macOS (or Linux). http:/ /brew.sh/ 2 番目の方法はより簡単で、推奨される方法は、AppStore から Xcode を直接インストールすることです。Xcode は Git を統合しますが、デフォルトではインストールされません。Xcode を実行し、メニュー「Xcode」->「」を選択する必要があります。「環境設定」を選択し、ポップアップウィンドウ「ダウンロード」で見つけて「コマンドラインツール」を選択し、「インストール」をクリックしてインストールを完了します。

(3) WindowsにGitをインストールする

Windows で Git を使用するには、Git 公式 Web サイトからインストーラーを直接ダウンロードし、デフォルトのオプションに従ってインストールします。

インストールが完了したら、スタート メニューで [Git] -> [Git Bash] を見つけます。コマンド ライン ウィンドウのようなものがポップアップ表示され、Git が正常にインストールされたことが示されます。

 インストールが完了した後も、最後のステップを設定する必要があります。コマンド ラインに次のように入力します。

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

Git は分散バージョン管理システムであるため、各マシンはその名前 (名前と電子メール アドレス) を報告する必要があります。コマンドのパラメータに注意してください。このパラメータを使用すると、マシン上のすべての Git ウェアハウスがこの構成を使用することになります。もちろん、特定のウェアハウスに異なるユーザー名と電子メール アドレスを指定することもできます。git config--global

3. バージョンライブラリを作成する

バージョンライブラリとは何ですか? バージョン ライブラリはウェアハウスとも呼ばれます。単純にディレクトリとして理解できます。このディレクトリ内のすべてのファイルは Git で管理できます。Git は各ファイルの変更と削除を追跡できるため、いつでも履歴を追跡できます、またはいつでも、将来のある時点で「復元」することができます。

(1) まず、適切な場所を選択し、空のディレクトリを作成します。

$ mkdir zxcvgit
$ cd zxcvgit
$ pwd

pwdコマンドはカレントディレクトリを表示するために使用されます。Windows システムを使用する場合は、ディレクトリ名 (親ディレクトリを含む) に漢字が含まれていないことを確認してください。

(2) 2 番目のステップでは、次のgit initコマンドを使用して、このディレクトリを Git で管理できるウェアハウスに変更します。

$ git init

Git はすぐにリポジトリを構築し、それが空のリポジトリ (空の Git リポジトリ) であることを通知します。現在のディレクトリの下に追加の.gitディレクトリがあることがわかります。このディレクトリは、Git がリポジトリを追跡および管理するために使用します。問題がない場合は手動で行わず、このディレクトリ内のファイルを変更してください。変更しないと、変更が台無しになった場合に Git リポジトリが破壊されます。

.gitディレクトリが表示されない場合、そのディレクトリはデフォルトで非表示になっており、ls -ahコマンドで表示できるためです。

 4. ファイルをリポジトリに追加します

すべてのバージョン管理システムは、実際には、TXT ファイル、Web ページ、すべてのプログラム コードなどのテキスト ファイルへの変更のみを追跡できます。Git も例外ではありません。バージョン管理システムは、5 行目に「Linux」という単語を追加したり、8 行目に「Windows」という単語を削除したりするなど、すべての変更を通知できます。写真やビデオなどのバイナリ ファイルもバージョン管理システムで管理できますが、ファイル内の変更を追跡する方法はありません。バイナリ ファイルの各変更をつなぎ合わせるしかありません。画像は100KBから120KBに変更されましたが、結局何が変更されたのか、バージョン管理システムは知りません、そして知ることができません。

残念ながら、Microsoft の Word 形式はバイナリ形式です。そのため、バージョン管理システムは Word ファイルへの変更を追跡できません。バージョン管理システムを実際に使用するには、ファイルをプレーン テキストで記述する必要があります。標準の UTF-8 エンコーディングを使用することを強くお勧めします。すべての言語で同じエンコーディングが使用されるため、競合がなく、すべてのプラットフォームでサポートされています。

Windows を使用する場合は特別な注意を払う必要があります。テキスト ファイルの編集にはWindows 内蔵のメモ帳を決して使用しないでください。その理由は、Web ページの 1 行目に「?」が表示されたり、正しいプログラムがコンパイルされるとすぐに構文エラーが報告されたりするなど、信じられないような問題が数多く発生するためです。メモ帳の精神薄弱な動作による。強力なだけでなく無料であるメモ帳の代わりにVisual Studio Codeをダウンロードすることをお勧めします。

readme.txt(1) 次の内容のファイルを書き込みます。

ダウンストリームコードを実行する

$ vi reademe.txt

 編集モードに入る: i キーを押します。次のように入力します

Git はバージョン管理システムです。
Git はフリーソフトウェアです。

Esc キーを押して編集モードを終了し、通常モードに戻ります。「:mq」と入力して保存して終了します。

zxcvgitこれは Git リポジトリであり、どんなに強力な Git が他の場所に配置されても、このファイルを見つけることができないため、このファイルはディレクトリに配置する必要があります (サブディレクトリも許容されます)  。

(2) ファイルを Git リポジトリに置くには 2 つの手順だけが必要です

1. 最初のステップは、コマンドを使用してファイルをウェアハウスに追加するように Git に指示することです。git add

$ git add readme.txt

上記のコマンドを実行すると何も表示されず、追加が成功したことがわかります。Unixの哲学は「ニュースがないことは良いニュースだ」

Q: と入力するgit add readme.txtとエラーが発生します: fatal: not a git repository (or any of the parent directories)。

A: Git コマンドは Git リポジトリ ディレクトリ内で実行する必要があります (git init例外あり)。リポジトリ ディレクトリ外で実行しても意味がありません。

Q: を入力するgit add readme.txtとエラーが発生しますfatal: pathspec 'readme.txt' did not match any files。

A: ファイルを追加する場合、ファイルはカレントディレクトリに存在する必要がありますので、lsまたはdirコマンドを使用してカレントディレクトリのファイルを確認し、ファイルが存在するか、ファイル名が間違って記述されていないかを確認してください。

Q: と入力するgit add readme.txtとエラーが発生します: fatal: not a git repository (or any of the parent directories)。

A: Git コマンドは Git リポジトリ ディレクトリ内で実行する必要があります (git init例外あり)。リポジトリ ディレクトリ外で実行しても意味がありません。

Q：输入git add readme.txt，得错误警告：readme.txt では LF が CRLF に置き換えられます。ファイルには、作業ディレクトリ内の元の行末が表示されます。

A: $ git config --global core.autocrlf true を実行します (#送信時に LF に変換し、チェックアウト時に CRLF に変換します)

 (2) 2 番目のステップでは、次のコマンドを使用して、ファイルをウェアハウスに送信するように Git に指示します。git commit

$ git commit -m "wrote a readme file"

git commitコマンド-mに続いて、この送信の説明を入力します。任意の内容を入力できます。もちろん、履歴レコードから変更レコードを簡単に見つけられるように、意味のある内容にするのが最善です。

git commitコマンドが正常に実行されると、次のメッセージが表示されます1 file changed: : 1 ファイルが変更されました (新しく追加された readme.txt ファイル); 2 insertions: 2 行のコンテンツが挿入されました (readme.txt には 2 行のコンテンツがあります)。ここには 2 つのファイルがあるため、番号が異なります。

commit一度に多くのファイルを送信できるため、次のaddような異なるファイルを複数回送信できます。

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

Git リポジトリを初期化するには、git initコマンドを使用します。

次の 2 つの手順でファイルを Git リポジトリに追加します。

1. コマンドを使用しますgit add <file>。このコマンドは複数のファイルを追加するために複数回使用できることに注意してください。
2. コマンドを使用してgit commit -m <message>完了します。

2. 前後のバージョン

1. ファイルを変更する

readme.txt ファイルの追加と送信に成功しました。次に、readme.txt ファイルを次の内容に変更します。

Git は分散バージョン管理システムです。
Git はフリーソフトウェアです。

コマンドを実行してgit status結果を確認します。git statusこのコマンドを使用すると、ウェアハウスの現在のステータスを追跡できます。

$ git status

上記のコマンド出力は、readme.txt変更されたことを示していますが、変更を送信する準備がまだ整っていません。

このコマンドを使用してgit diff、どのコンテンツが変更されたかを確認します。 git diff名前が示すように、差分を確認します。表示される形式は Unix の一般的な diff 形式です。次のコマンドの出力から、単語を追加したことがわかりますdistributed。最初の行で。

$ git diff

 変更の送信と新しいファイルの送信は同じ 2 つのステップです。最初のステップは次のとおりですgit add。

$ git add readme.txt

 やはり出力はありません。2 番目のステップを実行する前にgit commit、再度実行してgit status現在のウェアハウスのステータスを確認しましょう。

 git status送信する変更内容に が含まれていることをお知らせくださいreadme.txt。次のステップで、自信を持って送信できます。

送信後、次のgit statusコマンドを使用してウェアハウスの現在のステータスを確認できます。

Git は、現在コミットする必要のある変更がなく、作業ディレクトリがクリーン (作業ツリーがクリーン) であることを示します。

• ワークスペースのステータスを追跡するには、git statusコマンドを使用します。

• git statusファイルが変更されたことが示されている場合は、git diff変更内容を表示できます。

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

ファイルを変更して、その変更を Git リポジトリに送信する方法を学習しました。次に、もう一度練習して、readme.txt ファイルを次のように変更します。

Git は分散バージョン管理システムです。
Git は GPL に基づいて配布されるフリー ソフトウェアです。

次に、送信してみます。

$ git add readme.txt
$ git commit -m "append GPL"

ファイルを継続的に変更し、その変更をバージョン ライブラリに継続的に送信します。RPGゲームをプレイするときと同じように、レベルを通過するたびにゲームのステータスが自動的に保存されます。特定のレベルを通過していない場合は、次のことを選択することもできます。前のレベルのステータスを読み取ります。場合によっては、ボスと戦う前に手動でゲームを保存し、ボスとの戦いに失敗した場合に最も近い場所からやり直すことができます。Git も同様で、ファイルがある程度変更されたと感じたときに「スナップショットを保存」することができます。これを Git ではスナップショットと呼びますcommit。ファイルを壊したり、誤って削除したりしても、commit数か月の作業結果をすべて失うことなく、最新のファイルから復元して作業を続けることができます。

readme.txtファイルのいくつかのバージョンが Git リポジトリに送信されたことを思い出してください。

バージョン 1: Readme ファイルを作成する

Git はバージョン管理システムです。
Git はフリーソフトウェアです。

バージョン 2: 分散を追加

Git は分散バージョン管理システムです。
Git はフリーソフトウェアです。

バージョン 3: GPL を追加

Git は分散バージョン管理システムです。Git はGPL に基づいて配布される
フリー ソフトウェアです。

実際の作業では、何千行ものファイルで何が変更されたかを毎回覚えておくことは不可能です。Git では、git log履歴を表示するコマンドを使用します。git logこのコマンドは、コミット ログを最新のものから最も遠いものまで表示します。最新のもの、append GPL以前のもの、最も古いものadd distributed、の3 つのコミットが表示されますwrote a readme file。

 出力情報が乱雑すぎると思われる場合は、--pretty=onelineパラメーターを追加してみてください。

私が見ているのは52f3ad03...、一連の類似したものcommit id(バージョン番号)です。SVN とは異なり、Git はcommit id1、2、3... という増加する数字ではなく、SHA1 によって計算された16 進数の非常に大きな数字です。見てくださいcommit id、私とは決定的に異なります、あなた自身のものが優先されます。それを表すためになぜcommit idこれほど大きな一連の数値を使用する必要があるのでしょうか? Git は分散バージョン管理システムであり、複数の人が同じバージョン ライブラリで作業するため、全員がバージョン番号として 1、2、3... を使用すると、必ず競合が発生します。新しいバージョンが送信されるたびに、Git は実際にそれらをタイムラインに自動的につなぎ合わせます。ビジュアル ツールを使用して Git 履歴を表示すると、コミット履歴のタイムラインをより明確に確認できます。

readme.txt以前のバージョン、つまり のadd distributedバージョンにロールバックしたいのですが、どうすればよいですか?

まず第一に、Git は現在のバージョンがどのバージョンであるかを知る必要があります。Gitでは、は最新の送信である現在のバージョン(私の送信 ID はあなたのものとは明らかに異なることに注意してください)、前のバージョンは、および前のバージョンHEADを表しますもちろん、 100 を超えるバージョンを 100 個書くとカウントを失いやすくなるため、 と書かれています。52f3ad...HEAD^HEAD^^^HEAD~100

append GPL現在のバージョンを以前のバージョンにロールバックしたい場合は、次のコマンドをadd distributed使用できます。git reset

$ git reset --hard HEAD^

 --hardパラメータは何を意味しますか? 後ほどお話しますが、これで安心してご利用いただけます。

cat readme.txtコマンドは、コンテンツが次のバージョンであるかどうかを確認しますreadme.txtadd distributed。

$ cat readme.txt

確かに復元されていました。git logリポジトリの現在の状態をもう一度見てみましょう。

最新バージョンはappend GPLもう入手できません。戻りたくても戻れない、どうすればいいですか？実際、まだ方法はあります。上記のコマンド ライン ウィンドウが閉じていない限り、検索して見つけることができるため、append GPLcommit id52f3ad03...将来特定のバージョンに戻るように指定できます。

$ git reset --hard 52f3a

バージョン番号全体を書き留める必要はなく、最初の数桁だけを書き留めておくと、Git が自動的に検索します。もちろん、最初の 1 つか 2 つだけを書くことはできません。Git は複数のバージョン番号を見つけて、それがどれであるかを判断できない可能性があるからです。もう一度チェックしておきたいことreadme.txt:

ハハハ、私、胡漢山がまた戻ってきました。

Git のバージョンのロールバックは非常に高速です。Gitには現在のバージョンへの内部ポインターがあるためですHEAD。バージョンをロールバックするappend GPLadd distributed,と、Git は HEAD のポイントをポイントからポイントに変更し、ワークスペース内のファイルを更新するだけです。したがって、どのバージョン番号をHEAD指定しても、現在のバージョンを見つけることができます。

------->>>

 では、特定のバージョンに戻し、コンピューターの電源を切り、新しいバージョンに復元したい場合はどうすればよいでしょうか? 新しいバージョンが見つからない場合はどうすればよいですかcommit id? $ git reset --hard HEAD^あるバージョンにロールバックしadd distributed、再度復元する場合はappend GPL、append GPLコミット ID を見つける必要があります。git reflogGit には、各コマンドを記録するためのコマンドが用意されています。

$ git reflog

 出力からわかるように、append GPLコミット ID は です52f3ad0。これで、最新バージョンに戻ることができます。

• HEAD指定されているバージョンは現在のバージョンです。Git では、コマンドを使用してバージョン履歴間を行き来できます。git reset --hard commit_id

• シャトルする前に、ユーザーはgit logコミット履歴を表示して、どのバージョンにロールバックするかを決定できます。

• 未来に戻るには、git reflogコマンド履歴を使用して、どのバージョンの未来に戻りたいかを決定します。

3. 作業エリアおよび一時保管エリア

Gitと SVN などの他のバージョン管理システムの違いの 1 つは、ステージング領域の概念です。作業ディレクトリは、コンピュータ上で表示されるディレクトリです。たとえば、私のzxcvgitフォルダはワークスペースです。ワークスペースに隠しディレクトリがあります.git。これはワークスペースではなく、Git リポジトリです。Git リポジトリには多くのものが保存されていますが、その中で最も重要なものは、stage (またはindex) と呼ばれる一時保存領域、 Git が自動的に作成する最初のブランチmaster、およびと呼ばれるmasterそれへのポインタHEADです。

 前述したように、Git リポジトリにファイルを追加するときは、次の 2 つの手順で行います。

最初のステップはgit addファイルを追加することです。これは実際にはファイルの変更を一時記憶域に追加することを意味します。

2 番目のステップはgit commit変更をコミットすることです。これにより、ステージング領域のすべての内容が現在のブランチに実際にコミットされます。

Git リポジトリを作成すると、Git が自動的に一意のmasterブランチを作成してくれたので、後はそのブランチに変更をコミットするgit commitだけです。master簡単に理解すると、送信する必要があるすべてのファイル変更は一時記憶領域に配置され、その後、一時記憶領域内のすべての変更が一度に送信されます。

実践は真の知識をもたらします。ここで、もう一度練習して、readme.txtコンテンツ行を追加するなど、最初に変更を加えてみましょう。

Git は分散バージョン管理システムです。
Git は GPL に基づいて配布されるフリー ソフトウェアです。
Git には stage と呼ばれる可変インデックスがあります。 

次に、ワークスペースに新しいテキスト ファイルを追加しますLICENSE(内容は自由に記述します)。

まず次のgit statusコマンドでステータスを確認します。

readme.txtGit は、変更されたこと は明確に示しますが、LICENSE追加されていないため、ステータスは ですUntracked。ここで、コマンドを 2 回使用しgit add、readme.txt両方の合計LICENSEを追加してgit status再度確認します。

 これで、ステージング領域のステータスは次のようになります。

 したがって、git addこのコマンドは実際には、送信されるすべての変更をステージング領域 (Stage) に入れてから実行し、git commitステージング領域内のすべての変更を一度にブランチに送信します。

 送信後、ワークスペースに何も変更を加えていない場合、ワークスペースは「クリーン」になります。

 リポジトリは次のようになり、ステージング領域にはコンテンツがありません。

ステージング領域は Git の非常に重要な概念であり、ステージング領域を理解すると、Git の多くの操作が何を行うのかが理解できるようになります。ステージング領域で何が起こっているのか理解できない場合は、上にスクロールしてもう一度見てください。

4. 管理の変更

次に、Git が他のバージョン管理システムよりも優れた設計である理由について説明します。Gitはファイルではなく変更を追跡および管理するためです。修正とは何ですか? たとえば、新しい行を追加した場合も変更、行を削除した場合も変更、一部の文字を変更した場合も変更、一部を削除して追加した場合も変更となります。新しいファイルを作成することさえカウントされます。Git はファイルではなく変更を管理すると言われているのはなぜですか? 実験をしてみましょう。

最初のステップは、次のような行を追加するなど、 readme.txt を変更してから、次の内容を追加することです。

Git は分散バージョン管理システムです。
Git は GPL に基づいて配布されるフリー ソフトウェアです。
Git には stage と呼ばれる可変インデックスがあります。
Git は変更を追跡します。

 次に、readme.txt を変更して送信します。

Git は分散バージョン管理システムです。
Git は GPL に基づいて配布されるフリー ソフトウェアです。
Git には stage と呼ばれる可変インデックスがあります。
Git はファイルの変更を追跡します。

 2 回目の修正案が提出されなかったのはなぜですか? 操作プロセスを確認してみましょう。

1回目の変更 ->  git add -> 2回目の変更 -> git commit

Git は変更を管理します。コマンドを使用するとgit add、ワークスペース内の最初の変更は一時記憶域に置かれ、送信できる状態になります。ただし、ワークスペース内の2 番目の変更は一時記憶域に置かれないため、git commitは、変更を一時記憶領域に送信することのみを担当します。つまり、最初の変更は送信され、2 番目の変更は送信されません。

送信後、次のgit diff HEAD -- readme.txtコマンドを使用して、ワークスペースとリポジトリの最新バージョンの違いを表示できます。

 2 番目の修正が提出されていないことがわかります。では、2 回目の改訂版はどのように提出すればよいのでしょうか? 続行することgit addgit commitも、最初の変更を急いで送信することもできませんが、最初にgit add2 番目の変更を変更してから、git commit2 つの変更をマージして一緒に送信することと同じです。

1 回目の変更 ->  git add -> 2 回目の変更 ->  git add -> git commit

変更が行われるたびに、git add一時記憶領域に移動しないと、変更は追加されませんcommit。

5. 変更を元に戻す

没有git addステージングエリアへ:

当然、間違いを犯すことはできません。しかし、午前 2 時、仕事の報告に急いでいるときに、readme.txt次の行を追加します。

$ vi readme.txt

Git は分散バージョン管理システムです。
Git は GPL に基づいて配布されるフリー ソフトウェアです。
Git には stage と呼ばれる可変インデックスがあります。
Git はファイルの変更を追跡します。
私の愚かな上司は依然として SVN を好みます。

コミットの準備が整う前に、エラーはすぐに発見されたため、簡単に修正できることに突然気づきました (最後の行を削除し、ファイルを手動で以前のバージョンに復元できます)。使用する場合はgit status、次のことを確認してください。

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git checkout -- fileGit では、ワークスペース内の変更を破棄してもよいことがわかります。

$ git checkout -- readme.txt

このコマンドの意味は、ワークスペース内のファイルに対するすべての変更を元に戻すことです。ここには 2 つの状況があります。1git checkout -- readme.txtつは、変更以降、ファイルが一時記憶領域に配置されていない場合です。ここで、変更を元に戻すと、同じ状態に戻ります。バージョン ライブラリとしての状態; 1 つ目は、ステージング領域に追加された後に変更が加えられているため、変更を元に戻すとステージング領域に追加した後の状態に戻ります。簡単に言うと、ファイルを最新の状態に戻すことです。readme.txtreadme.txtreadme.txtgit commitgit add

次に、readme.txtファイルの内容を見てみましょう。

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

ファイルの内容は確かに復元されました。

git checkout -- fileコマンド内の「」は--非常に重要です。そうでないと「別のブランチへの切り替え」コマンドになります。以降のブランチ管理で再びこのコマンドに--遭遇します。git checkout

 git addステージングエリアに到着しました:

今は午前 3 時だとします。あなたは、くだらないことを書いただけでなく、git add一時保管場所にも行きました。幸いなことに、commitあなたはこの問題を以前に発見していました。見てみるgit statusと、変更はステージング領域に追加されただけで、まだ送信されていないことがわかります。

 Git では、コマンドを使用してgit reset HEAD <file>ステージング領域の変更をステージング解除し、それらをワークスペースに戻すgit resetことができます。このコマンドにより、バージョンをロールバックしたり、ステージング領域の変更をワークスペースにロールバックしたりできます。これを使用する場合HEAD、それは最新バージョンを意味します。もう一度確認してくださいgit status。これで、一時記憶域がクリーンになり、ワークスペースが変更されました。

ワークスペースの変更を破棄する方法を覚えていますか? ようやく全世界が平和になりました！ 

 

 間違ったものを修正するだけでなく、一時保存領域からリポジトリに送信した場合、どうすればよいでしょうか? バージョンのロールバックに関するセクションをまだ覚えていますか? 以前のバージョンにロールバックできます。ただし、これは条件付きです。つまり、ローカル バージョンのライブラリをリモートにプッシュしていないということです。Git が分散バージョン管理システムであることを覚えていますか? リモートリポジトリについては後述しますが、リモートリポジトリに送信をプッシュするとstupid boss本当に悲惨なことになります…。

シナリオ 1: ワークスペース内のファイルの内容を変更し、ワークスペース内の変更を直接破棄したい場合は、コマンドを使用しますgit checkout -- file。

シナリオ 2: ワークスペース内のファイルの内容を変更するだけでなく、そのファイルを一時記憶域にも追加し、その変更を破棄する場合は、2 つのステップで行う必要があります。最初のステップは、 2 番目のステップは、シーン 1 の操作を押すことですgit reset HEAD <file>。

シナリオ 3: 不適切な変更がリポジトリに送信されており、この送信を取り消したい場合は、バージョンのロールバックのセクションを参照してください。ただし、リモート リポジトリにプッシュされていないことが前提となります。

注意深い読者は、picture git prompt コマンドが異なることに気づくでしょう。以下は新しいバージョンのコマンドです。

新しいバージョン

• ケース 1: ファイルはワークスペース内でのみ操作され、追加されません。操作を元に戻す: git list <ファイル>。結果: ワークスペース ファイルはロールバックされます。
• ケース 2: ファイルは追加されましたが、コミットされていません。操作を元に戻す: git list --staged <ファイル>。結果: 一時記憶領域のファイルはロールバックされますが、作業領域のファイルはロールバックされません。引き続きロールバックする必要がある場合は、ケース 1 に従って操作してください。
• ケース 3: ファイルが追加され、コミットされました。操作を元に戻す: git restart --hard commit_id。結果: ワークスペース ファイル、ステージング領域ファイル、およびローカル ウェアハウスはすべてロールバックされます。

6. ファイルを削除する

Git では、削除も変更操作です。実際に試してみましょう。まず、新しいファイルをtest.txtGit に追加して送信します。

通常の状況では、不要なファイルはファイル マネージャーで直接削除するか、rm次のコマンドを使用して削除します。

$ rm test.txt

現時点では、Git はファイルが削除されたことを認識しています。そのため、ワークスペースとリポジトリに一貫性がありません。git statusコマンドは、どのファイルが削除されたかをすぐに通知します。

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

オプションは 2 つあります。1 つは、本当にリポジトリからファイルを削除したい場合は、コマンドを使用してgit rmファイルを削除し、次のようにすることですgit commit。

 ファイルはリポジトリから削除されます。

もう 1 つの状況は、ファイルが誤って削除された場合です。ファイルはまだバージョン ライブラリにあるため、誤って削除したファイルを最新バージョンに簡単に復元できます。

 git checkout -- test.txt

git checkout実際、ワークスペースのバージョンはリポジトリのバージョンに置き換えられ、ワークスペースが変更されたり削除されたりしても、「ワンクリックで復元」できます。

ファイルを削除するにはコマンドを使用します。git rmファイルがリポジトリに送信されている場合は、誤って削除することを心配する必要はありませんが、ファイルを最新バージョンに復元することしかできず、最後に送信した後に変更したコンテンツは失われることに注意してください。

3. 遠隔倉庫

Git は分散バージョン管理システムであり、同じ Git ウェアハウスを異なるマシンに分散できます。配布方法は？最初は、オリジナル バージョン ライブラリを持つマシンは 1 台だけでなければなりません。その後、他のマシンがこのオリジナル バージョン ライブラリを「複製」することができ、各マシンのバージョン ライブラリは実際には同じであり、プライマリまたはセカンダリの区別はありません。GitHub という魔法の Web サイトがあります。名前からもわかるように、この Web サイトは Git ウェアハウスのホスティング サービスを提供しています。そのため、GitHub アカウントを登録さえすれば、無料で Git リモート ウェアハウスを入手できます。国内版はgitee、海外版はgithubを使用します。

以下の内容を読み進める前に、ご自身で Gitee アカウントを登録してください。ローカル Git リポジトリと GitHub リポジトリ間の通信は SSH 経由で暗号化されるため、少しの設定が必要です。

ステップ 1: SSH キーを作成します。

まず、ローカル ssh キーを作成します。このキーは、ローカル コード リポジトリとリモート リポジトリ間の検証に使用されます。次のようにコマンドを入力します。Gitee 登録に使用したメール アドレスを入力することをお勧めします。

$ ssh-keygen -t rsa -C "[email protected]"  

公開/秘密 RSA キーのペアを生成しています... 3 回入力して SSH キーを生成します

 コマンドを入力して、生成された SSH キーを表示します。

$ cat ~/.ssh/id_rsa.pub

この ssh キーをコピーして Gitee に追加します。Gitee -> 個人情報 -> SSH 公開キー -> 公開キー名と公開キーを入力 -> [OK] をクリックします。

 GitHub/Gitee に SSH キーが必要なのはなぜですか? なぜなら、GitHub/Gitee は、あなたがプッシュする送信が、他の誰かがそのふりをしているのではなく、実際にあなたによってプッシュされたものであることを認識する必要があり、Git は SSH プロトコルをサポートしているため、GitHub/Gitee があなたの公開鍵を知っている限り、確認できるのはそれのみです。押すことができます。もちろん、GitHub/Gitee では複数のキーを追加できます。複数のコンピュータがあるとして、会社と自宅でそれぞれのコンピュータのキーを GitHub/Gitee に追加すれば、各コンピュータの GitHub/Gitee にプッシュできます。GitHub/Gitee アカウントがあることを確認したら、リモート ウェアハウスについて学び始めます。

2. リモートライブラリを作成する

Gitee 上にリモート コード ウェアハウスを作成し、Gitee Web ページにアクセスしてログインし、アバターの左側にあるプラス記号をクリックして、[新しいウェアハウス] を選択する必要があります。

倉庫情報を入力し、倉庫名を自分で定義し、その他のオプションはデフォルトのままにしてください。完了したら、「OK」をクリックします。

現在、Gitee 上のこのウェアハウスはzxcvgitまだ空です。Gitee は、このウェアハウスから新しいウェアハウスを複製するか、既存のローカル ウェアハウスを関連付けて、ローカル ウェアハウスの内容を Gitee ウェアハウスにプッシュできることを示します。

次に、Gitee のプロンプトに従い、ローカルリポジトリzxcvgitでコマンドを実行します。

$ git remote add origin [email protected]:michaelliao/learngit.git

注意してください。上記をmichaelliao自分の Gitee アカウント名に置き換えてください。そうでない場合、ローカルに関連付けたものは私のリモート ライブラリです。関連付けに問題はありませんが、SSH キーの公開キーが次のとおりであるため、今後プッシュすることはできなくなります。私と一緒ではありません。アカウントリストにあります。

追加後のリモート ライブラリの名前は ですorigin。これは Git のデフォルトの名前です。他の名前に変更することもできますが、originこの名前は一目でリモート ライブラリであることがわかります。

次のステップでは、ローカル ライブラリのすべてのコンテンツをリモート ライブラリにプッシュできます。

$ git push -u origin master

ローカル ライブラリの内容をリモートにプッシュするには、git pushコマンドを使用して実際に現在のブランチをmasterリモートにプッシュします。

リモート ライブラリは空なので、master初めてブランチをプッシュするときに-uパラメーターを追加します。Git はローカルmasterブランチの内容をリモートの新しいブランチにプッシュするだけでなく、masterローカルmasterブランチをリモート ブランチにmaster関連付けます。 ,これにより、押すときや引くときのコマンドが簡略化されます。プッシュが成功すると、リモート ライブラリのコンテンツがローカル ライブラリとまったく同じであることが Gitee ページですぐに確認できます。

今後は、ローカルでコミットを行う限り、次のコマンドを渡すことができます。

$ git push origin master

ローカルmasterブランチの最新の変更を Gitee にプッシュします

cloneGitまたはコマンドを使用してpush初めて GitHub に接続すると、次の警告が表示されます。

ホスト「github.com (xx.xx.xx.xx)」の信頼性を確立できません。
RSA キーのフィンガープリントは xx.xx.xx.xx.xx です。
接続を続行してもよろしいですか (はい/いいえ)。

入力してyesEnter を押すだけです。Git は、GitHub キーがこのマシンの信頼リストに追加されたことを通知する警告を出力します。

警告: 「github.com」(RSA) が既知のホストのリストに永久に追加されました。

この警告は 1 回だけ表示され、それ以降の操作では警告は表示されません。

リモートライブラリの削除

追加時に間違ったアドレスを入力した場合、またはリモート ライブラリを削除したい場合は、次のgit remote rm <name>コマンドを使用できます。git remote -v使用する前に、まずリモート ライブラリの情報を確認することをお勧めします。

$ git remote -v
origin  [email protected]:michaelliao/learn-git.git (fetch)
origin  [email protected]:michaelliao/learn-git.git (push)

次に、名前に基づいて削除します。たとえば、 delete origin:

$ git remote rm origin

ここでの「削除」は、実際にはローカルとリモート間のバインディング関係を削除するものであり、リモート ライブラリを物理的に削除するわけではありません。リモート ライブラリ自体には変更はありません。実際にリモート ライブラリを削除するには、Gitee にログインし、背景ページで削除ボタンを見つけて削除する必要があります。

リモート ライブラリを関連付けるには、コマンドgit remote add origin git@server-name:path/repo-name.git;を使用します。

リモート ライブラリを関連付ける場合は、リモート ライブラリの名前を指定する必要があります。これがoriginデフォルトの命名規則です。

関連付け後、コマンドを使用してgit push -u origin masterマスター ブランチのすべてのコンテンツを初めてプッシュします。

その後、ローカル コミットのたびに、必要に応じてコマンドを使用して最新の変更をプッシュできますgit push origin master。

3. リモートリポジトリからクローンを作成する

前回は、最初にローカル ライブラリがあり、その後にリモート ライブラリがある場合に、リモート ライブラリを関連付ける方法について説明しました。スクラッチから開発していると仮定すると、最善の方法は、最初にリモート ライブラリを作成し、次にリモート ライブラリからクローンを作成することです。まず、Gitee にログインし、新しいウェアハウスを作成し、GitHub が自動的にファイルを作成するように名前をgitskills 確認します。作成後、ファイルを確認できます。Initialize this repository with a READMEREADME.mdREADME.md

リモート リポジトリの準備ができたので、次のステップは次のgit cloneコマンドを使用してローカル リポジトリのクローンを作成することです。

$ git clone [email protected]:michaelliao/gitskills.git

Git ライブラリのアドレスを自分のものに変更することに注意し、gitskillsディレクトリに入ってREADME.mdファイルが既に存在するかどうかを確認します。

$ cd gitskills
$ ls
README.md

ウェアハウスのクローンを作成するには、まずウェアハウスのアドレスを知ってから、git cloneコマンドを使用してクローンを作成する必要があります。

Git は Git を含む複数のプロトコルをサポートしていますhttpsが、sshこのプロトコルが最も高速です。

4. 支店管理

実際にブランチはどのように使用されますか? 新しい機能を開発する予定ですが、完了までに 2 週間かかるとします。最初の 1 週間でコードの 50% を書きました。コードがまだ書かれていないため、すぐに送信すると、不完全なコード ベースが作成されます。他の人が働くのを妨げてしまいます。すべてのコードが記述されるまで待ってから送信すると、日々の進捗が失われる大きなリスクがあります。今は支店があるので、恐れる必要はありません。自分のブランチを作成します。他の人はそれを見ることができません。元のブランチで通常どおり作業を続けます。自分のブランチで作業し、必要なときに送信します。開発が完了するまで、それを元のブランチにマージします。これは安全であり、他の人の作業には影響しません。Git のブランチは異なりますが、ブランチの作成、切り替え、削除は Git なら 1 秒以内に完了します。リポジトリが 1 ファイルであるか 10,000 ファイルであるか。

1. ブランチの作成とマージ

バージョンのロールバックでは、Git は各送信をタイムラインに文字列化します。このタイムラインは ブランチ です。現時点では、タイムラインは 1 つだけですが、Git ではこのブランチをメイン ブランチ、つまりブランチと呼びます (master厳密HEADにはコミットを指しているのではなく、コミットmasterを指しているため、現在のブランチを指します)支店）。最初はブランチは線であり、Git は最新のコミットをポイントし、次にそれをポイントして現在のブランチと現在のブランチのコミット ポイントを決定します。masterHEADmastermasterHEADmaster

コミットするたびにmasterブランチは 1 ステップずつ進むため、コミットを続けるとmasterブランチ行がどんどん長くなっていきます。

たとえば、新しいブランチを作成するdevと、dev Git は同じコミットを指す という新しいポインタを作成しmaster、さらにHEADそれを指しますdev。これは、現在のブランチdevが

 これ以降、ワークスペースへの変更と送信はdevブランチ用になります。たとえば、新しい送信後、devポインタは 1 つ進みますが、masterポインタは変化しません。

dev上記の作業が完了したら、devそれを上記にマージできますmaster。Git をマージするにはどうすればよいですか? 最も簡単な方法は、現在のポイントを直接コミットしてmasterdevマージを完了することです。

ブランチをマージした後、ブランチを削除することもできますdev。devブランチの削除はポインタの削除を意味し、削除後は 1 つのブランチdevが残ります。master

実戦を始めましょう。

devまずブランチを作成し、次にdevブランチに切り替えます

$ git checkout -b dev

git checkoutコマンドと-bパラメーターは作成と切り替えを意味し、次の 2 つのコマンドと同等です。

$ git branch dev
$ git checkout dev

次に、次のgit branchコマンドを使用して現在のブランチを表示します。 

 git branchこのコマンドはすべてのブランチをリストし、現在のブランチには番号が付けられます*。その後、devブランチ上で通常どおり送信できます。たとえば、readme.txt変更を加え、行を追加してから送信します。

新しいブランチの作成は簡単です。

 

devブランチでの作業が完了した ので、masterブランチに戻ることができます。

masterブランチ に戻った後、readme.txtファイルを再度チェックすると、追加したばかりのコンテンツが消えていました。そのコミットはブランチ上にありdev、master現時点でのブランチのコミット ポイントは変更されていないためです。

devブランチの作業結果をmasterブランチに マージします。

$ git merge dev

 git mergeこのコマンドは、指定されたブランチを現在のブランチにマージするために使用されます。マージ後、再度内容を確認してみると、ブランチの最新のコミットと全く同じであることreadme.txtがわかります。dev上記のFast-forward情報に注目してください。Git は、このマージが「早送りモード」であること、つまり、ポイントされている現在のコミットが直接masterコミットされてdevいるため、マージ速度が非常に速いことを示しています。もちろん、すべてのマージが可能なわけではありませんFast-forward。他のマージ方法については後ほど説明します。

マージが完了したら、devブランチを安全に削除できます。

$ git branch -d dev

削除後に確認するとブランチbranchだけが残っていることがわかります。master

$ git branch

スイッチ

ブランチの切り替えが使用されていることに気付きましたgit checkout <branch>。また、上記の元に戻す変更では、git checkout -- <file>同じコマンドに 2 つの機能があり、確かに少し混乱しています。実際、ブランチを切り替えるアクションはswitchより科学的です。したがって、Git の最新バージョンでは、git switchブランチを切り替えるための新しいコマンドが提供されています。

新しいブランチを作成して切り替えるにはdev、次を使用します。

$ git switch -c dev

既存のブランチに直接切り替えるにはmaster、以下を使用できます。

$ git switch master

理解しやすい新しいgit switchコマンドを使用してください。git checkout

 ブランチを表示:git branch

ブランチを作成します。git branch <name>

ブランチを切り替える:git checkout <name>またはgit switch <name>

ブランチの作成 + 切り替え:git checkout -b <name>またはgit switch -c <name>

ブランチを現在のブランチにマージします。git merge <name>

ブランチを削除します:git branch -d <name>

2. 競合を解決する

ブランチのマージは、多くの場合、順風満帆ではありません。新しいfeature1ブランチを準備し、新しいブランチの開発を継続します

$ git switch -c feature1

readme.txt最後の行を次のように変更します。

新しいブランチの作成は迅速かつ簡単です。

feature1ブランチにコミットします。

$ git add readme.txt
$ git commit -m "AND simple"

ブランチに切り替えますmaster:

$ git switch master

masterブランチ上のファイルの最終行を変更してreadme.txt送信します。

新しいブランチの作成はすばやく簡単です。

$ git add readme.txt 
$ git commit -m "& simple"

これで、masterブランチとfeature1ブランチにはそれぞれ独自の新しいコミットがあり、次のようになります。

この場合、Git は「クイック マージ」を実行できず、それぞれの変更をマージしようとすることしかできませんが、この種のマージでは競合が発生する可能性があります。試してみましょう。

$ git merge feature1

案の定、衝突がありました！Git は、readme.txtファイル内に競合があるため、ファイルを送信する前に手動で競合を解決する必要があることを通知します。git status競合するファイルをお知らせいただくこともできます。

 readme.txtの内容を直接表示できます。

Git では、異なるブランチの内容をマークするために 、 、を使用します<<<<<<<。これを次のように変更して保存します=======。>>>>>>>

新しいブランチの作成はすばやく簡単です。

再度送信してください:

$ git add readme.txt 

 これで、master枝とfeature1枝は下の画像のようになります

git logパラメーターを使用してブランチのマージ ステータスを確認することもできます 。

$ git log --graph --pretty=oneline --abbrev-commit

最後に、feature1ブランチを削除します。

$ git branch -d feature1

仕事は終わりました。

Git がブランチを自動的にマージできない場合は、まず競合を解決する必要があります。競合を解決した後、再度送信するとマージが完了します。

競合を解決するには、Git とのマージに失敗したファイルを必要なコンテンツに手動で編集して、送信する必要があります。

コマンドでgit log --graphブランチマージグラフを確認できます。

3. 支店経営戦略

Fast forward通常、ブランチをマージする場合、Gitは可能であれば モード を使用しますが、このモードではブランチを削除するとブランチ情報が失われます。強制的に無効Fast forwardモードにしたい場合、Git はマージ時に新しいコミットを生成し、ブランチ履歴からブランチ情報を確認できるようにします。

--no-ffメソッドのパラメータを見てみましょう。これはメソッドが無効になっていることを意味します。git merge，--no-ffFast forward

まず、引き続きdevブランチを作成して切り替えます

$ git switch -c dev

readme.txt ファイルを変更し、新しいコミットを送信します。

$ git add readme.txt 
$ git commit -m "add merge"

ここで、次のように戻りますmaster。

$ git switch master

ブランチをマージする準備をしてください。パラメーターdevに注意してください。つまり、無効になっています。このマージでは新しいコミットが作成されるため、パラメーターを追加し、コミットの説明を書き込みます。--no-ffFast forward,-m

$ git merge --no-ff -m "merge with no-ff" dev

git logマージ後、次のようにしてブランチ履歴を確認できます。

$ git log --graph --pretty=oneline --abbrev-commit

 ご覧のとおり、Fast forwardパターンを使用しないと、マージ後は次のようになります。

 

分岐戦略

実際の開発では、いくつかの基本原則に従ってブランチ管理を行う必要があります: まず、masterブランチは非常に安定している必要があります。つまり、ブランチは新しいバージョンをリリースするためにのみ使用され、通常は作業できないものでなければなりません。その後、どこで作業する必要がありますか? すべての作業はブランチ上で行われますdev。つまり、devブランチは不安定です。バージョン 1.0 がリリースされたときなど、特定の時点で、devブランチはブランチにマージされmaster、masterバージョン 1.0 はブランチ上でリリースされます。誰もがdev自分のブランチを持っており、dev時々ブランチにマージする必要があるだけです。チームワークブランチは次のようになります

ブランチをマージする場合、--no-ffパラメーターを追加することで通常モードでマージできますが、マージされた履歴にはブランチがあるため、マージが行われたことがわかりますが、マージではfast forwardマージが行われたことがわかりません。

4. バグブランチ

ソフトウェア開発では、バグがある場合は修正する必要があります。Git ではブランチが非常に強力であるため、各バグは新しい一時ブランチによって修正できます。修正後、ブランチはマージされ、次に一時ブランチがマージされます。ブランチは削除されます。issue-101コードネーム 101 のバグを修正するという割り当てを受けた場合、当然、それを修正するためのブランチを作成したくなります。

$ git branch -d issue-101

しかし、待ってください、dev現在作業が進行中です

$ git status
ブランチ dev で
コミットする変更:
  (ステージングを解除するには、「git replace HEAD <file>...」を使用します)

    新しいファイル: hello.py

コミット用にステージングされていない変更:
  (コミットされる内容を更新するには、「git add <file>...」を使用します)
  (作業ディレクトリ内の変更を破棄するには、「git checkout -- <file>...」を使用します)

    変更: readme.txt

提出したくないのではなく、作業が途中までしか進んでいないため、まだ提出できないのです。完了までにさらに 1 日かかると予想されています。ただし、バグは 2 時間以内に修正する必要があります。どうすればよいですか? Git は、現在の作業サイトを「保存」し、後でサイトが復元された後も作業を継続できるstash機能も提供します。

$ git stash

現在、git statusビュー ワークスペースを使用すると、クリーンな状態になっているため (Git によって管理されていないファイルがない限り)、バグを修正するためのブランチを安全に作成できます。

まず、バグを修正する必要があるブランチを決定します。masterブランチで修正する必要がある場合は、master一時的なブランチを作成します。

$ git checkout master
$ git checkout -b issue-101

ここでバグを修正するには、「Git はフリー ソフトウェアです...」を「Git はフリー ソフトウェアです...」に変更して、次のように送信する必要があります。

$ git add readme.txt 
$ git commit -m "fix bug 101"

 [issue-101 4c805e2] バグ 101 を修正
 1 ファイル変更、1 挿入 (+)、1 削除 (-)

修復が完了したら、masterブランチに切り替えてマージを完了し、最後にissue-101ブランチを削除します。

$ git switch master
$ git merge --no-ff -m "merged bug fix 101" issue-101

バグ修正完了！devさあ、ブランチに戻って仕事をしましょう。

$ git switch dev
$ git status

ブランチ開発では
コミットするものは何もなく、作業ツリーはクリーンです

作業場はきれいになりました。今作業場を保存した場所はどこですか? git stash list次のコマンドで確認してください。

$ git stash list

stash@{0}: 開発上の WIP: f52c633 マージの追加

作業サイトはまだ存在します。Git は隠しコンテンツをどこかに保存していますが、復元する必要があります。方法は 2 つあります:

1 つはリカバリを使用する方法git stash applyですが、リカバリ後はスタッシュ コンテンツは削除されないため、git stash dropそれを使用して削除する必要があります。もう 1 つはリカバリをgit stash popスタッシュ コンテンツはリカバリと同時に削除されます。

スタッシュは複数回行うことができます。リストアするときは、最初に を使用してgit stash list表示し、次に指定したスタッシュをリストアするには、次のコマンドを使用します。

$ git stash apply stash@{0}

master ブランチのバグを修正した後、それについて考えなければなりませんが、dev ブランチは以前に master ブランチからブランチされたため、このバグは実際には現在の dev ブランチに存在します。では、dev ブランチで同じバグを修正するにはどうすればよいでしょうか? この操作を 1 回繰り返して送信することもできますが、同じバグを dev で修正する4c805e2 fix bug 101簡単な方法があります。この送信によって加えられた変更を dev ブランチに「コピー」するだけです。注: master ブランチ全体をマージするのではなく、このコミットによって加えられた変更のみをコピーする必要があります4c805e2 fix bug 101。

Git は、cherry-pick特定のコミットを現在のブランチにコピーできるコマンドを具体的に提供します。

$ git cherry-pick 4c805e2

Git は自動的に dev ブランチへのコミットを作成しました。2つのコミットには同じ変更が加えられているだけであり、実際には 2 つの異なるコミットであるため、このコミットのコミットは1d4b803マスター コミットと異なることに注意してください。4c805e2これを使用するとgit cherry-pick、開発ブランチでバグ修正プロセスを手動で繰り返す必要がなくなります。バグは master ブランチで修正でき、修復プロセスは dev ブランチで「再生」できるため、dev ブランチでバグを直接修正してから、master ブランチで「再生」しても問題ありませんか? もちろん可能ですが、git stashシーンの保存に対して dev ブランチから master ブランチに切り替えるコマンドを実行する必要があります。

バグを修正するときは、新しいバグ ブランチを作成して修正し、それをマージして、最後に削除します。

目の前の作業が完了していない場合は、まずgit stash現場に行き、バグを修正してからgit stash pop現場に戻ります。

master ブランチで修正されたバグを現在の dev ブランチにマージする場合は、git cherry-pick <commit>コマンドを使用してバグによって送信された変更を現在のブランチに「コピー」し、作業の重複を避けることができます。

5. 機能ブランチ

ソフトウェア開発では、常に追加すべき新機能が無限にあります。新しい機能を追加するときは、実験的なコードでメイン ブランチを台無しにしたくないため、新しい機能を追加するたびに、新しい機能ブランチを作成し、そのブランチ上で開発し、それをマージすることが最善です。完了したら、最後に機能ブランチを削除します。

さて、ついに新しいタスクを受け取りました。コード名「Vulcan」という新しい機能を開発するというものです。

したがって、開発の準備をします。

$ git switch -c feature-vulcan

5 分後、開発は完了します。

$ git add vulcan.py
$ git status
$ git commit -m "add feature vulcan"

元に戻ってdevマージの準備をします。

$ git switch dev

すべてがうまくいけば、機能ブランチはバグ ブランチに似ており、マージされてから削除されます。しかし！そんな時、上司から資金不足のため新機能を中止せよとの命令が！それは無駄でしたが、それでも機密情報が含まれているこの支店はその場で破棄されなければなりませんでした。

$ git branch -d feature-vulcan

エラー: ブランチ「feature-vulcan」は完全にはマージされていません。
本当に削除する場合は、「git Branch -D feature-vulcan」を実行します。

破壊は失敗しました。Git からのフレンドリーなリマインダーです。feature-vulcanブランチはまだマージされていません。ブランチを削除すると、変更は失われます。削除を強制したい場合は、大文字のパラメータを使用する必要があります-D。ここで削除を強制します:

$ git branch -D feature-vulcan

ようやく削除に成功しました！

新しい機能を開発するには、新しいブランチ機能を作成するのが最善です。

マージされていないブランチを破棄したい場合は、git branch -D <name>強制的に削除できます。

6. 複数人のコラボレーション

リモート リポジトリからクローンを作成すると、Git は実際にはローカルmasterブランチをリモート ブランチに自動的にマップしますmaster。リモート リポジトリのデフォルト名は ですorigin。

リモート リポジトリに関する情報を表示するには、次を使用します。git remote​​​​​​​

$ git remote

 起源

または、次git remote -vのコマンドを使用して、より詳細な情報を表示します。

$ git remote -v

オリジン [email protected]:michaelliao/learngit.git (フェッチ)
オリジン [email protected]:michaelliao/learngit.git (プッシュ)

上記はoriginクロールおよびプッシュできるアドレスを示しています。プッシュ権限がない場合は、プッシュ アドレスを表示できません。

プッシュブランチ

ブランチのプッシュとは、ブランチ上のすべてのローカル コミットをリモート ライブラリにプッシュすることを意味します。プッシュするときは、Git がリモート ライブラリに対応するリモート ブランチにブランチをプッシュできるように、ローカル ブランチを指定する必要があります。

$ git push origin master

他のブランチ (たとえば ) をプッシュする場合は、次devのように変更します。

$ git push origin dev

ただし、ローカル ブランチをリモートにプッシュする必要はありません。では、どのブランチをプッシュする必要があり、どのブランチをプッシュする必要がないのでしょうか?

• masterブランチはメイン ブランチであるため、常にリモートと同期する必要があります。

• devこのブランチは開発ブランチであり、チームのメンバー全員がそれに取り組む必要があるため、リモートと同期する必要もあります。

• バグ ブランチは、ローカルでバグを修正するためにのみ使用されます。上司が毎週修正するバグの数を確認したい場合を除き、リモートにプッシュする必要はありません。

• 機能ブランチがリモートにプッシュされるかどうかは、小規模パートナーと協力して開発するかどうかによって決まります。

ブランチを取得する

複数の人が共同作業する場合、全員が自分の変更をブランチにプッシュしますmaster。dev

ここで、友人をシミュレートし、別のコンピュータ (SSH キーを GitHub に追加する必要があることに注意してください) または同じコンピュータ上の別のディレクトリにクローンを作成します。

$ git clone [email protected]:michaelliao/learngit.git

友人がリモート リポジトリからクローンを作成する場合、デフォルトでは、友人はローカルmasterブランチのみを参照できます。私の言うことが信じられない場合は、次のgit branchコマンドを使用して確認できます。

$ git branch
* master

ここで、友人がdevブランチで開発したい場合は、リモートoriginブランチをdevローカルに作成する必要があるため、次の$ git checkout -b dev Origin/devコマンドを使用してローカルdevブランチを作成します。

$ git checkout -b dev origin/dev

これで、彼はdev引き続き変更を加え、その後、時々リモートにdev分岐できるようになります。push

$ git add env.txt
$ git commit -m "add env"
$ git push origin dev

あなたの友人はすでにorigin/dev自分のコミットをブランチにプッシュしており、偶然あなたも同じファイルに変更を加えてプッシュしようとしました。

$ cat env.txt
env

$ git add env.txt

$ git commit -m "add new env"
[dev 7bd91f1] add new env
 1 file changed, 1 insertion(+)
 create mode 100644 env.txt

$ git push origin dev
To github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to '[email protected]:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

友人の最新の送信があなたがプッシュしようとしている送信と競合するため、プッシュは失敗します。解決策も非常に簡単です。Git は、最初に最新の送信を取得し、それをローカルでマージして競合を解決するように要求します。もう一度プッシュしてgit pullくださいorigin/dev。​​​​

$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev

git pulldevまた、ローカルブランチとリモートブランチの間のリンクがorigin/dev指定されていないため、失敗しました。プロンプトに従って、次のdevようにリンクを設定しますorigin/dev。

$ git branch --set-upstream-to=origin/dev dev

次のエラーが発生します。 zsh: no such file or directory: Branch

 その理由は、「branch」を git Branch --set-upstream-to=origin/master master のようにブランチ名に置き換える必要があるためです。

もう一度引っ張ります:

$ git pull

今回は成功しましたが、マージ中に競合が発生したため、手動で解決する必要がありました。解決策はgit pullブランチ管理での競合解決とまったく同じでした。解決したら、送信して再度プッシュします。

$ git commit -m "fix env conflict"
$ git push origin dev

したがって、複数人によるコラボレーションの作業モデルは通常次のようになります。

1. まず、git push origin <branch-name>独自の変更をプッシュしてみることができます。

2. プッシュが失敗した場合は、リモート ブランチがローカル ブランチより新しいため、git pull最初にマージを試みる必要があります。

3. マージ内に競合がある場合は、競合を解決してローカルでコミットします。

4. 競合がない場合、または競合が解決された場合、git push origin <branch-name>プッシュは成功します。

git pullプロンプトが表示された場合はno tracking information、ローカル ブランチとリモート ブランチ間のリンク関係が作成されていないことを意味します。コマンドを使用しますgit branch --set-upstream-to <branch-name> origin/<branch-name>。

これが複数人によるコラボレーションの仕組みであり、慣れてしまえば非常に簡単です。

• リモート ライブラリ情報を表示するには、git remote -v;を使用します。

• 新しく作成されたブランチがリモートの場所にプッシュされない場合、そのブランチは他のユーザーには表示されません。

• ブランチをローカルにプッシュして使用しますgit push origin branch-name。プッシュが失敗した場合は、それを使用してgit pull最初に新しいリモート送信を取得します。

• リモート ブランチに対応するローカル ブランチを作成して使用します。git checkout -b branch-name origin/branch-nameローカル ブランチとリモート ブランチの名前は同じである必要があります。

• ローカル ブランチとリモート ブランチ間の関連付けを確立するには、git branch --set-upstream branch-name origin/branch-name;を使用します。

• リモートからブランチを取得して使用しますgit pull。競合がある場合は、最初に競合を解決します。

7、キツネ

Git のコミット履歴がきれいな直線にならないのはなぜですか?

次のコマンドを入力してみてくださいgit rebase。

$ git rebase

リベース操作の特徴: フォークされたコミット履歴を直線に「編成」し、より直感的に見えます。欠点は、ローカル フォークのコミットが変更されていることです。最後に、プッシュ操作によってローカル ブランチがリモートにプッシュされます。リモート ブランチの送信履歴も直線になります。

• リベース操作では、ローカルのアンプッシュ フォークのコミット履歴を直線に整理できます。

• リベースの目的は、フォークされたコミットには 3 方向の比較が必要なため、履歴コミットの変更を簡単に確認できるようにすることです。

研究リンク: https://www.liaoxuefeng.com/wiki/896043488029600/900004590234208