• Gitを素早く学ぶ
• Git の起源について紹介します。
• 集中型バージョン管理システムと分散型バージョン管理システムの違い
• Gitをインストールする
• 完全なGitの使用プロセス
• 支店管理

Gitを素早く学ぶ

学習後すぐに使えるGitチュートリアル！ミスを防ぎ、変更内容を簡単に確認するために、コードの変更をすべて記録したいと思ったことはありませんか？開発効率を向上させるために、複数のメンバーが役割を交代した際に、すぐに新しいコードベースを生成したいと思ったことはありませんか？Gitを学んで、ドキュメントを手動で管理する必要はもうありません！

バージョン管理システムは数多くありますが、Gitが最も有名です。なぜでしょうか？CVSやSVNのような集中型バージョン管理システムは、処理速度が遅いだけでなく、使用するにはインターネット接続も必要になるからです。

Git の起源について紹介します。

Linuxの人気が高まるにつれ、コード管理が課題となりました。そこで、Linuxの創始者であるLinus Torvaldsは、コードの管理と保守のために分散バージョン管理システムBitKeeperを選択しました。しかし、後に何らかの不都合な理由により、BitKeeperを開発した商用企業はLinuxカーネルオープンソースコミュニティとの提携を解消し、BitKeeperの管理権をLinuxカーネルコミュニティから奪還しました。BitKeeperの使用から得られた教訓に基づき、Linuxオープンソースコミュニティ（特にLinuxの創始者であるLinus Torvalds）は独自のC言語による分散バージョン管理システムGitを開発し、多くの改良を加えました。これは実に素晴らしいことです。

集中型バージョン管理システムと分散型バージョン管理システムの違い

集中型バージョン管理システムでは、リポジトリは中央サーバーに保存されます。ユーザーは作業時に自分のコンピューターを使用するため、作業を開始する前に中央サーバーから最新バージョンを取得する必要があります。作業が完了したら、作業を中央サーバーに戻します。

分散型バージョン管理システムには、実際には「中央サーバー」は存在しません。各ユーザーのコンピュータには、それぞれ専用の完全なリポジトリ（ローカルリポジトリ）が存在します。つまり、リポジトリは各自のコンピュータ上に保存されるため、作業にインターネット接続は必要ありません。分散型バージョン管理システムには通常、「中央サーバー」（実際にはリモートリポジトリ）として機能するコンピュータも存在しますが、このサーバーの役割は変更内容の交換を容易にすることのみです。中央サーバーがなくても作業は可能ですが、変更内容の交換が不便になるという欠点があります。

Gitをインストールする

Linuxへのインストール:

2つの方法

一つの方法は、yumを使ってGitをインストールすることです。以下の手順を参考にしてください。

1. yumをインストールする

yum で git をインストール

ダウンロードするかどうかを尋ねられたら、「はい」をクリックします。

2. インストールが成功したことを確認します。

 git --version  

バージョン番号が表示されればインストールは成功です。Gitはデフォルトで/usr/libexec/git-coreディレクトリにインストールされます。cdコマンドを使ってインストール情報を確認できます。

2つ目の方法は、ソースコードのコンパイルを使用してインストールすることです。この方法の利点は、インストールされたバージョンをより簡単に管理できることです。

1. まず、https://github.com/git/git/releases からソースコードをダウンロードします。ここにはGitのすべてのリリースバージョンが載っています。最新のtar.gzパッケージを選択します。

最新バージョンはv2.30.0です。

ダウンロードコマンドは次のとおりです。

 https://github.com/git/git/archive/v2.30.0.tar.gz から wget を実行します。

解凍

tar -zxvf git-2.22.0.tar.gz

cd コマンドを使用して、抽出したフォルダーに移動します。

コンパイルに必要な依存関係をインストールします。

 yum インストール curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker

インストールが完了するまでお待ちください。インストール中にプロンプ​​トが表示されたら、「y」と入力してEnterキーを押してください。

ソースコードのコンパイルに必要な依存関係をインストールする際、yum は自動的に git をインストールします。この時点で、まず古いバージョンの git をアンインストールする必要があります。

 yum -y gitを削除する

Gitソースコードのコンパイル

prefix=/usr/ をlocal /git allにする 

/usr/local/git パスに git をインストールします。

 prefix=/usr/ をlocal /git でインストールします

環境変数を設定する

vi /etc/profile
下に追加
エクスポート PATH=$PATH:/usr/ローカル/git/bin

(変更を保存するには:wq!と入力してください)

環境変数を更新する

ソース /etc/profile

Git が正しくインストールされているかどうかを確認します。

 git --version  

Macにインストール:

2つの方法

まずHomebrewをインストールし、次にHomebrew経由でGitをインストールします。詳細な手順については、Homebrewのドキュメント（http://brew.sh/）を参照してください。

2つ目の方法はより簡単で、推奨される方法です。App StoreからXcodeを直接インストールします。XcodeはGitを統合していますが、デフォルトではインストールされていません。Xcodeを起動し、メニューから「Xcode」→「環境設定」を選択し、ポップアップウィンドウで「ダウンロード」を見つけて「コマンドラインツール」を選択し、「インストール」をクリックしてインストールを完了します。

Windowsにインストール:

Git Web サイトからインストーラーを直接ダウンロードし、デフォルトのオプションを使用してインストールします。

インストール後、スタートメニューで「Git」→「Git Bash」を探してください。コマンドラインウィンドウがポップアップ表示されたら、Gitが正常にインストールされたことを意味します。または、右クリックすると以下のアイコンが表示されます。

写真

一般的に、ここでは git bash の使用に慣れている人がいます。

最後のステップは識別子を設定することです。次のコマンドを入力してください。

 $ git config --global user.name "あなたの名前"  
 $ git config --global user.email "[email protected]"  

`git config --global` パラメータに注意してください。このパラメータは、このマシン上のすべての Git リポジトリでこの設定が使用されることを意味します。もちろん、特定のリポジトリに対して異なるユーザー名とメールアドレスを指定することもできます。

Git は、Linux、Unix、Mac、Windows などの主要なプラットフォームで正常に実行できるようになりました。

まずいくつかの基本的な概念を理解しましょう。

上の画像は Git の基本的なワークフローを示しており、おおよそ次の 4 つの領域に分けられます。

ワークスペース: 作業領域

通常の開発では、コードを変更する場合、つまり新しい要件が発生するたびに、その領域のコードが直接変更され、その領域のコードは最新の状態になります。

インデックス/ステージ: 一時保存領域

作業ディレクトリには、.git という隠しディレクトリがあります。これは作業ディレクトリの一部ではなく、Git リポジトリ（ステージング領域とオブジェクト領域を含む）です。

要件または機能を完了し、それをリモート リポジトリにコミットする必要がある場合、最初のステップは、Git で管理できるように `git add` を使用してステージング領域にコミットすることです。

.git ディレクトリ内のステージング領域（インデックスファイル）には、`git add` コマンドで追加されたファイルに関する情報（ファイル名、サイズ、タイムスタンプなど）が記録されますが、実際のファイルは保存されません。代わりに、各ファイルへの参照には ID が使用されます。ステージング領域は、現在の作業ディレクトリ内のどのコンテンツが Git によって管理されているかを示します。

リポジトリ: ローカルリポジトリ

`git commit` は `index` の内容をローカルリポジトリに同期できます。

ローカル リポジトリには、オブジェクトのコミットされたバージョンがすべて保存されますが、これは作業ディレクトリとステージング領域の内容よりも古いものです。

リモート: リモートリポジトリ

`git push` は、ローカル リポジトリの内容をリモート リポジトリに同期できます。

完全なGitの使用プロセス

1. リポジトリを作成または取得する

• バージョン管理リポジトリを作成する

ファイル ディレクトリを選択し、右クリックして Git Bash コマンドライン ウィンドウを開き、次のコマンドを実行してローカル リポジトリを初期化します。

 git 初期化

このコマンドは.gitというディレクトリを作成します。このディレクトリはGitがバージョンを追跡および管理するために使用されます。必要な場合を除き、このディレクトリ内のファイルを手動で変更しないでください。変更するとGitリポジトリが破損します。

• リモートリポジトリをローカルリポジトリに取得する

追記: リモート リポジトリを作成すると、ディレクトリを選択するように求められます。次に、右クリックして Git Bash コマンドライン ウィンドウを開き、サーバーから Git リモート リポジトリのクローンを作成します。

 git クローン [URL]

2. リポジトリへの各更新を記録する

新しく作成されたリポジトリの場合は、作業ディレクトリにはまだファイルがないので、作業ディレクトリで直接ファイルを追加したり変更したりできます。また、取得したリポジトリの場合は、作業ディレクトリの内容を直接変更できます。

変更を加えた後、次のコマンドを実行できます。

現在のファイルのステータスを確認します。

 $ git ステータス
ブランチマスター
変更はステージングされていません 専念：
 ( 「git add <file>...」を使用します)  に コミットされる内容を更新する）
 ( 「git checkout -- <file>...」を使用します)  作業ディレクトリの変更を破棄する） 
 
変更: readme.txt 
   
変更は追加されません コミット（ 「git add」を使用）  および/または  （"git commit -a" ）

「変更はコミット用にステージングされていません」とは、ファイル readme.txt が変更されているが、ステージング領域に存在しないことを意味します。

ステージング領域に変更を追加します。

 `git add [filename]` (特定のファイルの場合)
 git add *(すべてのファイル)
 `git add *.txt` (ワイルドカードをサポートし、すべての .txt ファイルを追加します)

この時点では、一時保存領域の内容は作業領域の内容と同じになります。

ファイルを無視:

追加操作を実行する際に、ステージング領域に配置したくないファイルが存在する場合があります。これらのファイルを無視するには、以下の方法があります。

• `touch .gitignore` コマンドを使用して `.gitignore` ファイルを作成します。
• 無視するファイルをファイルに書き込みます。
• たとえば、`appName/src/test/*` と記述すると、`appName` プロジェクトの `test` フォルダ内のすべてのファイルが無視されます。

更新を送信:

最新のコードは現在ステージングエリアにあります。以下のコマンドを使ってローカルリポジトリに移動する必要があります。

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

注: 各コミットの前に、`git status` を使用してすべてがステージングされているかどうかを確認し、コミット コマンドを実行します。

ステージング領域を使用して更新を送信する方法をスキップします。

よく考えてみると、変更はステージングエリアにあり、何もしていないように見えるので、ローカルリポジトリに直接コミットしないのはなぜでしょうか？これについては後ほど説明します。まずは、ステージングエリアを使わずに更新をコミットするコマンドについて説明しましょう。

 `git commit -a -m "コミットメッセージ"` 。

`git commit` に -a オプションを追加すると、Git は追跡されているすべてのファイルを自動的にステージングしてまとめてコミットするため、`git add` ステップがスキップされます。

Git ステージング領域の目的:

もしこのような疑問をお持ちなら、まず自問自答してみてください。Gitを使う際、変更が複数の機能に関係している可能性や、それぞれの機能を個別にコミットする必要があることを考慮せずに、すべての変更を一度にコミットしていませんか？そうすることで、明確なコミット履歴を確保できます。そうしないと、履歴をロールバックしようとした際に、どのバージョンにどの機能が含まれていたのか、どのバグが修正されたのかを区別できなくなり、完全に混乱してしまいます。

ステージングエリアの目的は、選択的なコミットを可能にすることです。例えば、機能Bを開発中に機能Aにバグを発見した場合、まず機能Aのバグを修正し、次にバグ修正版のAをコミットし、最後に機能Bをコミットする必要があります。これにより、コミット履歴が明確になり、ロールバックが容易になります。コミットはアトミック操作であり、ファイルの選択はステージングエリアによって処理されます。各コミットは機能開発の完了を表すため、クリーンなコミットが保証され、コミットの粒度が低減されます。

作業ディレクトリとリポジトリ内の最新バージョンの違いを確認するには:

 git diff HEAD -- [ファイル名]  

ファイルを削除:

ローカルリポジトリに更新をコミットする前に、ステージングエリアからファイルを削除する必要がある場合があります。削除コマンドは以下のとおりです。

 git rm [ファイル名]

ファイルの名前を変更します:

 git mv README.*** README
 (このコマンドは、mv README.*** README、git rm README.***、git add READMEの 3 つのコマンドの組み合わせと同等です。)

(このコマンドは、mv README.*** README、git rm README.***、git add README の 3 つのコマンドの組み合わせと同等です。)

提出履歴を表示:

複数の更新を行ったり、プロジェクトをクローンした後は、コミット履歴を確認したいと思うかもしれません。そのための最もシンプルで効果的なツールは、`git log` コマンドです。`git log` は、コミット時刻順にすべての更新を一覧表示し、最新の更新が一番上に表示されます。`--pretty=oneline` を追加すると、出力される情報量が減ります。

 $ git ログ
コミット1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> マスター)
著者: Michael Liao <[email protected]>
日付: 2018年5月18日金曜日 21:06:15 +0800 
 
 GPLを追加
 
コミットe475afc93c209a690c39c13a46716e8fa000c366
著者: Michael Liao <[email protected]>
日付: 2018年5月18日金曜日 21:03:36 +0800 
 
分散を追加
 
コミットeaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
著者: Michael Liao <[email protected]>
日付: 2018年5月18日金曜日 20:59:18 +0800 
 
 READMEファイルを書きました

git log --pretty=oneline  
 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) GPLを追加
e475afc93c209a690c39c13a46716e8fa000c366分散を追加
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 が Readme ファイルを作成しました

バージョンのロールバック:

 `git reset --hard HEAD^` は以前のバージョンに戻ります。  
 `git reset --hard HEAD^^` は以前のバージョンに戻ります。  
 `git reset --hard HEAD~100` は、以前の 100 バージョンに戻ります。  
 `git reset --hard [バージョン番号]` は固定バージョン番号に戻します。  
 `git reflog` コマンドは実行されたすべてのコマンドを記録します (バージョン番号を表示できます)。

ローカルの変更をリモート リポジトリにプッシュして、ローカル リポジトリとリモート リポジトリの整合性を保ちます。

既存のリポジトリをまだクローンしておらず、リポジトリをリモート サーバーに接続する場合は、次のコマンドを使用して追加できます。

 ·git リモートadd origin <url>

リモート リポジトリがすでにリンクされている場合は、次のコマンドを使用して、どのリモート リポジトリであるかを確認できます。

 git リモート -v

次に、ローカルの変更をリモート リポジトリにコミットします。

 git push origin [ブランチ]

これにより、追加されたサーバーに変更をプッシュできるようになります。

支店管理

ブランチは、機能開発を分離するために使用されます。リポジトリを作成すると、master が「デフォルト」ブランチになります。他のブランチで開発を行い、完了したら master ブランチにマージします。通常、新機能の開発や緊急のバグ修正を行う際には、ブランチを作成します。単一ブランチ開発と複数ブランチ開発のどちらが適しているかは、具体的なシナリオによって異なります。

最初は、masterブランチは1行です。Gitはmasterを最新のコミットを指すために使用し、HEADをmasterを指すために使用することで、現在のブランチとそのコミットポイントを決定します。

各コミットはマスター ブランチを 1 ステップ前進させるので、コミットが増えるにつれて、マスター ブランチはどんどん長くなります。

• ブランチ dev を作成する

git ブランチ dev
ブランチ名を指定せずに `git branch` を使用すると、現在のブランチが表示されます。

• 現在のブランチをdevに切り替える

git チェックアウト dev

• ブランチの作成と切り替え

`git checkout -b dev` (2つのコマンドを組み合わせる)

• メインブランチに切り替える

git チェックアウト マスター

• dev ブランチを master にマージします (これにより競合が発生する可能性があります)。

 git マージ dev

それで、この紛争はどのように解決すべきでしょうか?

まず、`git status` コマンドを使って競合しているファイルを確認します。次に、`cat [filename]` を使って、そのファイル内のどのコード行が競合しているかを確認します。Git は、`<<<<<<<`、`=======`、`>>>>>>>` を使用して、異なるブランチの内容をマークします。`<<` は…

• 新しく作成されたブランチを削除する

git ブランチ -d dev

• ブランチをリモート リポジトリにプッシュします (プッシュが成功すると他のユーザーに表示されます)。

 git push origin [ブランチ名]

プッシュが失敗する可能性があります。これは、他の同僚が同じファイルを変更してプッシュに成功したものの、プッシュしようとしているファイルがリモートリポジトリ内の既存ファイルと競合している場合に発生する可能性があります。その場合は、まずファイルをプルしてから再度プッシュする必要があります。

 git プル
追記: 失敗した場合は、プロンプトに従って `git pull --set-upstream-to=origin/<branch>` を実行してください。  
つまり、ローカル ブランチとリモート ブランチ間のリンクを指定する必要があります。