はじめに

PHPStormのバージョン管理のヘルパー機能である、Local Changesの使い方メモです。

詳細は公式ドキュメントを参照してください。
→ Gitを使用して複数の機能を同時に処理する

PHPStormの使い方シリーズ

• Shelfで並行開発を楽に管理する

作業用フォルダを用意する

まず、今回作業を行うフォルダを用意します。
この記事では、ローカルリポジトリ上で作業を行います。

% cd ~/Desktop
% mkdir shelf
% cd shelf

ローカルリポジトリを作成します。

% git init
% ls -la

drwxr-xr-x@  3 mitsuoka-takahiro  staff   96  7 29 21:19 ./
drwx------@ 14 mitsuoka-takahiro  staff  448  7 29 21:16 ../
drwxr-xr-x   9 mitsuoka-takahiro  staff  288  7 29 21:19 .git/

.gitフォルダがあればOK。

PHPStormでGitツールウィンドウを表示する

View > Tool Windows > Gitから開くことができます。
ショートカットはデフォルトで⌘9に設定されています。

このような感じのウィンドウが開きます。

変更リストで変更をまとめる(Local Changes)

変更リストを利用すると、開発中のファイルをグループで管理することができます。
コミットも変更リスト単位で行うことができ、1つのコミットに含めるファイルを選択する手間を省くことができます。

準備

新しいファイルを3つ追加し、ステージングします。
ステージングするのは、バージョン管理対象ファイルでないとLocal Changesに表示されなからです。

% echo hello > a1.txt
% echo hello > a2.txt
% echo hello > b2.txt
% git add .

Gitツールウィンドウはこのようになっていると思います。

変更リストでまとめる

ここで、a1.txtとa2.txtを機能Aの資源と仮定して、変更リストでまとめてみます。
a1.txtを右クリックし、New Changelistを選択します。
変更リストの名前を聞かれるので、機能Aを追加するという意味でadd feature Aとしておきます。
（変更リストの名前はデフォルトのコミットメッセージとなるので、コミットメッセージを意識してつけておくのがオススメです）

新しい変更リストが作成されるので、a1.txtとa2.txtをドラッグして変更リストに追加します。

これで、変更リストadd feature Aにa1.txtとa2.txtを追加することができました。

変更リスト単位でコミットする

⌘Kでコミットウィンドウを開きます。
デフォルトでは、b2.txtのみが表示されています。

ウィンドウ上部のChangelistからadd feature Aを選択します。

変更リストadd feature Aを選択したので、a1.txtとa2.txtが表示されました。
また、コミットメッセージにadd feature Aが表示されました。
このままコミットする場合は、右下のCommitボタンをクリックしてください。

変更リストのまとめ

変更リストを使うことで、開発中のファイルをグループ化して管理し、そのまま1つのコミットとすることができます。

PHPStormの使い方シリーズ

• Shelfで並行開発を楽に管理する

はじめに

PHPStormのバージョン管理のヘルパー機能である、Local ChangesとShelfの使い方メモです。

詳細は公式ドキュメントを参照してください。
→ Gitを使用して複数の機能を同時に処理する

作業用フォルダを用意する

まず、今回作業を行うフォルダを用意します。
この記事では、ローカルリポジトリ上で作業を行います。

% cd ~/Desktop
% mkdir shelf
% cd shelf

ローカルリポジトリを作成します。

% git init
% ls -la

drwxr-xr-x@  3 mitsuoka-takahiro  staff   96  7 29 21:19 ./
drwx------@ 14 mitsuoka-takahiro  staff  448  7 29 21:16 ../
drwxr-xr-x   9 mitsuoka-takahiro  staff  288  7 29 21:19 .git/

.gitフォルダがあればOK。

PHPStormでGitツールウィンドウを表示する

View > Tool Windows > Gitから開くことができます。
ショートカットはデフォルトで⌘9に設定されています。

このような感じのウィンドウが開きます。

変更リストで変更をまとめる(Local Changes)

変更リストを利用すると、開発中のファイルをグループで管理することができます。
コミットも変更リスト単位で行うことができ、1つのコミットに含めるファイルを選択する手間を省くことができます。

準備

新しいファイルを3つ追加し、ステージングします。
ステージングするのは、バージョン管理対象ファイルでないとLocal Changesに表示されないからです。

% echo hello > a1.txt
% echo hello > a2.txt
% echo hello > b2.txt
% git add .

Gitツールウィンドウはこのようになっていると思います。

変更リストでまとめる

ここで、a1.txtとa2.txtを機能Aの資源と仮定して、変更リストでまとめてみます。
a1.txtを右クリックし、New Changelistを選択します。
変更リストの名前を聞かれるので、機能Aを追加するという意味でadd feature Aとしておきます。
（変更リストの名前はデフォルトのコミットメッセージとなるので、コミットメッセージを意識してつけておくのがオススメです）

新しい変更リストが作成されるので、a1.txtとa2.txtをドラッグして変更リストに追加します。

これで、変更リストadd feature Aにa1.txtとa2.txtを追加することができました。

変更リスト単位でコミットする

⌘Kでコミットウィンドウを開きます。
デフォルトでは、b2.txtのみが表示されています。

ウィンドウ上部のChangelistからadd feature Aを選択します。

変更リストadd feature Aを選択したので、a1.txtとa2.txtが表示されました。
また、コミットメッセージにadd feature Aが表示されました。
このままコミットする場合は、右下のCommitボタンをクリックしてください。

変更リストのまとめ

変更リストを使うことで、開発中のファイルをグループ化して管理し、そのまま1つのコミットとすることができます。

Shelfにしまう

後日アップデート

はじめに

PHPStormのバージョン管理のヘルパー機能である、Local ChangesとShelfの使い方メモです。

詳細は公式ドキュメントを参照してください。
→ Gitを使用して複数の機能を同時に処理する

作業用フォルダを用意する

まず、今回作業を行うフォルダを用意します。
この記事では、ローカルリポジトリ上で作業を行います。

% cd ~/Desktop
% mkdir shelf
% cd shelf

ローカルリポジトリを作成します。

% git init
% ls -la

drwxr-xr-x@  3 mitsuoka-takahiro  staff   96  7 29 21:19 ./
drwx------@ 14 mitsuoka-takahiro  staff  448  7 29 21:16 ../
drwxr-xr-x   9 mitsuoka-takahiro  staff  288  7 29 21:19 .git/

.gitフォルダがあればOK。

PHPStormでGitツールウィンドウを表示する

View > Tool Windows > Gitから開くことができます。
ショートカットはデフォルトで⌘9に設定されています。

このような感じのウィンドウが開きます。

変更リストで変更をまとめる(Local Changes)

変更リストを利用すると、開発中のファイルをグループで管理することができます。
コミットも変更リスト単位で行うことができ、1つのコミットに含めるファイルを選択する手間を省くことができます。

準備

新しいファイルを3つ追加し、ステージングします。
ステージングするのは、バージョン管理対象ファイルでないとLocal Changesに表示されないからです。

% echo hello > a1.txt
% echo hello > a2.txt
% echo hello > b2.txt
% git add .

Gitツールウィンドウはこのようになっていると思います。

変更リストでまとめる

ここで、a1.txtとa2.txtを機能Aの資源と仮定して、変更リストでまとめてみます。
a1.txtを右クリックし、New Changelistを選択します。
変更リストの名前を聞かれるので、機能Aを追加するという意味でadd feature Aとしておきます。
（変更リストの名前はデフォルトのコミットメッセージとなるので、コミットメッセージを意識してつけておくのがオススメです）

新しい変更リストが作成されるので、a1.txtとa2.txtをドラッグして変更リストに追加します。

これで、変更リストadd feature Aにa1.txtとa2.txtを追加することができました。

変更リスト単位でコミットする

⌘Kでコミットウィンドウを開きます。
デフォルトでは、b2.txtのみが表示されています。

ウィンドウ上部のChangelistからadd feature Aを選択します。

変更リストadd feature Aを選択したので、a1.txtとa2.txtが表示されました。
また、コミットメッセージにadd feature Aが表示されました。
このままコミットする場合は、右下のCommitボタンをクリックしてください。

変更リストのまとめ

変更リストを使うことで、開発中のファイルをグループ化して管理し、そのまま1つのコミットとすることができます。

Are you still worn out on GitHub?

GitHubでまだ消耗してるの？
GitHubってレスポンス遅くない？
時間を節約したくない？

You don't have to use GitHub to use Git.

自称エンジニアの多くの人が知らないので、一応説明しておくと、gitはGitHubを使わなくても使えます。

もしあなたがエンジニアなら、MacかLinuxを使っていると思います。私はFreeBSDですが。え？Windows？？？そっ閉じして下さい…。

Creating a Git repository

ターミナルで mkdir temp.git してから cd temp.git して、git init --bare しましょう。

これであなたのパソコンがgitリポジトリーのホストになります。

Cloning a Git repository

sshでログインできれば、ssh経由でgitをクローンできます。

git clone username@example.com:~/temp.git

I don't understand SSH.

THAT'S COOL!!
sshを知らないエンジニアも最近は多いですよね！
そもそもWebデザイナー・コーダーの方にはsshは荷が重いですよ！
そのような場合も想定してあって、GitにはGitサーバーというデーモンが常駐してくれるプログラムがあります！
10年ほど前に、一度作ったことがありますが、もう忘れてしまいました。詳しくはググってみて下さい！

このような技術的な記事はLGMTされません！

LGMTされやすい記事とは、技術的な知識がなくても読める【ポエム】タグの記事です！
この記事をLGMTした人は"技術者"ですね！！

If you use --depth option when cloning a repo like this:

git clone --depth=50 repo.git

You will see origin/master branch of git branch -a command. But git ls-remote --heads origin will only see all remote branches. Nor we can't checkout a remote branch.

To checkout a remote branch in addition of master, you can do this:

git remote set-branches origin 'foo'
git fetch -v
git checkout -b foo origin/foo

概要

コミットを試みたところ、変更していない行に差分があった。
差分の正体は改行コードだった

解決策1

trコマンドで置換する

参考
[【 tr 】コマンド――テキストファイルの文字を置換する／削除する](https://www.atmarkit.co.jp/ait/articles/1610/03/news017.html

解決策2

gitは自動で改行コードを変換する機能があるのでそれをoffにする

git config --global core.autocrlf false

参考
気をつけて！Git for Windowsにおける改行コード - Qiita

Git - Git の設定
書式設定と空白文字 項目の部分

解決策3 vimで置換する

1. vimで改行コードを指定してファイルを開き直す

：e ++ff=unix 

1. ^M を削除する

:%s/\r//g

ファイルをステージングにaddしてコミットするのが面倒だ。

とくに

git commit -m "message"

のダブルクオーテーションを入力するときにタイピング速度が落ちるのが嫌だった。

なので、shellで対話モードで開いてくれて入力待ちしてくれるスクリプトを作った。

gcimコマンドの中身

#! /bin/bash
echo "add update file to staging"
echo Write commit Messge ...
read msg
git add -u
git ci -m "$msg"

使い方はこんな感じ

gcim
# >>> 入力モード
# これでgit add -u && git ci -m "<入力結果>"をしてくれる

とりあえず超シンプルなコードだけ書いた。Macでのみうごくので、使う人は適当に改良してほしい。

GitHub: gcim

- git(https://git-scm.com/download/win) をダウンロードしてインストールする option(with linux command)

gitsync.bat

REM Switch Disk
D:
cd D:\your-git-folder
git checkout -f master
git fetch origin master

REM Keep Local Change File Here
git update-index --assume-unchanged Unity/Assets/Model/AppInfo.cs

REM Remove Merge Problem File Here
rm -rf Unity/Assets/Model/AppInfo.cs.meta

git pull origin master
PAUSE

後は TaskManager 実行するだけ

GitHubのプロフィール画面が動いた…！

GitHubプロフィール画面にREADME.mdを作れるようになったらしい

最近少し話題になっていますが、GitHubプロフィール画面にREADME.mdを作れるようになったらしいです。

ここに自分の経歴や実績などをまとめておけると強いですね！
転職や案件探しの時にGitHubのURLだけを提出すればいいだけになったら素敵やん。。

日本語版の情報はまだ少ないですが、海外だとそこそこ試している人が多いみたいです。

How To Create A GitHub Profile README

GitHub recently released a feature that allows users to create a profile-level README to display prominently on their GitHub profile. This article walksthrough how to access this new feature.

自分もさっそく試してみたので作成方法をまとめておきます。

さっそく試してみる

Repository作成

自分のGitHubアカウント名と同じRepositoryを作成して、その直下にREADME.mdを作成するとできるみたいです。

Repository nameに自分のGitHubアカウント名で yagi-eng を入力すると、以下のように案内が出てきました。

⇒「Repository name」が赤くなっているのは自分は既にこの名前でRepositoryを作成済みのためです。

You found a secret! yagi-eng/yagi-eng is a ✨special ✨ repository that you can use to add a README.md to your GitHub profile. Make sure it’s public and initialize it with a README to get started.

README.mdが必要なので、 Initialize this repository with a README にはチェックを入れます。
もちろん後から作成してもOK。

プロフィールページを確認

https://github.com/yagi-eng
のように自分のプロフィールページにアクセスすると、自動生成されたREADME.mdの内容が表示されました！

Hi there ?

本格的に自分のプロフィールを書いてみる

完成品

https://github.com/yagi-eng

あんまり長文を書きすぎると、Top repositories にたどり着くまでにたくさんスクロールしなくてはいけなくなるので、このくらいの分量が限度かなと思います。

詳細な経歴や実績はREADME.mdの末尾にリンクとしておいて、別ページに飛んでもらうと良さそうです。
自分はこのRepositoryのルート直下に detail ディレクトリを作成してそこにREADME.mdを配置し、そこに詳細な経歴を記載することにしました。

まあmarkdownなのでなにか奇抜なデザインができるかというとそうでもないですが、gifを入れたりすると動きが出てライバルに差をつけることができますね！

でもhtmlタグを入れることもできるっぽい。。？
ここは自分は未検証です。

ボツ案1

カバー画像を入れてみたけど邪魔だった。。

ボツ案2

冒頭のように、遊び心で似顔絵がまばたきしているgifを入れてみたけど似顔絵2つはうざかった。。

gitignore Mac用

.DS_Storeとか、環境依存の不要なファイルをgitに混入させない設定

内容としては、github/gitignore: A collection of useful .gitignore templatesの紹介です。

ディレクトリとファイル作って、vimで編集

まずはグローバルの設定を変更します。

mkdir -p ~/.config/git && vim $_/ignore

ignoreの中身 （コピペでOK）

参考: gitignore/macOS.gitignore at master · github/gitignore

~/.config/git/ignore

# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon

# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

Mac以外の人は以下の一覧から探して入れる。
参考: gitignore/Global at master · github/gitignore

言語ごとにローカルの.gitginoreを設定する

自分の場合はCなのでCのディレクトリの.gitignoreは以下の設定を入れる。

参考: gitignore/C.gitignore at master · github/gitignore

# Prerequisites
*.d

# Object files
*.o
*.ko
*.obj
*.elf

# Linker output
*.ilk
*.map
*.exp

# Precompiled Headers
*.gch
*.pch

# Libraries
*.lib
*.a
*.la
*.lo

# Shared objects (inc. Windows DLLs)
*.dll
*.so
*.so.*
*.dylib

# Executables
*.exe
*.out
*.app
*.i*86
*.x86_64
*.hex

# Debug files
*.dSYM/
*.su
*.idb
*.pdb

# Kernel Module Compile Results
*.mod*
*.cmd
.tmp_versions/
modules.order
Module.symvers
Mkfile.old
dkms.conf

他にもいろんな言語が網羅されています。
参考: github/gitignore: A collection of useful .gitignore templates

Git を操作するコマンドやらなんやらを調べればコマンドプロンプトなどで$ git hogehoge みたいなのが無限に出てくる割に，この操作がどうなっているのか図示している人はあまりいなかった．

Git で管理をしたことのない人間としては，コマンドを並べられるよりも図で示された方が分かりやすいと思う．図で覚えた方が，どのような操作をしているのか覚えやすいということもある．
ということで，mermaid.js で描いてみた．¹

（対象が，“ちょっと分かっている人”でないと分からないような気がする......Git の用語も多く出てくるおかげで何が何やらという感が否めないが，その辺りは調べていただいて......）

○ 本記事で図示すること

• Git でワークツリー上にローカルリポジトリを作成し，リモートリポジトリに上げる（push）
• リモートリポジトリから情報を取得してローカルリポジトリに展開する（clone, pull）

リモートリポジトリにはGitHub を想定しているが，どのようなリモートリポジトリでも問題ない書き方を心がけた．

■ 基本事項

• Git は.git というフォルダ内にプロジェクト ワークツリーのHistory を書き込んでいる．これをWeb 上のGitHub に上げて，ローカルとリモートの双方で管理しようとしている．（以下，ワークツリーのHistory を単にHistory と表記する．）²
• ファイルやHistory を管理するところをリポジトリと言う．
  • ローカルリポジトリ：PC 内のリポジトリ
  • リモートリポジトリ：GitHub やGitLab など
• ブランチはプロジェクトの分岐であり，ベースとなるブランチはマスターブランチ³ と呼ばれる．（今回は$ git branch については触れない．）
• コマンド操作では$ が頭に付いているが，今回ではワークツリーの.git のあるディレクトリ上で行うことを示している．

○ 準備

開発中のワークツリーをリモートリポジトリに上げたい．

1. リモートリポジトリを作成する
2. ローカル側でGit で管理するディレクトリに.git を作成する（init）
3. .git にリモートリポジトリを認識させる（remote add）

$ git init
$ git remote add origin [HTTPS or SSH]

init によって，ワークツリーに.git フォルダが作成される．このフォルダにはワークツリーのHistory が記録されていくことになる．隠しフォルダになっているので通常では見えない．

remote add では，リモートリポジトリは"origin" と名づけられている．慣習的にこのような名前で名づけられているようだが，他の名前にしても良い（らしい）．
また，複数のリモートリポジトリをremote add で紐づけることも出来るようだ．

ここでは，単にリモートリポジトリ先のHTTPS/SSH を特定の名前に置き換えているものと認識している．

○ リモートリポジトリを更新する（Push）

1. History として残すファイルをステージングする（add）
2. ステージングしたHistory をローカルリポジトリに更新する（commit）
3. 更新されたファイルとローカルリポジトリのHistory をリモートリポジトリ上げ，リモートリポジトリ上のファイルとHistory を更新する（push）

シーケンスではpush が2回の操作のようになっているが，実際は1回の操作でpushが完了する．また，Index (Cache) ⁴とLocal Repository は双方とも.git に含まれている．

$ git add [files]
$ git commit -m "[comment]"
$ git push origin master

ステージングはコミットする前に複数回行っても良い．コミットする際にはそれまでにステージングされたHistory が更新される．

ステージングするファイルをいちいち特定するのが面倒な場合には，-A オプションでワークツリーに含まれるファイルすべてを選択することもできる．

$ git add -A

コミットする際にはコメントを残すことが出来る．というよりは，コメントを残す必要がある．-m オプションでコメントを入れることが出来る．
どのようなコメントをすべきなのかは他の記事に譲るが，変更点を簡潔に書いておけば良いだろう．（参考：Gitのコミットメッセージの書き方 - Qiita）

プッシュするブランチは"master" にするとマスターブランチのHistory が更新される．⁵
他のブランチが作成されている場合には，そのブランチ名にするとそのブランチのHistory が更新される．どのブランチを更新するのかは注意する必要がある．

config のエラーがあった場合（折りたたみ）

本当は準備の段階で$ git config についても触れるべきなのかもしれない．しかし，これも書くとどうも図で示したいという記事の体裁がアレな気がしたので，折りたたみでごまかします．

コミットしようとしてconfig が無いよと警告されたら，ユーザ名とユーザのEメールアドレスを登録しておこう．これによって，誰がコミットしたのかを明らかにしている．

$ git config --global user.name [User Name]
$ git config --global user.email [User E-mail]

--global を--local にすれば，プロジェクト毎に決めることもできる．

config 関連でもさまざまなことをGit に与えられるようなので，余裕があるときに調べてみると良いだろう．（参考：gitconfig の基本を理解する - Qiita）

○ リモートリポジトリを複製する（Clone）

リモートリポジトリにあるファイルとHistory をローカル側に複製する．このとき.git がディレクトリに作成されるので，ワークツリーをどこに作成するのか意識する必要がある．

1. リモートリポジトリのHTTPS/SSH を取得する
2. ローカル側にリモートリポジトリのファイルとHistory をクローンする（clone）

$ git clone [HTTPS or SSH]

ワークツリーを作成するディレクトリには注意する必要があるが，.git にはローカルのディレクトリのどこなのかを識別することはしていないようなので，clone してから任意のディレクトリに移動させることは出来るはずである．
移動する場合には，ワークツリーの構造を崩さないように注意する．次にプッシュしたときにリモートリポジトリのワークツリーの構造も変化してしまう．

○ リモートリポジトリと同期する（Pull: Fetch+Merge）

ローカルにあるプロジェクトとHistory をリモートリポジトリと同期したい．このときローカルにあるファイルは更新されるので，共同で開発している場合には意図していない編集が加えられている可能性もあることに注意．

1. リモートリポジトリからファイルとHistory を"Remote tracking branch" に複製する（情報の取得）（fetch）
2. "Remote tracking branch" に複製されたファイルとHistory をローカル側のファイルとHistory とに合わせる．（merge）

シーケンスではmerge が2回の操作のようになっているが，実際は1回の操作でmerge が完了する．また，Local Repository とupstream branch は.git に含まれている．

$ git fetch origin
$ git merge origin/master
$ git pull origin master

fetch でリモートリポジトリから情報を取得しているが，ローカル側には見た目の上では反映されていない．これは，"Remote tracking branch" に格納されているだけだからだ．（バイナリになっているので，人間では読めない）

上の場合では，"origin" のすべてのブランチの情報を取得している．
どのブランチをフェッチするのかを特定したい場合には，以下のようにする．このときにはマージも変わるので注意．⁵

$ git fetch origin [branch name]
$ git merge origin/[branch name]
$ git pull origin [branch name]

merge することで，"Remote tracking branch" にあるファイルとHistory をローカル側のファイルとHistory に合わせる．

これらの操作を一気にするのがpull であり，pull = fetch + merge である．

○ 参考

Special Thanks!!

• GitHub
• Git
  • Git - Book / 日本語
• Qiita
  • 君には1時間でGitについて知ってもらう(with VSCode) - Qiita
  • 図解！ Gitのブランチ・ツリーをちゃんと読む - Qiita
  • Gitの使い方メモ - Qiita
  • GitとGithubの基礎 - Qiita
  • いまさらだけどGitを基本から分かりやすくまとめてみた - Qiita
  • GitHubに作成したレポジトリをVSCodeにプルからのプッシュするまで - Qiita
  • Githubに新規リポジトリを追加 - Qiita
  • origin masterとorigin/masterの違い - Qiita
  • 【初心者向け】git fetch、git merge、git pullの違いについて - Qiita
  • GitとGitコマンド - Qiita
• Other
  • WindowsにGitをインストールする方法 | サービス | プロエンジニア
  • サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】

余談

参照にQiita での分かりやすい解説を複数挙げておいた．しかしながら，記事として非常に長いものもあり，1回ですべてを読みつくそうとは思えない．初見ではよく分からないところもある．分かりやすいけれど．
その意味では，図で示した方が分かりやすいものとなっているような気がする．図だけ覚えて帰ってもらってもいいと思う．間違いがあったらごめんなさい．

プルやプッシュはステージングやフェッチの段階を踏まないとローカルリポジトリを更新できないようになっている．操作としては面倒に感じるかもしれないが，ローカルリポジトリは直接操作しないというのがGit 製作者の思想らしい．

楽しいGit & GitHub ライフを！

---

1. 本記事で使用しているシーケンス図は自由に使ってもらって構いません．ただし，間違いがあった場合に関する図の流用で生じた被害の一切の責任は持ちません．（間違ってはいないはずですが．） ↩

2. なんだかHistory だなんて言葉を使っているが，「履歴」と読み替えてもまったく差し支えない．ちなみにHistory を見たいときには$ git log を使う．カタカナにしなかったのはヒステリーのように見えるのを避けるため． ↩

3. 人権的な意味合いから，master よりもmain の方がベターだと言う動きがあるらしい．現在の標準的な初期ブランチはmaster となっておりオプションで変更可能となっているようだ．（参考：“master”は不適切？　デフォルトブランチ名の変更に対応した「Git for Windows」v2.28.0 - 窓の杜） ↩

4. ステージングする場所をIndex と言うが，歴史的な経緯からCache とも言うようだ．また，Staging area と呼称する人もいる．いずれの呼び方であっても混乱のしないようにしよう． ↩

5. リモートリポジトリ側で更新された情報とローカルリポジトリ側で更新された情報が競合（けんか）する場合がある．この状態をConflict と言う． ↩

チーム開発で1つのPull Requestを複数人でレビューするときに修正ファイルで分担することがあったので
その一覧を取得した際のコマンドを残しておこうと思います。

git diff <ベースのブランチ> <修正が入ったブランチ> --name-only // --name-onlyオプションでファイル名のみの取得