VSSより10倍モダンなGitの使い方について学ぶ【基本】

##【はじめに】
普段業務でGitを使ったことのない人間が、Gitの使い方について学んでみましたので、アウトプットのつもりでqiitaの投稿をいたします。
業務では、VSS（Visual Source Safe）というバージョン管理ソフトを使用して、ソースや仕様書等の管理をしている。未だにそんなレガシーなもの使っているの？というご意見は最もなのですが、レガシーな現場であり、ネットワーク制限が厳しい為、そんなモダンなものを使えいないのです。

##【対象者】
- OS Windows
- Gitをすでにインストールしている
[インストールしてない方はこちらを参考](https://eng-entrance.com/git-install)

- VScodeをすでにインストールしている

[インストールしてない方はこちらから](https://azure.microsoft.com/ja-jp/products/visual-studio-code/)
[インストール参考HP](https://eng-entrance.com/texteditor-vscode)
[VScode日本語化の仕方](https://webbibouroku.com/Blog/Article/vscode-ja-language)

##【Gitについて】
そんなわけで、今どきのモダンなバージョン管理システムといえば<b>GitおよびGitHub</b>
そんな<b>Git GitHub</b>について微力ながら解説していきたいと思う。

##【Git GitHubを使用する上での用語説明】
<b>1.リポジトリ</b>
ソースなどを管理する保管庫

<b>2.ローカルリポジトリ</b>
自身のPCのローカルにディレクトリを作成し、リモートリポジトリへ登録するための自身の保管庫

<b>3.リモートリポジトリ</b>
ネットワーク上（GitHub上）にあるリポジトリ。開発者間で共有する保管庫

<b>4.mkdir</b>
make directory、 ディレクトリを作成すること

<b>5.cd</b>
change directory、作業ディレクトリを移動すること。
例：デスクトップにあるディレクトリ⇒Cドライブ配下のディレクトリへ移動

<b>6.コミット</b>
追加・変更したファイルをGitに登録すること

<b>7.VScode</b>

WEB系のエンジニアさんの大半が使用している高機能エディタ

- コード補完の表示
- パラメータインフォの表示![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/d0dafdc6-4b02-d979-7743-080431874f77.png)
- ユーザースニペットの表示(VSCodeでは、forやtrycatchのような、よく使う定型文がすでに登録されている)
- デバック機能

など上記に挙げた機能以外にもたくさんの機能が盛り込まれたまさしく超高機能エディタです。

[参考：Visual Studio Codeのうれしい機能を使いこなして、初心者を最速で脱出する！より](https://employment.en-japan.com/engineerhub/entry/2019/06/21/103000)


###【そもそもGitって】
プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システム[(Wikipediaより)](https://ja.wikipedia.org/wiki/Git)
バグの修正や機能の追加ごとにソースコードの状態を記録していくのが、主な活用法だと思う。
大規模プロジェクトとなると、数多くのソースコードを管理する必要があるため、開発者同士で共同で作業がしやすくなるように、リポジトリを複数用意して行う必要がある。
<b>リポジトリを複数用意して共同作業ができる、これが分散型と言われている。</b>
イメージは以下となるが、リポジトリを複数用意して共同作業ができる、とは、個々で保有しているローカルリポジトリから変更内容を反映させたり、逆にリモートリポジトリというところからローカルに反映させることができる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/eb24f5bb-dae5-d51e-b765-5daf76f36f0d.png)


###【Gitコマンドについて】
上記については追々説明していくが、百聞は一見に如かず、Gitコマンドを使用して、実際にファイルをcommitするところまでを実施してみよう。
Cドライブ配下で

```Git:
mkdir Git(任意のディレクトリ名)
cd Git
mkdir VBA(任意のディレクトリ名)
cd VBA
git init
```
上記コマンドを入力するとCドライブ配下に
1.Gitというディレクトリを作成
2.Gitのディレクトリへ移動
3.Gitディレクトリ内にVBAディレクトリを作成
4.VBAディレクトリへ移動

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/709adbcf-3e03-ee0c-965b-494af6e0fef5.png)
私の場合は、C:\Git\VBAとディレクトリ作成をしてみた。
その後Git Bashを開こう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/a4db8486-6a19-457b-00ba-b36efeab889d.png)


#VScodeをコマンドで開く
C:\Git/の配下にVBAのディレクトリを作成後、cd(チェンジディレクトリ)で、C:\Git/VBA
をコマンドに打ち込むと作業ディレクトリをC:\Git/VBAへ移動できるので、移動します。
その後「code .」とすることで作業ディレクトリに割り当てた状態で、VScodeを開く

```Git:code
code . 
```
※正直なところ、HTMLやCSS、PHPなどはVScode内でファイルを作成して編集していくスタイルですが、今回xlsm形式のファイルを例題に挙げてますので、VScodeの出番はcommitした時になります。

#init
「init」は「initialize」からきていると思うと、納得いくと思う。新規作成や初期化を意味する。
Cドライブ配下に作成したディレクトリ内でinitコマンドを実行してリポジトリ（保管庫を作成）

```Git:init
git init 
```
これで、リポジトリが完成したが、見た目ではわからないので、隠しファイルを表示する。
ツールバーの表示⇒隠しファイルのチェックボックスにチェックを付けておく
こうすることで、git initされた場合、に隠しファイルが表示されるようになる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/c76472a6-ee14-4504-80e4-b04182e5d90d.png)

実際に隠しファイルにチェックを入れると、以下のようにアイコンが薄くなっている隠しファイルが表示されるようになる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/2a61e796-1f8d-9045-60b9-c9332464a918.png)

これが確認できたら、<b>git init</b>すなわちリポジトリが作成できたことがわかる。

#status
ステータス、要するに現在のリポジトリの状態を見るコマンドである。

```Git:status
git status 

(use "git add <file>..." to include in what will be committed)
	dbconnect.xlsm
```
initしてリポジトリ作成後、そのディレクトリにファイルを配置し、git statusをすると、
>use "git add <file>..." to include in what will be committed

と表示される。commitする前段階に持っていくことを「ステージング」というが、このステータスは、ステージングできる「ファイルをaddできますよ」ということである。


#add
ファイルの配置が完了し、commitの前準備を始めます。

```Git:add
git add ファイル名
または
git add . 
(「add .」とすることで全ての追加できていないファイルをaddすることが出来る)
```
git add後、git status状態を確認すると
>Changes to be committed:
>new file:   test.xlsm

上記が表示される。
「コミットする変更がありますよ」
何を？
「dbconnect.xlsmのファイル」ということである。

#rm
commitの前に実はリポジトリに入れておきたいのは別のファイルだったんだよ、とファイルを削除するときには、git rmを使用する。

```Git:rm
git rm ファイル名
```
ただし、直接ディレクトリからファイルをDELETEするのは好ましくない方法です。
直接削除してgit statusで確認すると「rmして更新してくれ」と言われてしまいます。

>(use "git add/rm <file>.." to update what will be committed)
>(use "git checkout -- <file>..." to discard changes in working directory)

git rmをして正規に削除すると以下のように表示されればOKです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/8a52aebe-f9f5-69b7-9169-e8eb7f3c7322.png)



#commit
さて、いよいよcommitです。早く結果にcommitしたいです。
bashでコメントをつけてcommitする方法と、VScode側でコメントを付けてcommitする方法の2つをご紹介します

```Git:commit
■ bashでコメントをつけてcommitする方法
git commit -m'コメント'
```
-mの後に'コメント'を挿入することで、何の変更でcommitしたかがわかる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/1e0782e8-c063-18bf-84b2-6654693cacb7.png)
>1 file changed,　0 insertions(+), 0 deletions(-)

と出ているが、これはファイルを1つ変更しました。という意味だ。

```Git:commit
■ VScode側でコメントをつけてcommitする方法
git commit 
```
commitの後に何もつけずにコミットする、そうすると
>hint: Waiting for your editor to close the file...

と表示され、VScodeが表示され、エディターに「コメントをつけてcommitして」と表示されますので
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/168708f7-789f-2f19-4a9c-468e49a0a18c.png)



虫眼鏡アイコンの下にある（なんていうのこのアイコン？）アイコンをクリックすると左側のエディタが切り替わりますので、ステージング済みの変更ファイルがあることが確認できます。
これはaddしてまだコミットされてないファイルを示しています。
これをコミットするには、「ソース管理：Git」の文言右にある「✔」をクリックして、コメント入力してEnterでcommitが完了します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/46a02fc5-6dc6-0564-b695-bb09f0487200.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/9d7aafe6-2244-8acd-0ed2-181e88109fb5.png)

git status で状態を確認すると以下のようになり、commitするものはありません、出れば無事commitが完了です。
>On branch VBA_CRUD
>nothing to commit, working tree clean

ここまでの流れを図にまとめるとこうなる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/1acef048-8e75-3b25-14af-94dfc33bfda3.png)

##他にも知っておくと便利なgitコマンドを紹介しておく。

- <b>git revert</b>

既存コミットの取り消し、コミットを取り消すコミットとなるため、「取り消した」という履歴を残すことが出来る。

```Git:revert
git revert ハッシュされた文字列
```
ハッシュ文字列とはgit logコマンドで表示されるcommit以下の文字列である。
ハッシュ文字列を指定することで、指定したコミット時点まで戻すことが出来る。
履歴を残すという観点から言うと、「ハッシュ文字列に指定した位置までコミットする」が正しいだろうか。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/b6f36307-7e53-28e4-24c2-526eb1bd8582.png)

-  <b>git reset</b>

git revert と似ているが若干意味合いが異なる。
「reset」はコミット自体をなかったことにする。「revert」は取り消しましたよ、のログを残したが、こちらはログが残らない。
用途としては、今コミットしたが内容が誤っていていた、などの場合は直前取り消し、
過去（既存）にコミットしてあった内容が誤っていた、などの場合はハッシュ文字列を指定してコミットの取り消しを行うようだ。

```Git:reset
git reset --hard HEAD^ 直前コミットの取り消し
git reset --hard ハッシュ文字列
```

#ブランチについて
ブランチって？という方に向けて、ブランチについても簡単に説明したいと思う。
ブランチ「枝」のことです。
gitはツリー上にファイルが存在していて、木から枝を生やしてファイル管理することが出来る。
木が<b>master</b>だとしたら、枝は<b>branch</b>である。
masterとbranchの意味合いは以下の通りである。

- [x] master
完成版のファイルおよびソースなどをコミットする場所
現在本番稼働しているソース、といった方がシックリくるか。

- [x] branch
 バックアップも兼ねて、branchを切って(branchを作ることをbranchを切るという)保管しておくこともあれば、機能追加改修があり、masterとは別の保管庫に開発中のソース(ファイル)を置いておく場所

##branchのイメージ

- 緑が木:master
- ピンクが枝:branch

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/1a332635-1e11-ca17-12e9-45b029c3bdb6.png)

yamada devというbranchを切って、masterとは別に管理し、yamadaさんが追加改修を行っておくととする。
そうすることで、本番稼働しているソースとは別に管理が可能だ。
では、追加改修が完了し、いよいよ改修したものを本番稼働させる場合のソース管理はどうするか？そう。masterに結合:maergeさせるのだ。

#margeのイメージ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/96c6bf14-2ad6-5fd5-a870-68f17644a7e1.png)

現行で本番稼働していたソースに対して新たに追加改修を行っていたyamada devからmasterへmargeすることで、追加改修が行われた新たな本番稼働用のソースをmasterへ適用させる。
これがmasterとbranchを分けて行う最大のメリットである。
#branch操作
```Git:branch
//➀ブランチの作成
git branch ブランチ名
//➁現在いるブランチの確認
git branch 
//➂ブランチを移動
git checkout ブランチ名
//➃結合　結合したいbranchにcheckout後、以下のコマンドを入力する
git marge マージしたいブランチ名
```
②の現在いるブランチの確認をすると以下のような形で、*がついて「VBA_CRUD」というbranchにいますよ、というのがわかる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/196c2b99-f7d3-83bf-e8f1-4e3c4ff892bf.png)
③ブランチ名を指定することで、その指定のブランチに移動することが出来る。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/2f113463-4421-d4f6-2afd-38f555a37daa.png)
>Switched to branch 'master'

と表示されこれはmasterブランチに移動しましたよ、という意味だ。
ここで再度git branchをコマンドに入力すると、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/379725/b649ff47-b52a-e42c-b473-42ade22ad85f.png)
masterに「*」が移っているのがわかる。ちゃんとmasterへ移動出来た証拠だ。
最後に、結合したいbranch名にcheckoutして（今回の例ならVBA_CRUDにcheckoutして）margeをすれば、masterへの結合は完了する。

#最後に
ここまで<b>git init ⇒ git commit</b>、また<b>branch</b>までの一覧の流れを記載した。
ローカルでの環境は整ったが、リモートリポジトリの環境整備についても説明しなければいけない。それは次回に持ち越しし、ご説明できればと思います。
また、ほんとに最後にこんなことを言うのもなんですが、Gitはあまりマクロ等のファイルを管理すること適切ではないそうです…。

なぜか？
Gitは最終的にGitHubとよばれるネットワーク側に存在するリポジトリに過去のファイルもすべて履歴として保管する為、ネットワークからローカルへ取得しようとすると膨大な量のファイルを取得することになるため、落とし込みに非常に時間がかかってしまうから、のようです。
web系エンジニアさんはPHPやHTML、CSSその他諸々のファイル管理になりますから、ファイルの容量的にはそこまで膨れ上がらない？から相性も良いのでしょうか。


今回はここまで解説させていただきました。
見ていただた方、ありがとうございます。



#参考にさせていただいた記事
- [【GitHub超初心者入門】この前初めてGitHubを使い始めたエンジニア見習いが書くGitHubの使い方と実践～とりあえず一緒に動かしてみようぜ！～](https://qiita.com/nnahito/items/565f8755e70c51532459)
- [君には1時間でGitについて知ってもらう(with VSCode)](https://qiita.com/jesus_isao/items/63557eba36819faa4ad9)
- [【gitコマンド】いまさらのrevert](https://qiita.com/chihiro/items/2fa827d0eac98109e7ee)