はじめに

Gitを使ってる際に、コミット前に静的チェックを実施するためにあれこれ調べたので、記事にまとめました。

この記事で得られること

• Gitコマンドの前に特定の処理を挟む方法

最終的な成果物

package.jsonに下記を指定することで、git commit前に静的チェック(lint)を実行できる。

package.json

  "husky": {
    "hooks": {
      "pre-commit": "npm run lint"
    }
  },

環境/前提

• 上記ライブラリがインストールされていること。

Gitのコマンドを検知する仕組み

最初に、Gitのコマンドを検知する仕組みについて紹介します。

Gitには、Gitの特定アクションを検知してカスタムスクリプトを叩く仕組みである「Gitフック」が提供されています。
この「Gitフック」を利用することで、gitコマンド実行時に処理を割り込ませることができます。

https://git-scm.com/book/ja/v2/Git-のカスタマイズ-Git-フック

Gフックの例

フック	タイミング
pre-commit	コミットメッセージが入力される前に実行
prepare-commit-msg	コミットメッセージエディターが起動する直前、デフォルトメッセージが生成された直後に実行
post-commit	コミットプロセスが全て完了した後

Gフックを利用したnpmパッケージ

Gフックを利用して、特定処理を挟むサポートをしてくれるパッケージは主に下記があります。
・GHooks(https://github.com/ghooks-org/ghooks)
・Husky(https://github.com/typicode/husky#readme)
・Pre-Commit(https://github.com/observing/pre-commit)

パッケージを比較してみると、Huskyが最も人気がありアップデート頻度も高いので、Huskyで実装していきます。

https://www.npmtrends.com/git-hooks-vs-husky-vs-pre-commit

手順

huskeyのインストール

下記コマンドを実行し、huskeyをインストールする。

npm install husky --save-dev

参考
https://typicode.github.io/husky/#/?id=manual

package.jsonに、Gフックとコマンドを設定

下記のように、package.jsonに"husky"の設定を追記すればOKです。

例：git commit前にnpm run lintを実行する。

package.json

  "husky": {
    "hooks": {
      "pre-commit": "npm run lint"
    }
  },

まとめ

huskyを使えば、簡単に任意のコマンドをGitの特定アクション前後に挟むことができます。

前提条件

• 既にメインのGitHubを持っていて、gitbashと連携している
• 新しいGitHubアカウントがすでにある(ない場合は作成してから)
• 既にあるGItHubアカウントをGit-old、新しいGItHubアカウントをGit-newと呼ぶことにする

ファイルの確認

　1.Git-oldで使っているssh鍵の場所の確認

gitbash

$ cd ~/.ssh
$ ls -l
id_rsa  id_rsa.pub  => Git-oldのssh鍵

　2.Git-newのssh鍵を作成するフォルダ(フォルダ名を任意にaaaに入れて使用)の作成

gitbash

$ mkdir ~/.ssh/aaa

Git-newのssh鍵を作成

gitbash

$ ssh-keygen -t rsa -b 4096 -C {Githubメールアドレス} -f ~/.shh/xxx/id_rsa

鍵の確認

gitbash

$ ls ~/.ssh/aaa/
id_rsa  id_rsa.pub  => Git-newのssh鍵

作成したssh鍵をGItHubに登録

gitbash

$ clip < ~/.ssh/aaa/id_rsa.pub

コピーしたものをGItHubのssh kyesに貼りつけ登録

~/.ssh/configを作成

configファイルがなかったら作成

gitbash

$ touch ~/.ssh/config

configファイルを編集

~/.ssh/config

Host github.com-old
  HostName github.com
  User git
  Port 22
  IdentityFile ~/.ssh/id_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes
Host github.com-new
  HostName github.com
  User git
  Port 22
  IdentityFile ~/.ssh/aaa/id_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes

Hostの部分は自由に変えてください。あとで使います。

sshの接続確認

gitbash

$ ssh -T git@{configファイルのHostの部分}
Hi {GitHubの名前}! You've successfully authenticated, but GitHub does not provide shell access. => 成功

Git-newにpushする方法

pushしたいディレクトリで行うこと

gitbash

$ git init

$ git remote add origin git@{configファイルのHostの部分}:{GitHubの名前}/{リモートリポジトリの名前}.git

$ git add -A && git commit -m "xxx" && git push origin master

この記事について

この記事は、開発未経験の人間がインプットした内容が書かれています。
実際に開発経験を積まないと身につかない、かといって疎かにしたら後々痛い目にあう、といったジレンマを少しでも解消するために、「頭の中を言語化し、解釈違いを指摘してもらう」という手段を取ることとしました。
気になる点がありましたらツッコミをいただけると嬉しいです。

記事の内容

VCSの基礎知識。Gitの運用の流れ。個人開発と複数人での開発の違いと注意点。

インプット教材

introduction-to-vcs: https://github.com/masaru-b-cl/introduction-to-vcs
introduction-to-git: https://github.com/yamataku29/introduction-to-git

開発環境

git version 2.21.0

VSCとは

VCS（ヴァージョン管理システム/Version Control System）。ファイルやディレクトリの変更をバージョンとして管理する概念のこと。

VSCの強み

• 履歴が残る
  • 作業した内容を記録として残せる。
  • その時点の状態に戻すことができる。
  • 別の作業をするために分岐することができる。
• 競合を防ぐ
  他の作業者の変更内容を消して自分が行った変更内容を反映することができないので、競合による不具合の発生を防ぐ。

気をつけるべきこと

以下の項目に注意し履歴を残す。

• 時間ではなく作業単位で行う
• 変更する理由を明記する（変更内容は自動で記録されるが、変更した理由は明記しないとわからない）
• 動かないものは履歴に残さない（あくまで成果物として残す）
• 一つの履歴に一つの変更（複数の履歴を一度に残すと、それぞれの変更箇所がどの仕様によるものかが分からない）

Gitとは

VCSの一つで分散VCSと呼ばれている。作業者全員が一つのリポジトリを共有するVCSに対し、分散VCSは各人にレポジトリがあり、作業者間で変更内容を共有したりできる。また、競合が発生したらエラーで教えてくれる機能がある。

Git運用

リポジトリの作成から最初のコミットまで

• my_first_workspaceという作業ディレクトリに対応するリポジトリは、 my_first_workspace/.git に作られる

$ mkdir introduction-to-git
$ cd introduction-to-git/
$ mkdir my_first_workspace
$ cd ./my_first_workspace/
$ git init
Initialized empty Git repository in /Users/username/introduction-to-git/my_first_workspace/.git/
$ ls -a
.   ..  .git ←これ

• 作業ディレクトリで作業しただけでは、コミットしたときに Git はその変更内容をリポジトリに登録していいのかどうかわからないので、git add などのコマンドをつかって、変更したファイルをstage areaに置く(staging)

nyan.txtを新規作成し、git statusでgitの状態を確認。

$ vim nyan.txt
$ git status
On branch master

No commits yet  "まだコミットされていない"

Untracked files "追跡されていないファイル":
  (use "git add <file>..." to include in what will be committed)
　"git add <file>を使ってコミットできる"
    nyan.txt

nothing added to commit but untracked files present (use "git add" to track)
"コミットできるものはないが、追跡されてないファイルがある"

git addを実行し、再度gitの状態を確認。
一度ステージングされたファイルを却下したい場合は、git rm --cachedなどのコマンドを使ってstage areaから下ろす（unstageing）ことができる。

$ git add nyan.txt
$ git status
On branch master

No commits yet

Changes to be committed:  "コミットできる変更箇所"
  (use "git rm --cached <file>..." to unstage)
  "use git rm --caches <file> でunstage"
    new file:   nyan.txt

git commit を行うと、エディタが立ち上がるのでコミットメッセージを書いて保存、終了する。すると、stage areaに上がっていた変更内容がコミットメッセージとともにリポジトリに反映される。このとき、staging されていたファイルの内容とコミットメッセージは「コミットオブジェクト」としてリポジトリ内に保存されている。

コミットメッセージを入力してコミット実行。その後、gitの状態確認。

$ git commit -m "nyam.txt 新規作成"
[master (root-commit) ef83816] nyam.txt 新規作成
 1 file changed, 1 insertion(+)  "1ファイル変更、1行変更"
 create mode 100644 nyan.txt

$ git status
On branch master
nothing to commit, working tree clean  "コミットするものはない、稼働ツリーはクリーンな状態"

コミットされるときの内部の動き

コミット時、リポジトリには新しい「コミックオブジェクト」が生成される。
コミックオブジェクトには、ステージングされたファイルの内容　＋　コミットメッセージ　が格納されている。
コミットオブジェクトにはIDがあり、git log等のコマンドで確認できる。
commitの後に続く長いコードがIDである。

$ git log       
commit ef83816cf5a8f0f5e18cf6b2cf692d0fd1bd114b (HEAD -> master)
Author: YUUSUKE <yuusuke@example.com>
Date:   Thu Feb 25 10:31:46 2021 +0900

    nyam.txt 新規作成

コミットの親子関係

• コミットには親子関係がある
  変更前のコミットが親、変更後のコミットが子、という関係がある。親の内容と子の内容の差分が変更点として記録されている。

• コミットオブジェクトには「親コミットはどれか」という情報と、「この瞬間のファイルの状態」という情報が入っている。

nyan.txtの中身のテキストを「nyan」から「mew」へ変更。その後、git log --graphで確認。
親コミット（変更前のコミット）と比べると、"nyan"というテキストの行が無くなり、"mew"というテキストの行が増えた（＝変更された）。

$ git commit -am "nyan.txt の中身をmewに変更"
[master ae3cd98] nyan.txt の中身をmewに変更
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git log
commit ae3cd98b4d5f6b5100d4cb2f46ee94576e75cc02 (HEAD -> master)
Author: YUUSUKE <yuusuke@example.com>
Date:   Thu Feb 25 10:55:41 2021 +0900

    nyan.txt の中身をmewに変更

commit 87bdcd5c72a7c50fe412977535507120d032abe7
Author: YUUSUKE <yuusuke@example.com>
Date:   Thu Feb 25 10:31:46 2021 +0900

    nyan.txt 新規作成

• これらのふたつの情報を比べることによって、Gitはいつでも「その2つのコミットの間にどのような変更が行われたか」を知ることができる。

gitで管理しているファイルのリネーム、移動

• ファイルのリネームとは、名前を変更しているだけのように見えるが、実際の動きは変更前のファイルを削除し、変更後のファイルを新しく作成している。また、ファイルの移動も、移動元にあるファイルが消え、移動先にファイルが作成されている。
• ファイルをリネームや移動を行う際は、すでにgitの管理下にあるファイルについては本来のコマンドの前にgitを入れる。そうすると、「gitの管理下のファイルを操作する」という処理になり、直接コミットができる。gitを入れ忘れると、変更後のファイルがUntrack（gitの管理下にない）なファイルとみなされ、再度stagingが必要になる。

nyan.txtとwan.txtのファイル名を変更。

$ git mv nyan.txt mew.txt   gitを入れて操作するとそのままstagingされる。
$ git mv wan.txt baw.txt
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    wan.txt -> baw.txt
    renamed:    nyan.txt -> mew.txt

$ git commit -m "ファイル名変更"
[master 656f0db] ファイル名変更
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename wan.txt => baw.txt (100%)
 rename nyan.txt => mew.txt (100%)

brunch -ブランチ-

• git のブランチは「コミットオブジェクトを指し示すポインター」である

コミットオブジェクトを一覧表示する。一番上の（最新の）コミットオブジェクトにmasterブランチが指し示されている。

$ git log --oneline
656f0db (HEAD -> master) ファイル名変更
bb7330b 削除依頼が来たためboo.txtを削除
d42d145 wan.txt, boo.txt作成
ae3cd98 nyan.txt の中身をmewに変更
87bdcd5 nyan.txt 新規作成

• リポジトリには最初から「master」というブランチが存在している。 リポジトリを作成した時にGitが自動で作成している。
• HEAD という特殊なブランチも存在していて、このブランチは「現在選択しているブランチ」を指している
• git branch new_branch_name とすることで、新しいブランチを new_bnrach_name という名前で作成することができる。作成時に現在選択しているブランチが指しているのと同じコミットオブジェクトを指す。

新しいブランチmy_first_branchを作成し移動する。ログを確認すると、現在指定しているブランチであることを示す「HEAD」が新しいブランチを指している。

$ git branch my_first_branch   ブランチ作成
$ git checkout my_first_branch　　ブランチに移動
Switched to branch 'my_first_branch'
$ git branch　　ブランチの一覧と現在指定しているブランチを表示
  master
* my_first_branch

$ git log --oneline
656f0db (HEAD -> my_first_branch, master) ファイル名変更
bb7330b 削除依頼が来たためboo.txtを削除
d42d145 wan.txt, boo.txt作成
ae3cd98 nyan.txt の中身をmewに変更
87bdcd5 nyan.txt 新規作成

• 新しくコミットすると、現在のブランチがそのコミットオブジェクトを指すようになり、コミット前に指していたコミットオブジェクトが親となる。

masterブランチ、my_first_branchブランチでそれぞれ作業を実施。作業したコミットオブジェクトにそれぞれのブランチが指されている。また、「ファイル名変更」のコミットオブジェクトが親となり、そこから分岐しているのがわかる。

$ git graph
* bd85cc0  (HEAD -> my_first_branch) 猫の鳴き声を増やした
| * 03e1092  (master) 犬の鳴き声を追加
|/  
* 656f0db  ファイル名変更
* bb7330b  削除依頼が来たためboo.txtを削除
* d42d145  wan.txt, boo.txt作成
* ae3cd98  nyan.txt の中身をmewに変更
* 87bdcd5  nyan.txt 新規作成

marge -マージ-

• git merge branch_name で、今選択されているブランチに branch_name という名前のブランチのコミット内容を取り込むことができる

masterブランチが指しているコミットオブジェクトにmy_first_branchブランチが指しているコミットオブジェクトをマージする。

$ git co master
Switched to branch 'master'
$ git merge my_first_branch
Merge made by the 'recursive' strategy.
 mew.txt | 1 +
 1 file changed, 1 insertion(+)

• マージするときには「マージコミット」という特殊なコミットが行われ、マージコミットのコミットオブジェクトは親をふたつ持つ

「犬の鳴き声を追加」と「猫の鳴き声を増やした」の2つのコミットオブジェクトの内容が混ざったマージオブジェクトが完成。

$ git graph
*   5965361  (HEAD -> master) Merge branch 'my_first_branch'
|\  
| * bd85cc0  (my_first_branch) 猫の鳴き声を増やした
* | 03e1092  犬の鳴き声を追加
|/  
* 656f0db  ファイル名変更
* bb7330b  削除依頼が来たためboo.txtを削除
* d42d145  wan.txt, boo.txt作成
* ae3cd98  nyan.txt の中身をmewに変更
* 87bdcd5  nyan.txt 新規作成

• git branch -d branch_name とすることで、branch_name という名前のブランチを消すことができる

$ git br -d my_first_branch
Deleted branch my_first_branch (was bd85cc0).

$ git br
* master

• masterブランチはデータの最終リリースとして保存した方が良い。なにか作業を行うときはmaster以外のブランチで作業する。

新しい作業用ディレクトリmy_second_workspaceを作成。
猫の愛でるファイルと猫を嫌うファイルを作成しコミット（master）。
修正する必要があるため、新しいブランチunify_stylesを作成し、そこで修正する。

$ mkdir my_second_workspace
$ cd my_second_workspace/
$ git init
Initialized empty Git repository in /Users/username/introduction-to-git/my_second_workspace/.git/

$ vim cat_lover_said.txt
$ vim cat_hater_said.txt
$ git add .
$ git c
[master (root-commit) 4d50277] 猫好きの話と犬好きの話を作成
 2 files changed, 32 insertions(+)
 create mode 100644 cat_hater_said.txt
 create mode 100644 cat_lover_said.txt

$ git br unify_styles
$ git co unify_styles
Switched to branch 'unify_styles'

$ vim cat_lover_said.txt
$ vim cat_hater_said.txt
$ git c -am "文体を統一"
[unify_styles a6a4ce3] 文体を統一
 2 files changed, 6 insertions(+), 9 deletions(-)

• 「分岐」してないブランチをマージするときには Fast-foward という手法が取られる。Fast-foward だと、マージコミットは作られず、たんにブランチが進められる

2つのファイルの中身を見ると、文中に「頭おかしい」という表現があり、修正が必要。
新しいブランチhotfixを作成し、そこで修正。修正後masterブランチにマージ。
ログを確認すると、単にmasterブランチが移動しているのがわかる。

$ git co -b hotfix
Switched to a new branch 'hotfix'
$ git br
* hotfix
  master
  unify_styles

$ vim cat_hater_said.txt 
$ vim cat_lover_said.txt 
$ git c -am "頭がおかしいという表現はまずいので修正"
[hotfix 9cfca6a] 頭がおかしいという表現はまずいので修正
 2 files changed, 3 insertions(+), 3 deletions(-)

$ git graph
* 9cfca6a  (HEAD -> hotfix) 頭がおかしいという表現はまずいので修正
| * a6a4ce3  (unify_styles) 文体を統一
|/  
* 4d50277  (master) 猫好きの話と犬好きの話を作成

$ git co master
Switched to branch 'master'
$ git merge hotfix
Updating 4d50277..3aee339
Fast-forward
 cat_hater_said.txt | 2 +-
 cat_lover_said.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

$ git graph
* 3aee339  (HEAD -> master, hotfix) 頭がおかしいという表現はまずいので修正
| * a6a4ce3  (unify_styles) 文体を統一
|/  
* 4d50277  猫好きの話と犬好きの話を作成

• Fast-foward したくないときには --no-ff というオプションを付ける

git reset --hard commitIDで過去のコミットオブジェクトに戻る。
オプションをつけて再度マージする。

$ git reset --hard 4d50277
HEAD is now at 4d50277 猫好きの話と犬好きの話を作成

$ git graph
* 3aee339  (hotfix) 頭がおかしいという表現はまずいので修正
| * a6a4ce3  (unify_styles) 文体を統一
|/  
* 4d50277  (HEAD -> master) 猫好きの話と犬好きの話を作成

$ git merge --no-ff hotfix
Merge made by the 'recursive' strategy.
 cat_hater_said.txt | 2 +-
 cat_lover_said.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

$ git graph
*   175944b  (HEAD -> master) Merge branch 'hotfix'
|\  
| * 3aee339  (hotfix) 頭がおかしいという表現はまずいので修正
|/  
| * a6a4ce3  (unify_styles) 文体を統一
|/  
* 4d50277  猫好きの話と犬好きの話を作成

• マージしたときに競合（conflict）が発生した場合には、手動でマージする

unify_stylesブランチでファイルを修正しコミット。
masterに戻り、unify_stylesをマージしようとしたらエラーが起きた。
unify_stylesブランチで修正したファイルの行とmasterにマージされたhotfixブランチで修正したファイルの行が同じであるため、競合が発生。

$ git co unify_styles
Switched to branch 'unify_styles'
$ vim cat_hater_said.txt 
$ git c -am ""ヘッヘッヘッヘッ" という表現は残すようにした"
[unify_styles 6119bc1] ヘッヘッヘッヘッ という表現は残すようにした
 1 file changed, 2 insertions(+), 1 deletion(-)

$ git co master
Switched to branch 'master'

$ git merge unify_styles
Auto-merging cat_lover_said.txt
CONFLICT (content): Merge conflict in cat_lover_said.txt
Auto-merging cat_hater_said.txt
CONFLICT (content): Merge conflict in cat_hater_said.txt
Automatic merge failed; fix conflicts and then commit the result.

ファイルを手動で修正しgit statusで確認。

$ vim cat_hater_said.txt 
$ vim cat_lover_said.txt 

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:   マージされていないパス
  (use "git add <file>..." to mark resolution)  

    both modified:   cat_hater_said.txt
    both modified:   cat_lover_said.txt

add&commitでマージ完了。マージされていない状態の時はコミットすればマージも完了される。

$ git add .
$ git c
[master 70b3611] Merge branch 'unify_styles'

$ git graph
*   70b3611  (HEAD -> master) Merge branch 'unify_styles'
|\  
| * 6119bc1  (unify_styles) ヘッヘッヘッヘッ という表現は残すようにした
* |   175944b  Merge branch 'hotfix'
|\ \  
| * | 3aee339  頭がおかしいという表現はまずいので修正
|/ /  
| * a6a4ce3  文体を統一
|/  
* 4d50277  猫好きの話と犬好きの話を作成

リモートリポジトリ

• 共有リポジトリを作成し運用する場合、自分のリポジトリのデータを反映したり、逆に共有リポジトリのデータを反映させるためには、共有リポジトリをリモートリポジトリとして登録する必要がある。
  • たかしさんとゆうすけさんのそれぞれの作業ディレクトリを作成し、お互いのデータを共有するためのリポジトリを作成。先にたかしさんの作業ディレクトリと作業ファイル、masterブランチとは別の開発用ブランチを作成し、そのクローンを共有リポジトリにする。
  • 共有リポジトリのクローンをゆうすけさんのディレクトリに作成。
  • ブランチまでは複製されていないため新しく作る必要があるが、リモートリポジトリのブランチorigin/branch_nameと関連付けないと反映したりできない。

gitを初期化し、ユーザー登録
$ mkdir takahashi
$ cd takahashi/
$ git init
Initialized empty Git repository in /Users/kudokoki/introduction-to-git/my_third_workspace/takahashi/.git/
$ git config --local user.name Takahashi
$ git config --local user.email takahashi@example.com

ファイル作成
$ vim cat_lovar_said.txt
$ git add .
$ git c
[master (root-commit) a38177b] 猫好きの話を追加
 1 file changed, 15 insertions(+)
 create mode 100644 cat_lovar_said.txt

開発用ブランチ
$ git br development

たかしさんのディレクトリをクローンし、共有リポジトリにする。
git clone <クローンしたいデータ> <クローンデータのパス>
共有リポジトリは直接いじらないので作業ディレクトリは不要。
--bare オプションはリポジトリのみを複製できる。
$ cd ../
$ git clone --bare ./takahashi/ ./shared_repo.git
Cloning into bare repository './shared_repo.git'...
done.

共有リポジトリのクローンをゆうすけさんのディレクトリに生成
--bareをつけずにクローンすると作業ディレクトリも生成される
$ git clone ./shared_repo.git/ ./yuusuke
Cloning into './yuusuke'...
done.

developmentブランチはクローンされない
$ git br
* master
$ git graph
a38177b  (HEAD -> master, origin/master, origin/development, origin/HEAD) 猫好きの話を追加

developmentブランチをリモートリポジトリのブランチと関連付けて作成
git branch <作成したいブランチ名> <関連付けたいブランチ名>
クローンした時に、デフォルトのリモート登録名はoriginになっている
$ git br development origin/development
Branch 'development' set up to track remote branch 'development' from 'origin'.

• クローン元のリポジトリはクローン先のそれと関連付けられていないため、別途登録する必要がある。
  • リモートリポジトリの登録
  • リモートリポジトリのブランチを生成
  • リモートリポジトリのブランチと関連付ける

リモートリポジトリの登録
git remote add <登録名> <リモート先のパス>
$ git remote add origin ../shared_repo.git
$ git remote
origin

ブランチ作成
git fetch <登録名>　でリモートレポジトリのブランチを呼び出して生成
$ git fetch origin
From ../shared_repo
 * [new branch]      development -> origin/development
 * [new branch]      master      -> origin/master

リモートリポジトリのブランチと関連付ける
git branch --set-upstream-to=<リモートリポジトリのブランチ> <関連付けたいブランチ>
$ git branch --set-upstream-to=origin/master master
Branch 'master' set up to track remote branch 'master' from 'origin'.
$ git branch --set-upstream-to=origin/development development
Branch 'development' set up to track remote branch 'development' from 'origin'.

pushとpull

• リモートリポジトリに手元の変更を反映したいなら、git push
• 追跡ブランチに対しての変更はそのまま git push 新しいブランチを作りたいなら git push ＜リモートリポジトリの名前＞ ＜手元のブランチ＞:＜リモートのブランチの名前＞
• ブランチを削除したいなら git push ＜リモートリポジトリの名前＞ :＜リモートのブランチの名前＞
  • リモートリポジトリから手元に変更を持ってきたいなら git fetch
  • リモートリポジトリのコミットとブランチを持ってくる
  • リモートリポジトリのブランチはリモートブランチとして作られる
• fetch のついでに merge も一緒にやりたいなら、git pull
• git pullを成功するには以下の条件を満たす必要がある。
  • リモートリポジトリが、bare リポジトリである
  • リモートリポジトリへの書き込み権限を持っている
  • 手元のリモートブランチがリモートリポジトリに「追いついて」いる
  • すでにリモートリポジトリに push 済みのコミットが、手元のリポジトリで改変されていない
    

初学者です。
GitHubを使って1ヶ月くらいになりますが、理解しきれてないとこがあるので纏めがてら記述します。
※アカウントの登録法、操作方法などを記述したものではありませんので悪しからず。

追記：随時追加していきます。

GitとGitHubとは？

Git

ソースコードなどのファイルやフォルダの変更履歴を記録・追跡するためのバージョン管理システム。
Gitでアプリを管理すると、それぞれの開発段階でセーブポイントを作れる！
時系列に沿って管理してくれるため、ポイントごとに遡ることもできる。

初期(ベース)・セーブ!　▶︎　フロント実装・セーブ！　▶︎最新版・セーブ！▶︎...みたいな

これだけでも便利なのはわかったけれど、チーム開発することを想定するとさらに力を発揮できる！

< 複数人で開発するときの問題 >
資料を受け渡す時にメールでやりとりするのは大変...
また、同じファイルを複数人で編集したい場合に、誰かがそのファイルを編集し終わるまで手が出せなくなる...と、問題がいくつか出てくる。

以上のことから、「同じプログラムのファイルを複数人で編集する」を実現・解決してくれるのがGitHub！

GitHub

Gitの仕組みを利用して、簡単に複数人での開発ができるWebサービスのこと。

GitHubの公式サイト(登録ページ)

実装中のコードを共有し、コメントをもらうこともでき、実際の現場でも活用されている。
また、SlackやCircleCIなどと連携することもできてかなりの強者。

リポジトリ

Gitの管理下にあるファイルやディレクトリの変更履歴を残しておく箱のようなもの。
Gitの中に、自分がこれから作るアプリをディレクトリごとぶっ込んで、変更履歴を記録・追跡するためのバージョン管理を指定するみたいなイメージ。

リポジトリには、ローカルリポジトリとリモートリポジトリがある！

ローカルリポジトリ

自分が今使ってるパソコン上(ローカル環境)においているリポジトリのこと。
リポジトリを作っても、自分のパソコンの中にあるため、ファイルやディレクトリを変更、修正した際は好きなタイミングで記録できる。

リモートリポジトリ

リモートリポジトリはローカルの真逆。外部サーバー上に置くリポジトリのこと。
作成した箱がインターネットを通して別の場所に作られているイメージ！

外部サーバーにある=他の人に自分のコードを共有できる！
つまり、複数人(チーム)で開発する時に使うのがリモートリポジトリ！

ローカルと違うのは、直接の変更修正ができない。一旦ローカルでいじった後、同期して修正するという流れになる。

ローカルリポジトリを作ったら、そのアプリの現状を保存させる。
その保存作業で必要になるのがcommit。

commit(コミット)

ファイルやディレクトリの変更修正を、リポジトリに記録すること。
commitをすることで、変更修正の時系列の管理が行いやすくなり、変更修正を遡る事が可能に！

< コミットの粒度 >
commitをするにあたって、どの程度の頻度で記録していくかは悩みどころ。

粗いコミット
ユーザー管理機能
投稿機能
編集機能

細かいコミット
ユーザー管理機能　ルート
ユーザー管理機能　コントローラー
ユーザー管理機能　ビュー

比較すると、やはり細かい方がわかりやすい。
極力、作業の節目ごとにするといいのかと。

コミットメッセージ

commitには、それぞれ「なんの変更修正なのか？何をしたのか？」をわかるように題名をつける。中身をいちいち確認せずともわかりやすくするため。(目次みたいなイメージ)
※企業によっては英語表記で、というとこもあるそうな。。

ちなみに、commitは初期段階の、アプリを立ち上げた時点で最初のコミット(first commit)をしておく。
※初期状態の把握のため。

commit log

今まで行ったcommitの履歴が確認できる。
commit logによってアプリケーションの実装の過程を振り返り、実装を戻す際も、どこのcommitの段階まで戻るべきかがわかる。

インデックス

変更修正が一時的に保存される場所。インデックスに保存されている内容がcommitの対象になる。

add (アド)

インデックスに登録して、コミットの対象にすること。(チェックマークをつける、外すで決められる)
直訳でaddは「追加」。

push (プッシュ)

ローカルリポジトリでのコミットをリモートリポジトリに反映する。

このpushから先(リモートに反映していく作業)は、個人的にかなり
慎重になった方がいいかなと。
GitHubDesktopを使っていると、とりあえず上のボタンポチポチしてたけど、必ず表記と意味を調べてからポチること。

はじめに

Gitの概念って理解するのが大変ですよね。
私は最近コンフリクトを起こしてしまい、
早くプロジェクトを勧めたいのにGitに時間をとられてしまいました。

もう少しわかりやすく学習できる方法はないのかな・・・
と思っていたらGitを学べるゲームがありました。

ダウンロード

下記のページからWindows, Linux, MAC版がダウンロード出来ます。
https://blinry.itch.io/oh-my-git

遊び方

ゲームを起動したら"Levels"を選択、学びたいレベルを選択します。

• 赤背景の文字がミッションです。
  各ミッションはクリアすると緑色に変わり、LEVELの全てのミッションを達成するとLEVELクリアです。

• 画面中央がブランチツリーで四角い正方形がコミット、キャラクターがいるコミットがHEADです。

• gitコマンドの書いてあるカードをドラッグまたは右下のボックスにgitコマンドを入力、
  ミッションの下に表示された各ファイルを開き、編集してクリアを目指しましょう。

コマンドの使い方

• コマンドを入力すると表示されるスニペットはtabキーで選択が出来ます.
• コミットのハッシュ値の取得はコマンド入力中に黄色い正方形(コミット)をMACなら２本指タップ、恐らくWindowsであれば右クリックで出来ます。

カードを使わずにコマンドのみでLEVELをクリアするとLEVELS画面に称号(マーク)が付きます。

参考

https://ohmygit.org/
https://github.com/git-learning-game/oh-my-git
https://labs.cybozu.co.jp/blog/akky/2021/02/oh-my-git-learning-game/の

リモートブランチをいくつか使って開発をするとき、それぞれfetchするのがだるいなと思ったら --all つけたらいい感じにじゅんぐりfetchしてくれて便利だった。
リモートで消えたブランチをローカルで消してくれる -p も便利で、組み合わせて基本これを使うことにしよう。

git fetch --all -p

しあわせ〜

リモートブランチをいくつか使って開発をするとき、それぞれfetchするのがだるいなと思ったら --all つけたらいい感じにじゅんぐりfetchしてくれて便利だった。
リモートで消えたブランチをローカルで消してくれる -p も便利で、組み合わせて基本これを使うことにしよう。

git fetch --all -p

しあわせ〜〜〜