Git - バージョン管理は王様です

2022-02-19 12:56:27

前書き

片手間での単独開発の時代は終わり、チームや組織間での共同開発が主流となりました。では、どのように開発時間を最大化するか。svn、gitなどのバージョン管理ソフトウェアが登場し、中でもgitはローカルバージョン管理に優れており、開発者の必須スキルとなっています。

1.1 gitの概要

1.1.1 gitのビフォーアフター

人生の偉大な出来事の多くと同様に、Gitも大きな論争と革新の時代に生まれ、Linuxカーネル・オープンソース・プロジェクトには多くの参加者がいました。Linuxカーネルのメンテナンスの大部分は、パッチのコミットやアーカイブの保存という雑用に費やされていました（1991年から2002年の間）。2002年になると、プロジェクトチーム全体が、コードの管理とメンテナンスに分散型バージョン管理システムであるBitKeeperを使うようになりました。

2005年、BitKeeperを開発した営利企業がLinuxカーネルオープンソースコミュニティとの提携を解消し、BitKeeperの無償使用権を取り上げたのです。これにより、Linuxオープンソースコミュニティ（特にLinuxの生みの親であるリーナス・トーバルズ氏）は、同じ過ちを繰り返さないためには、自分たちでバージョン管理システムを開発するしかないという教訓を得ざるを得なくなりました。彼らは、この新しいシステムに対して、いくつかの目標を設定しました。

* スピード * シンプルなデザイン * 非線形開発パターンの強力なサポート (並行開発のための数千のブランチを可能にする)

* Linuxカーネルのような巨大プロジェクトを効率的に管理する能力（スピードとデータ量）。

2005年に誕生して以来、Gitは成熟し、達成しようとした目標を保ちつつ、非常に使いやすいものに仕上がっています。高速で、大規模なプロジェクトの管理に最適で、信じられないようなノンリニアブランチ管理システム複雑なプロジェクト開発のニーズにも幅広く対応できます。

1.1.2 gitの開発環境

ステップ1：Gitをダウンロードし、デフォルトでインストールする

ダウンロードURL https://git-scm.com/downloads

(スタートメニュー -- Git -- Git bash, type git --version でバージョンを確認できます)

ステップ2： TortoiseGitグラフィカルクライアントのインストールをダウンロードする

ダウンロードはこちら https://tortoisegit.org/

(システムビットと一致する必要があります)

ステップ 3: Code Cloud (中国最大のリモートリポジトリ) にログインし、オンラインプロジェクトを作成します。

のURLです。 <スパン https://gitee.com/

(プロジェクトのあるURLをコピーします。オンラインリポジトリの場所としてhttps://gitee.com/winallt/项目名)

ステップ4：オンラインリポジトリをローカルにクローンします。Gitクローン

1.1.3 gitの開発プロセス

1: データベース（コードとバージョン情報を含む）をサーバーからスタンドアロンマシンにクローンします。

2: 自分のマシンにブランチを作成し、コードを修正する。

3: 1台のマシンで作成したブランチのコードをコミットする。

4: 1台のマシンでブランチをマージする。

5: 新しいブランチを作成し、サーバー上の最新バージョンのコードを取得し、自分の master ブランチとマージします。

6: 生成する <スパンパッチ (patch)と呼ばれるもので、パッチをメインの開発者に送ります。

7: メイン開発者からのフィードバックを探す。メイン開発者が一般開発者同士のコンフリクト（協力して解決できるコンフリクト）を見つけた場合、まずコンフリクトを解決してもらい、その後どちらかがコミットすることになります。主担当開発者が自分たちで解決できる場合、あるいは衝突がない場合は、パスします。

8: 開発者間の一般的なコンフリクト解消開発者は pull コマンドを使用して開発者間の衝突を解決し、衝突を解決した後にパッチをメイン開発者に提出することができます。

1.1.4 gitのしくみ

Gitと他のバージョン管理システムの主な違いは、Gitはファイル・データ全体が変更されたかどうかだけを気にするのに対し、他のほとんどのシステムは、ファイルの内容の特定の違いだけを気にすることです。これらのシステム（CVS、Subversion、Perforce、Bazaarなど）は、毎回、どのファイルが更新され、どの行で何が更新されたかを記録します。

他のシステムでは、各バージョンの個々のファイル間の具体的な差異を文書化している

Gitは、このような前後の差分に関するデータを保持していません。実際 Git は、変更されたファイルのスナップショットを取り、ミニファイルシステムに記録するようなものです。更新をコミットするたびに、すべてのフィンガープリントを見て、ファイルのスナップショットを取ります。更新をコミットするたびに、すべてのファイルのフィンガープリントを調べ、ファイルのスナップショットを取得し、次にこのスナップショットを指すインデックスを保存します。 . パフォーマンスを向上させるためにファイルが変更されていない場合 Git はそれを再度保存せず、ただ最後に保存されたスナップショットへのリンク Gitの動作方法は、次の画像のようになります。

Git は、ファイルが更新されるたびにそのスナップショットを保存します。

これが、Gitと他のシステムとの重要な違いです。Gitはどちらかというと小さなファイルシステムに近いのですが、単なるVCSではなく、それに基づいた多くの強力なツールを提供しています。後でGitブランチ管理について説明するときに、この設計の利点を見てみましょう。

ほぼすべての操作をローカルで行うことができる

Gitの操作の大部分は、ネットワーク接続を必要とせず、ローカルのファイルやリソースへのアクセスのみを必要とします。しかし、CVCSでは、ほとんど全ての操作でネットワークに接続する必要があります。なぜなら、Gitは、現在のプロジェクトに対するすべての更新の履歴をローカル・ディスク上に保持するので、非常に高速に動作するのです。

例えば、プロジェクトの履歴の要約を表示したい場合、Gitはサーバーに出かけてデータを取ってくる必要はなく、ローカルのデータベースからデータを読み取って表示するだけでいいのです。ですから、いつでも、待たずにすぐにそれを見ることができます。現在のバージョンのファイルと一ヶ月前のファイルの差分を見たい場合、Gitは一ヶ月前のファイルのスナップショットを取り、現在のファイルに対して差分計算を行います。これは、リモートサーバーに差分計算を依頼したり、古いバージョンのファイルを引っ張ってきてローカルで比較したりする代わりに行われます。

CVCSの場合、ネットワークやVPN接続がないと何もできない。しかしGitなら、たとえ飛行機や電車に乗っていても、好きなだけ更新をコミットし、インターネットにアクセスできるようになったらリモート・リポジトリにアップロードする、ということが楽しくできます。また、VPN接続がなくても、帰宅途中でも作業を続けることができます。他のバージョン管理システムでは、これはほとんど不可能か、非常に面倒なことでしょう。例えばPerforceは、サーバーに接続されていないとほとんど何もできません（デフォルトでは、ファイルの編集を開始するためにp4 edit fileというコマンドを発行できません。Perforceは、ファイルを変更している人をシステムに通知するためにネットワークに接続されている必要があるためです）。これは、Perforce がネットワークに接続して、誰がファイルを変更しているかをシステムに通知する必要があるためです (しかし、実際にはファイルのパーミッションを手動で変更することでこの制限を回避できます。ただし、変更が完了したときに更新をコミットできないだけです)。SubversionやCVSの場合、ファイルを編集することはできますが、データベースがネットワーク上にあるため、更新をコミットすることはできません。これは大したことではないと思われるかもしれませんが、実際に体験してみると、実際にどれだけの違いがあるのかに驚かれることでしょう。

データの完全性を常に維持する

Gitに保存する前に、すべてのデータはチェックサムされ、その結果はデータの一意な識別子とインデックスとして使用されます。言い換えれば、あなたが変更した後のファイルやディレクトリをGitが知らないということはあり得ないのです。この機能は、Gitの設計思想の一番底にある全体的なアーキテクチャに組み込まれています。ですから、転送中にファイルが不完全になったり、ディスクの破損でデータが欠落したりしても、Gitはすぐにそれを知ることができるのです。

Gitは、ファイルの内容やディレクトリの構造をフィンガープリント文字列としてSHA-1ハッシュを計算することで、データのチェックサムを計算するためにSHA-1アルゴリズムを使用します。この文字列は、40個の16進文字（0-9とa-f）から成り、以下のような形をしています。

<テーブル

24b9da6552252987aa493b52f8696cd6d3b00373

Git はこのような指紋文字列ですべて動作するので、このようなハッシュをよく目にすることになります。実際、Git に保存されているハッシュはすべて Git データベースはこのハッシュでインデックスされています。のように、ファイル名に依存するのではなく

ほとんどの操作は、データのみを追加する

一般的なGitの操作のほとんどは、データベースにデータを追加するだけです。なぜなら、データを削除するような不可逆的な操作は、ロールバックや過去のバージョンの再作成を困難にするからです。他のVCSでは、まだ更新をコミットしていないと、変更を失ったり難読化したりすることがあります。しかしGitでは、特に定期的に他のリポジトリにプッシュする習慣をつければ、スナップショットをコミットした時点でデータを失う心配はないでしょう。

この高い信頼性により、「好きな実験を進めても、どうせデータは失わない」という安心感が生まれます。Gitが内部でどのようにデータを保存し復元するかについては、後ほどGitが内部でどのように動作するかを説明するときに詳しく説明します。

ファイルの3つの状態

さて、次の考え方はとても重要なので注意してください。どのようなファイルであっても、Gitの中では3つの状態しかありません。コミット ( コミット )、修正された( モディファイド ) とステージング ( 段階的 ). コミットは、ファイルがローカルデータベースに安全に保存されたことを意味します。modifiedは、ファイルが変更されたが保存のためにまだコミットされていないことを意味します。stagedは、変更されたファイルが次のコミットで保存されるリストに置かれたことを意味します。

つまり、Gitがプロジェクトを管理する際にファイルの流れには、3つの作業領域があります。ギット Gitの作業ディレクトリ、ステージングエリア、ローカルリポジトリです。

作業ディレクトリ、ステージングエリア、ローカルリポジトリ

各プロジェクトはGitディレクトリ（git cloneが出る場合は .git のディレクトリを作成します。 (git clone --bare の場合、新しいディレクトリはそれ自体がGitディレクトリとなります。) これは Git メタデータとオブジェクトデータベースが格納される場所 . このディレクトリは非常に重要で、ミラーリポジトリをクローンするたびに、実際にコピーされるのはこのディレクトリ内のデータです。

作業を開始するために、プロジェクトのあるバージョンからすべてのファイルとディレクトリを取得することは、次のように呼ばれます。 <スパン作業ディレクトリ . これらのファイルは、実際にはGitディレクトリにある圧縮されたオブジェクトのデータベースから抽出され、その後、作業ディレクトリでこれらのファイルを編集することができます。

ステージング・エリアは、通常Gitディレクトリに置かれる単純なファイルに過ぎません。時々、このファイルをインデックス・ファイルと呼ぶ人もいますが、標準的な用語はやはりステージング・エリア（staging area）です。

1.2 共通のgitコマンド

###git init

ローカルに新しいレポを作成し、プロジェクトディレクトリに移動して git init を実行すると、レポが初期化され、現在のフォルダに .git フォルダが作成されます。

###git clone

リモートの Git リポジトリを URL で取得し、ローカルにコピーを作成します。

一般的な書式は git clone [url]です。

特定の名前を指定したい場合は、git clone [url] newnameで指定できます。

###gitステータス

レポのステータスを問い合わせます。

git status -sです。-s は short を意味し、-s 出力フラグは 2 列になります。1 列目はステージングエリア、2 列目は作業ディレクトリとなります。

###gitログ

ブランチのコミット履歴を表示します。

git log --oneline --number: ログを1行表示し、エントリ数を表示します。

git log --oneline --graph: ブランチのマージ履歴をグラフィカルに表示します。

git log branchname は、特定のブランチのログを表示します。

git log --oneline branch1 ^branch2 これを使うと、ブランチ 1 にあるコミットでブランチ 2 にないものを見ることができます。^ はこのブランチを除外するという意味です (Window の下に ^branch2 を引用符で囲んでおくとよいでしょう)。

git log --decorate でタグの情報が表示されます。

git log --author=[作者名] で作者のコミット履歴を指定することができます。

git log --since --before --until --after コミット時刻でログをフィルタリングします。

--no-merges は、マージ・コミットを除外します。

git log --grep はコミット情報に基づいてログをフィルタリングします： gitlog --grep=keywords

デフォルトでは、git log --grep --author は OR 関係、つまりひとつを返します。もし AND 関係にしたい場合は、--all-match オプションを追加します。

git log -S: 導入したdiffでフィルタリングします。

例えば、git log -SmethodName (Sと次の単語の間に等号がないことに注意しましょう)。

git log -p: 各コミットで導入されたパッチを表示します。

各コミットはスナップショットであり、Gitは各コミットのdiffを計算し、パッチとして表示します。

他の方法としては、git show [SHA]があります。

git log --stat: 各コミットで導入された変更点の diffstat を表示します。

また、変更に関する相対的な情報を見るために使用され、--statは-pの出力よりもシンプルです。

###git add

コミットする前に、Gitは新しいファイルを追加したり、新しい変更を追加したりできるステージング・エリアを用意しています。コミット時にコミットされる変更は、ステージング・エリアに最後に追加された変更であり、私たちのディスク上の変更ではありません。

git add .

現在の作業ディレクトリにあるすべてのファイルを再帰的に追加します。

###git diff

引数なしでgit diffを実行します。

ステージングされていない変更の diff を表示します。

このコマンドは、作業ディレクトリにある現在のファイルとステージング領域のスナップショット、つまり変更が加えられてからステージングされていない変更点との差分を比較します。

ステージングされたファイルと最後のコミットによるスナップショットの差分を見るには、次のようにします。

git diff --cached コマンドを実行します。

ステージングされた変更の diff を表示します。

(Git 1.6.1 以降では、git diff --staged でも同じ効果が得られます)。

git diff HEAD

すべてのステージングされた、あるいは未記載の変更の diff を表示します。

これは woking ディレクトリと最後のコミットの間のすべての変更を比較します。

あるバージョン以降に何が変更されたかを確認したい場合。

git diff [バージョンタグ]の場合

logコマンドと同様に、diffも--statパラメータを追加することで出力を簡略化することができます。

git diff [branchA] [branchB] は、2 つのブランチを比較するために使用します。

実際には、AからBへのパッチが返され、私たちが望む結果ではありません。

一般的に必要なのは、2つのブランチを、それぞれが変更する内容によって、コマンドで区切ることです。

git diff [branchA]...[branchB]となります。

実際には :git diff $(git merge-base[branchA] [branchB]) [branchB] の結果です。

###gitコミット

追加された変更をコミットします。

git commit -m "コミットメッセージ"です。

git commit -a は、tracked されたファイルにすべての変更を追加し、それをコミットします (ステージングを行わない svn commit のようなものです)。追跡されていないファイルについては、まだ git add する必要があります。

git commit --amend コミットを追加する。現在のコミットノードと同じ親を使用して新しいコミットが作成され、古いコミットは取り消されます。

###git リセット

変更とコミットを取り消します。

ここでの HEAD キーワードは、現在のブランチの末尾にある最新のコミットを指します。つまり、リポジトリ内のそのブランチでの最新バージョンです。

git reset HEAD: インデックスからファイルのステージを解除し、ポインタを HEAD にリセットします。

このコマンドは、誤って追加されたファイルをステージング状態から取り除くために使用します。git reset HEAD - - ファイル名、これは省略することもできます。

git reset --soft

HEAD を特定のコミット参照に移動します。index と staging はそのままです。

git reset --hard

ファイルのステージを解除し、作業ディレクトリの最後のコミットからの変更をすべて取り消します。

リセットするには git reset -hard HEAD を使用します。つまり、ステージされたファイルでのすべての変更と、最後のコミット以降の作業ディレクトリでの変更がなくなり、最後のコミットの状態に復元されます。

ここでのHEADは、どのコミットでもSHA-1として書き込むことができます。

git reset は soft と hard の引数なしで、実際にはデフォルトのパラメータを混ぜて使用します。

要約すると

git reset --mixed id は、git の HEAD を変更しますが（つまりコミット記録を変更します）、ファイルは変更しません（つまり、作業ツリーは変更しません）。コミットや追加の内容は削除されます。

git reset --soft id. 実際には、git reset --mixed id は git reset の後に git add を実行します。

git reset --hard id. これは git の HEAD を変更し、ファイルを変更します。

変更点は、以下のようにスコープごとにソートされます。

ソフト (コミット) <fixed (コミット + 追加) < ハード (コミット + 追加 + ローカル作業)

###git revert

コミットを取り消す。コマンドの引数に、おかしくなったコミットの名前(参照)を渡すだけです。

git revert HEAD: 直近のコミットを元に戻す。

git revert は逆の手順で新しいコミットを作成します。-n 引数は、そもそもコミットしないように Git に指示します。

###git rm

git rm ファイル。ステージングエリアからファイルを削除し、作業ディレクトリからも削除します。

git rm --cached: ステージングエリアからファイルを削除しますが、作業ディレクトリにはファイルを残します。

git rm --cached は、機能的には git reset HEAD と同じです。これはステージングエリアをクリアしますが、作業ディレクトリツリーはそのまま残します。

###git clean

git clean は、作業ディレクトリからトラックのないファイルを削除します。

通常の引数は git clean -df です。

-dはディレクトリを同時に削除すること、-fは強制を意味します。gitの設定ファイルではclean.requireForce=trueとなっているので、-fを付けないとcleanは実行を拒否されます。

###git mv

git rm - - キャッシュされた orig; mv orig new; git add new

###git stash

現在の変更点をスタックに押下します。

git stash は、現在のディレクトリとインデックスにあるすべての変更 (ただし未追跡ファイルは除く) をスタックにプッシュし、クリーンな作業状態 (つまり最後のコミットの状態) にします。

git stash listは、このスタックの一覧を表示します。

git stash apply: 隠し場所の最後の項目 (stash@{0}) を取り出し、現在の作業ディレクトリに適用します。

git stash apply stash@{1}のように、別のプロジェクトを指定することもできます。

適用中にstash内のアイテムを削除したい場合は、git stash popを使用することができます。

プロジェクトをstashから削除します。

git stash dropを実行します。前のものを削除するか、パラメータを指定して特定の項目を削除します。

git stash clear: すべてのアイテムを削除します。

###gitブランチ

git branch は、ブランチの一覧表示、ブランチの作成、ブランチの削除に使用できます。

git branch -v で、各ブランチの最後のコミットを見ることができます。

gitブランチすべてのローカルブランチを一覧表示し、現在のブランチにはアスタリスクが表示されます。

git branch (branchname)。新しいブランチを作成します (この方法でブランチを作成した場合、ブランチは最後のコミットに基づきます)。

git branch -d (branchname)。ブランチを削除します。

リモートからブランチを削除します。

git push (remote-name) :(branch-name): リモートブランチを削除します。

これは、コマンドの完全な形が :

git push remote-name local-branch:remote-branch

そして、local-branch の部分は空で、これは remote-branch が削除されたことを意味します。

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

リモートブランチにリンクするようにローカルブランチを変更します。

###git checkout

　git checkout(branchname) あるブランチに切り替えます。

git checkout -b (ブランチネーム) : 新しいブランチを作成し、切り替えを行います。

このコマンドは、git branch newbranch と git checkout newbranch を組み合わせた結果です。

checkoutにはもう一つの目的があります。それは、ローカルの変更を置き換えることです。

git checkout --<filename>

このコマンドは、作業ディレクトリ内のファイルを HEAD の最新の内容で置き換えます。ステージングエリアに追加された変更や、新しいファイルは影響を受けません。

注意: git checkout filename は、ステージングおよびコミットされていないファイル内のすべての変更を削除し、これは元に戻せません。

###git merge

あるブランチを現在のブランチにマージします。

git merge [エイリアス]/[ブランチ]。

リモートブランチを現在のブランチにマージします。

コンフリクトがあり、手動で変更する必要がある場合は、git mergetoolを使用することができます。

git diff でコンフリクトを解決し、解決したら git add で追加すれば、コンフリクトが解決されたことになります。

###gitタグ

履歴の一点をインポートとしてタグ付けします。

永続的なブックマークはコミット時に作成されます。通常、リリースをリリースした後、またはタグを付けて何かを出荷した後に作成されます。

例：gitタグv1.0

git tag -a v1.0, -a 引数は、何らかの情報を追加する、つまり注釈付きタグを作成することを可能にします。

git tag -a コマンドを実行すると、Git はエディタを開き、タグの情報を入力できるようになります。

コミットSHAを使って、過去のコミットにタグ付けすることができます。

git tag -a v0.9 XXXX

タグを含めたい場合は、プッシュ時に --tags パラメータを追加することで可能です。

取り込みの際、ブランチヘッドから到達できないタグはスキップされます。すべてのタグが含まれるようにしたい場合は、-tags オプションを追加する必要があります。

###gitリモート

リモートリポジトリのエイリアスをリストアップ、追加、削除します。

毎回完全な url は必要ないので、Git はリモートリポジトリの url ごとにエイリアスを作成し、そのリストを管理するために git remote を使用します。

git リモートリモートエイリアスを一覧表示します。

プロジェクトをクローンすると、Git は自動的に元の URL を :origin というエイリアスとして追加します。

git remote -v: 各エイリアスの実際のurlを見ることができます。

git remote add [alias] [url]。新しいリモートリポジトリを追加します。

git remote rm [alias]。既存のリモートエイリアスを削除します。

git remote rename [old-alias] [new-alias]: 名前を変更します。

git remote-set-url [エイリアス] [URL]を設定します。 ]:urlを更新します。引数として -push と fetch を追加すると、同じエイリアスに対して異なるアクセスアドレスを設定することができます。

###git フェッチ

リモートリポジトリから新しいブランチとデータをダウンロードします。

リモートレポを取得するには git fetch [alias] を、すべてのレポを取得するには git fetch --all を使用します。

fetch はローカルにないデータをすべて取得します。取得したブランチはすべてリモートブランチと呼ぶことができ、これはローカルブランチと同じです (diff やログなどを見たり、他のブランチにマージしたりできます)。しかし Git では、これらにチェックアウトすることができません。

###git pull

リモートリポジトリから取得し、現在のブランチにマージしようとします。

プル == フェッチ + マージ FETCH_HEAD

git pull は、まず gitfetch を行い、次に git merge を行って取得したブランチの head を現在のブランチにマージします。このマージ操作によって、新しいコミットが生成されます。

引数に --rebase を指定すると、git merge の代わりに git rebase を実行します。

###git rebase

--rebase はマージされたコミットを生成せず、すべてのローカルコミットをパッチとして ".git/rebase" ディレクトリに一時的に保存し、現在のブランチを最新のブランチチップに更新し、最後に保存したパッチをそのブランチに適用します。

リベース中にコンフリクトが発生した場合、Git はリベースを停止してコンフリクトを解決します。解決後、git add で更新すれば、コミットする必要はありません。

git rebase --continue はパッチの残りを続行します。

git rebase --abort はリベースを終了させ、現在のブランチはリベース前の状態に戻ります。

###git push

新しいブランチとデータをリモートリポジトリにプッシュします。

git push [エイリアス] [ブランチ]。

は、現在のブランチをエイリアス上の [branch] ブランチにマージします。ブランチがすでに存在する場合は更新され、存在しない場合は追加されます。

複数の人が同じリモートリポジトリにコードをプッシュしている場合、Git はまずプッシュ元のブランチで git log を実行し、その履歴をチェックしてサーバー上のブランチに現在のティップがあるかどうかを確認します。Git はあなたのプッシュを拒否し、フェッチ、マージ、そしてプッシュの順で実行します。

###git reflog

git reflog は reflog を管理するコマンドで、ブランチの変更や HEAD の参照に対する変更など、git が参照に対する変更を記録するために使用する仕組みです。

git reflog が参照を指定しない場合、デフォルトで HEAD reflog がリストアップされます。

HEAD@{0}は現在のHEADの値を表し、HEAD@{3}は3回変更する前のHEADの値を表します。

git は変更を .git/logs/HEAD にある HEAD reflog ファイルに記録し、ブランチの reflog ファイルは .git/logs/refs のサブディレクトリに記録します。