1,gitコマンド入門
1-1,gitの設定とコミットまで(ローカル編)
1-1-1,gitで一番最初にやること
ローカルにgitの設定をします。
//はじめる
git init
//e-mailとユーザー名の設定
git config --global user.name ユーザー名
git config --global user.email メールアドレス
//確認
git config --list
/* こんな感じの設定が出来ているはず
* user.name=ユーザー名
* user.email=メールアドレス
*/
ちなみに、ここで設定したものは~/.gitconfigに以下のように保存されています。
[user]
name = ユーザー名
email = メールアドレス
1-1-2,変更をコミットする
以下、ローカルでコードを変更(修正)をした後〜変更をローカルでコミットするまでのコマンドになります。
gitにはワーキングツリー(今作業している場所)とステージング(インデックス)と呼ばれるどの変更差分を反映するかを登録する場所があります。
変更を登録するまでの流れとしては
1,変更差分をみて、
2,変更するファイルを選んでステージングに追加して、
3,変更を確定する。
です！
//ファイルの更新状況の確認
git status
//変更差分の確認
git diff
//変更をなかったことにしたいファイルがある場合(ファイルの変更差分を削除)
git checkout ファイル名
//ステージングに追加(変更したいファイルの選択)
ファイルを指定してステージングに追加したい場合
git add "ファイル名"
全てのファイルを追加する場合
git add --all
//変更差分の確定
git commit -m "コミットメッセージ(なぜその変更をしたのか)"
コミットをする（変更を確定する）だけなら
git add --all
git commit -m "なぜその変更をしたのか"
で可能ですが、コミットをする前には変更差分を確認することが望ましいです。
確認せずにコミットしてしまうと不要な変更分が間違ってコミットされてしまったり、コードのインデントがずれているのに気づかないなどの問題が起きます。
不要な変更差分を修正してまたそれをコミットすると、コミットの履歴(後述)に本質的ではない変更が多く含まれてしまい、履歴が見にくくなってしまいます。
1-1-3,コミット履歴の確認
コミットの履歴に関しては
//コミットの履歴の確認
git log
//最新の一件だけを取得
git log -1
//特定の日(2019-05-01)までのログを取得
git log --until=2019-05-01
//特定の日(2019-05-01)以降のログを取得
git log --since=2019-05-01
//特定のファイル(ここではApp.js)のログを取得
git log App.js
で確認できます。
commit 195f1633e4dfa9095b3c9207e0e5a93751db3dfa
Author: kaitolll <kaitolll@gmail.com>
Date: Wed Sep 6 16:27:02 2017 +0530
こんな感じのものが出てきます。
一番上のものがコミットIDと呼ばれるものでコミットの識別子になります。
Authorはオリジナルのコードを書いた人です(コミットした人ではないです)。
Dateはその日時です。
git-logには色々なオプションがあります。
以下が詳しいのでよければ参考にしてみてください。
https://git-scm.com/docs/git-log
- Authorとcommitter
以下は、難しければ飛ばして1-1-4,ブランチを切るに進んでください
gitのタイムスタンプはauthor-dateとcommiter-dateの二種類あり、--pretty=fullerオプションをつけることでcommiter-dateを見ることが出来ます。
//コミットの履歴の確認
git log --pretty=fuller
出てくるのは、
Author: kaitolll <kaitolll@gmail.com>
AuthorDate: Fri Oct 6 11:21:53 2017 +0800
Commit: kaitommm <kaitommm@gmail.com>
CommitDate: Fri Oct 6 11:21:53 2017 +0800
こんな感じです。
なぜAuthorとcommitterが分かれているのかというと、複数人で開発する時に、コードを書いた人とコミットした人(履歴を登録した人)は必ずしも一致しないからです。
これは以下の1-1-4や複数人開発でのブランチモデルを説明した後に思い返してもらえると幸いです。
1-1-4,ブランチを切る
開発をしていて実験的に変更を加えてみて、上手くいったら反映したいなみたいな時に、
コミットの履歴を登録する場所を切り替えることが出来ます。
最初に何もしていない場合masterと呼ばれるブランチ(履歴の記録場所)にコミットの履歴は積み重なっていきます。
そうするのではなくて別の場所に履歴を登録していき、その履歴をmasterに必要に応じて反映させるということが可能です。
開発履歴を枝分かれさせることからブランチ(branchは英語で枝の意味です)と呼ばれています。
引用：https://git-scm.com/about/branching-and-merging
他のブランチの変更差分を取り込むことをマージと言います。(mergeは英語で統合するという意味です。)
枝分かれする元のブランチを親ブランチ、切った先のブランチを子ブランチと言います。
ここでは扱いませんが親ブランチを持たないブランチを切ることも可能で、
Orphan(オーファン)ブランチと言います。Orphanは孤児の意味です。
//ブランチ一覧を確認する
git branch
/* こんな感じでブランチ一覧が表示されます。
(developやdev1などmaster以外はサンプルとして作りました。)
dev1
dev2
dev3
* develop
master
ここで先頭に*が付いているものが現在の作業ブランチです。
何もブランチを切っていなければ
* master
とだけ表示されます。
*/
//ブランチを切って子ブランチに移動。(切った時の作業ブランチが親ブランチになります)
git checkout -b 子ブランチ名
//作業ブランチを切り替える
git checkout 作業ブランチ名(作業したいブランチ名)
//現在の作業ブランチに他のブランチの変更履歴を取り込む
git merge 取り込みたいブランチ名
//現在の作業ブランチに他のブランチの特定のコミットのみ取り込む
git cherry-pick コミットID
//ブランチ名の修正
git branch -m 元のブランチ名 修正後のブランチ名
//ブランチの削除
git branch -D 削除するブランチの名前
1-1-5 git stash
ファイルの変更差分があって、ブランチを切り替えたい場合が存在します。
その場合素直に作業ブランチを切り替えてしまう(get checkoutする)と変更差分を持ったまま、次の作業ブランチに移動することになります。
なので、作業ブランチを切り替える前に、コミットするというのも一つの手ではあるのですが、そのブランチのコミット履歴が汚れてしまいます(不完全な変更差分をコミットしてしまう)。
そこで、現在の変更差分を一時的に退避するためのコマンドがgit stashです。
git stashは一時的な変更を退避させたり、そこから取り出して反映させるコマンドです。
なのでブランチを切り替える前にgit stashして、変更を一時的に退避させ、終わったら戻ってきてgit applyで変更を元に戻します。
//変更を一時的に退避させる
git stash save "メッセージ（どういう差分かなど）"
//untrackedファイルも含めて全てスタッシュ
git stash save -u "メッセージ（どういう差分かなど）"
//stashの一覧
git stash list
/* こんな感じで一覧が表示されます。
* stash@{0}: On master: スタッシュの実験２
* stash@{1}: On master: スタッシュの実験1
*/
//stashの中身の確認
git stash show stash@{N}
/* こんな感じのものが表示されます。
* App.js | 3 +++
* 1 file changed, 3 insertions(+)
*/
//stashの反映(変更差分を元に戻す)
git stash apply stash@{N}
//stashされたものの中から特定のファイルのみ反映(戻す時にステージングされます)
git checkout stash@{N} ファイル名
//stashの削除
git stash drop stash@{N}
//stashから反映させ＆同時に削除もする
git stash pop stash@{N}
stashをsaveする時にはどういうものかを判別するために、メッセージをつけることが好ましいです。
変更差分をstashから戻す時に、applyとpopの二種類が存在しますが、違いとしては
applyはstashから削除しないですが、popはstashから削除します。
この違いはgit stash listで確認することが可能です。
1-2,gitの設定(リモート編)とリモートでの開発
今まではローカルでのブランチ運用のお話でしたが、ここからはリモートリポジトリ(GitHub)を使用した開発について書きます。
1-2-1 リポジトリを作成する
まず、GitHubのサイトに行って、登録をします。
登録が完了するとリポジトリを作成できますので自分のページの左サイドバーのRepositoriesのNewを押して、リポジトリ名や、Public or Privateの選択をした後Create repositoryを押してリポジトリを作成します。
リポジトリが出来ましたら、Quick setup — if you’ve done this kind of thing before
にあるHttpsのhttps://github.com/xxxxxxx/-.gitをコピーします。
ssh接続の場合は公開鍵をGitHubに登録する必要があり、長いので今回は省略します。
1-2-2 ローカルリポジトリの設定
ローカルリポジトリにどこのリモートリポジトリにコードを反映させるかの設定をします。
ローカルの該当ディレクトリにて以下のコマンドを実行します。
git remote add origin （1-2-1でコピーした）https://github.com/xxxxxxx/-.git
これでoriginにhttps://github.com/xxxxxxx/-.gitが設定され、完了です。
originはリモートリポジトリの判別に使用します。
1-2-3 リモートリポジトリに反映させる、リモートリポジトリから取ってくる
リモートリポジトリにローカルのコミットを送ります。
これをpush(プッシュ)と呼びます。
//リモートリポジトリにpushする
git push origin ブランチ名
/*
* ブランチの一覧はgit branchで確認できます。
* その時の作業ブランチは※が頭についているものです。
* masterブランチを送る場合は
* git push origin master
* dev1ブランチを送る場合は
* git push origin dev1
* です。
*/
リモートリポジトリから変更をローカルに持ってくる場合、
git pullコマンドを使用します。
(取ってくるだけならgit fetchというコマンドもありますが、今回は変更差分をローカルに反映(マージ)したいのでpullを使用します。)
//リモートリポジトリにpushする
git pull origin ブランチ名
/*
* リモートのmasterブランチの変更をローカルのmasterに反映させる場合は
* git pull origin master
* リモートのdev1ブランチの変更をローカルのdev1に反映させる場合は
* git pull origin dev1(dev1がローカルにない場合は新規作成されます)
*/
リモートリポジトリにコミットを送るのがpushで
その反対(リモートリポジトリからコミットを取ってくる)がfetchです。
fetchした後にマージまでしてくれるのがpullです。
複数人で開発するGitHubフローと呼ばれるGitHubのPullRequest機能を用いた開発フローの場合GitHub上のコミットを開発者がそれぞれ進めていくのでそれを適宜取り込む必要があります。その際にpullを使用します。
また、誰かがリモートリポジトリにpushしたブランチの動作確認を行う際に、
git pull origin そのブランチ名でローカルに持ってきて検証することもあります。
1-2-4 PullRequest
GitHubを用いた開発で一番大きな意味合いとしてPullRequest(プルリクエスト、通称プルリク)が挙げられます。
変更差分が入ったブランチをpushしてリモートリポジトリに挙げた後、そのブランチの変更分をリリースするブランチ(大抵はmasterブランチ)などに取り込んでもらう(mergeしてもらう)ため、プルリクを作成します。
作成手順は
１、プルリクエストタブのNew pull requestを選択し、
２、どこのブランチからどこのブランチに取り込んで欲しいかを設定して、どういう変更かを記述してプルリクをオープンします。プルリクは自動で二つのブランチの差分を算出して可視化してくれます。
作成手順はこれだけです。
この際にどういうものを記述するかは開発チームごとにテンプレートが存在しているのが一般的であると思います。大抵はプルリクの目的、変更の概要、行ったテストやデザイン上の変更点などを書くかなと思います。
オープンされたプルリクは決められた開発ルールの中で誰かしらに見られ(見る人をレビュアー、見られる人をレビュイーと言います)、問題ないと判断されればレビュアーはプルリクエストを承認(approve)します。
そして、管理者によってマージが実行されて、自分のブランチの変更差分が取り込まれます。
1-2-5 リモートブランチとチーム開発を少しまとめ
以上がリモートリポジトリの作成から自分のブランチをpushしてプルリクを作成してリリースブランチなりに取り込んでもらうまでの流れになります。