主要なGitの概念

マスターヘッド

Git では、コミットごとにタイムライン、つまりブランチが作成されます。Git には、master ブランチと呼ばれるブランチがあります。厳密に言えば、HEAD はコミットではなく、master を指しています。master はコミットを指しています。つまり、HEAD は現在のブランチを指していることになります。

最初は、masterブランチは1行です。Gitはmasterを使って***コミットを指し示し、次にHEADを使ってmasterを指し示します。これにより、現在のブランチとそのコミットポイントを特定できます。

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

dev のような新しいブランチを作成すると、Git は dev という新しいポインタを作成します。これは master と同じコミットを指します。次に、HEAD が dev を指すように設定されます。これは、現在のブランチが dev にあることを意味します。

今後、作業ディレクトリへの変更とコミットはdevブランチに対して行われます。例えば、新しいコミットの後、devポインタは1ステップ進みますが、masterポインタは変更されません。

`dev` での作業が完了したら、`dev` を `master` にマージできます。Git はどのようにマージするのでしょうか？最も簡単な方法は、`master` を `dev` の現在のコミットにポイントするだけで、マージが完了します。

ブランチをマージした後、devブランチを削除することもできます。devブランチを削除すると、devポインタが削除され、masterブランチだけが残ります。

作業エリア、一時保管エリア

• ワークスペース：これはコンピュータ上に表示されるディレクトリで、コードが保存されているフォルダです。非常にリアルタイム性が高く、ファイルへの変更はすべてここに即座に反映されます。
• バージョン管理リポジトリ：作業ディレクトリ内に隠しディレクトリ .git があります。これは作業ディレクトリではなく、Git バージョン管理リポジトリです。
• ステージング領域 (インデックス/ステージ): `git add` 後、ファイルへの現在の変更がこの領域に保存されます。
• ローカル リポジトリ: `git commit` の後、現在のステージング領域内のファイルへの変更がローカル リポジトリにコミットされます。
• リモートリポジトリ: リモートリポジトリ名は通常「origin」です。`git push` を実行すると、ローカルリポジトリのコミットのうちリモートリポジトリよりも優先されるコミットがリモートリポジトリにプッシュされます。

ダウンロードしてインストールする

公式サイトからGitをダウンロードする

初期化

初期化パラメータ

`$ git config --global user.name "あなたの名前"`    
 `$ git config --global user.email "あなたのメールアドレス"`  

Git は分散バージョン管理システムであるため、各マシンは自身を識別する必要があります (名前と電子メール アドレス)。

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

ローカルリポジトリを初期化する

$ git 初期化

SSHキー生成

`$ ssh-keygen -t rsa -C "あなたのメールアドレス"`  

クローンコード

// マスターブランチをクローンする 
 `$ git clone <リポジトリURL>`  
 // クローンするブランチ名を指定します 
 `git clone -b <ブランチ名> <リポジトリURL>`

.gitignore を効果的に使う方法

// まず、ローカル キャッシュを削除します (追跡されていない状態に変更します)。  
 `$ git rm -r --cached`    
 // 送信する 
 `$ git add .`  
 $ git commit -m '.gitignore を更新'  

さまざまなステータスを表示する

// 現在のステータス（ブランチ名、変更、競合、作業ディレクトリ内のステージング領域の内容、コミット数など）を表示します。  
 $ git ステータス 
 // ローカルリポジトリのコミット履歴を表示する 
 $ git ログ 
 // ローカルリポジトリのコミット履歴を表示する（簡易版）  
 git log --pretty=oneline    
 // コマンド履歴を表示 
 $ git reflog

支店

// ブランチを表示:
 $ git ブランチ -a  
 // ローカルブランチを作成します:  
 `git branch <ブランチ名>`  
 // ローカルブランチに切り替えます:  
 `git checkout <ブランチ名>`  
 // ローカルブランチを作成して切り替えます:  
 `git checkout -b <名前> `  
 // ブランチを現在のブランチにマージします:
 `git merge <マージするブランチ>`
 // ローカルブランチをリモートブランチにプッシュする
`git push origin <プッシュするローカルブランチ名>`
 // リモートブランチに基づいてローカルブランチを作成する
`git checkout -b <ローカルブランチ名> origin/<リモートブランチ名>`
 // ローカルブランチを削除します:
 `git branch -d <ローカルブランチ名>`
 // リモートブランチを削除します。ローカルの空のブランチをリモートブランチにプッシュすることは、リモートブランチを削除することと同じです。
 `git push origin :<削除するリモートブランチ名>`

コードを更新してコミットする

新しいファイル、つまり変更は、最初は作業ディレクトリにのみ存在します。`git add` を使用すると、Git はこの変更をキャッシュして追跡します。`git commit` を使用すると、変更がリポジトリにコミットされます。

 // すべての変更をキャッシュする 
 $ git を追加  - 全て   
 // 変更を1つのファイルにキャッシュする 
 `$ git add <ファイル名、パスを含む>`  
 // ローカルリポジトリにコミット 
 `git commit -m <コミットメッセージ>`  
 // ローカルコードを更新する 
 `git pull origin <ブランチ名>`  
 // ローカルコミットをリモートサーバーにプッシュする 
 `git push origin <ブランチ名>`

キャンセル

// ワークスペース内のファイルへの変更を元に戻す 
 `$ git checkout [ファイル]`  
 // ワークスペース内のファイルへのすべての変更を元に戻す 
 `$ git checkout`。  
 // ステージングエリア内の指定されたファイルを、最後のコミットと一致するようにリセットします。ただし、変更は消去されず、作業ディレクトリに戻されます。  
 `$ git reset [ファイル]`  
 // ステージング領域と作業領域を最後のコミットと一致するようにリセットします。  
 `git reset --hard <現在のブランチ名>`    
 // 現在のブランチポインタを指定されたコミットにリセットし、ステージングエリアもリセットします。ただし、変更は削除されず、作業ディレクトリに戻されます。  
 $ git reset [コミット]  
 // 現在のブランチの HEAD を指定されたコミットにリセットし、ステージング領域と作業ディレクトリも指定されたコミットと一致するようにリセットします。  
 `git reset --hard [コミット]`    
 // 現在の HEAD を指定されたコミットにリセットしますが、ステージング領域と作業ディレクトリは変更しません。  
 `git reset --keep [コミット]`    
 // コミットされていない変更を一時的にスタッシュに保存し、後でポップアップします。
 $ git スタッシュ 
 $ git スタッシュポップ 
 gitレビュー

コードレビューは Gerrit システムを使用して実行され、`git review <branch name>` コマンド (デフォルトは master) を使用してレビュー操作が実行されます。

ルール

• レビューにコミットする前にリモートコードをプルし、コミット前のコードが元のコードであることを確認してください。競合がある場合は、ローカルでマージして解決する必要があります。
• 1 つの機能変更は 1 つのコミットに配置され、1 つのレビューが送信されます。

特別な状況

• レビューが失敗したらどうなりますか?

まず、変更したいコミットに戻ります。

 `$ git reset --soft <変更するコミットID>`  

編集したいファイルの変更を続けます。変更後、キャッシュファイルを追加して実行します。

 $ gitコミット  - 修正する 

新しく作成された変更を以前の変更にマージし、`git review` の実行を続行します。

• すでに複数のコミットを行った場合はどうなりますか?

複数のコミットが関連している場合は、それらを 1 つのコミットにマージします。

 // *** によって送信されたコミットを照会し、その ID を記憶します。  
 $ git ログ 
 // リベース操作を実行する 
 `$ git rebase -i <前のステップで見つかったID>`  
ポップアップ ウィンドウには、*** の最新のコミットから現在までのすべてのコミット レコードが一覧表示されます。  
 // 各列の先頭の'pick' を's' に変更し、列 *** には'pick'のみを残します。  
 // 変更を保存すると、システムはこれらのコミットを自動的に 1 つのコミットにマージします。  
 // 競合が発生した場合は、手動で解決する必要があります。競合をマージした後、すべてのコミットがマージされるまでリベースを続行します。  
 git リベース--continue  

レビューで複数のコミットが送信された場合、そのうちの1つがレビューされていない場合（変更IDが生成されなかったコミットを含む）はどうなりますか？ 各コミットは1件のレビューに対応しています。前のレビューが不合格になった場合、後続のレビューは承認されていても送信できません。後続のレビューを送信するには、前のレビューが承認されている必要があります。

 //失敗したレビューに対応するコミットID を取得します(これは Gerrit に記録されます)。  
 // このコミットの前のノードに戻り、^ に注意してください。  
コマンド `git rebase -i <失敗したレビューに対応するコミットID>` が実行されます。  
 // コミットするファイルを変更してキャッシュした後 
 $ gitコミット  - 修正する   
 // 先頭に戻る 
 git リベース--continue    
 // 古いレビューの更新を送信する 
 $ git レビュー