Git/GitHub

【Git/GitHub】開発中の主な流れとコマンド

Octocat

はじめに

個人でGit、GitHubを使ったことはあるのですが、現職ではGitが採用されていないためチームでGitを使って開発するときにどういう風に使うかを具体的に知りたくて勉強しました。

今回は実際にGitを使いながら開発を行う際の流れと主に使うコマンドをまとめていきます。
今後自身で使っていく過程で、知識がアップデートされたら内容も更新していくかもしれません。

不備不足あればアドバイスいただけると、とてもうれしいです。
よろしくお願いします😀

 

開発中のGitコマンドの流れ

すでに一度リモートリポジトリから git clone などをおこなっており、ローカルとリモートの同期がとれている前提です。

Gitでバージョン管理を始めるときに最初に行うコマンドについては以下を参照してください。
【Git/GitHub】Gitでバージョン管理を始めるときに最初にするコマンド

1. 現在の状態を確認し把握する

作業前に以下のコマンドを適宜用いて、状況を確認して作業に入ります。

git branch

今どんなブランチが存在するか確認するコマンドです。
ブランチ名の一覧が表示されたときに * がついている箇所が今いるブランチになります。

#ローカルブランチの一覧を表示
git branch
#ブランチを新規作成
git branch ブランチ名
#ローカルとリモートの全てのブランチを表示
git branch -a
#リモートブランチの一覧を表示
git branch -r
ブランチとは

開発者ごとの作業フォルダのようなものです。

おおもとのmasterブランチから 「git branch ブランチ名」 を実行することで作業者専用のブランチを作成し、他の人に影響しない、かつ自分も影響を受けない状態で開発を進めることができます。

修正が完了した場合は、基本的にブランチをリモートリポジトリにpushして、プルリクエストを行い、コードをチェックしてもらった後に、masterブランチへ統合するような流れになります。

 

git status

変更されているファイルがないかを確認するコマンドです。

  • 変更したけど git add されていない
  • git add したけど git commit されていない
  • gitも認識していない新規ファイルがある

などを確認できます。

#現在の変更状況を確認
git status
#現在の変更状況を短い形式で表示できます
git status -s 

(見れたらかっこいいので個人的に使いたい笑)

特に何もなければ nothing to commit, working tree clean と表示されます。
※コミットするものは何もない、作業ツリーはクリーンです。のような意味

git diff

ファイルの変更差分を確認するコマンドです。

#git addする前の変更分を表示(ワークツリーとステージ)
git diff

#ファイル名の指定もできます
git diff ファイル名
#git add した後の確認(ステージとリポジトリ)
git diff --staged

※ネットでは git diff –cached のほうがよく出てくるが出力結果は同じでした

用語について

ワークツリー:作業中のPCフォルダのこと
ステージ: git add した内容が保存される場所
リポジトリ:git commit した内容が保存される場所

 

git log

変更履歴(git commitしたもの)を表示する

  • commit:コミットID
  • Author:作成者
  • Date:日時

上記と git commit 時のコミットメッセージなどが表示されます。
上から順に新しいものになります。

#変更履歴を確認
git log
#1行表示 
git log --oneline
#ファイルの変更差分を表示
git log -p ファイル名
#表示するコミット数を制限する(最近のを見たいときは数値をしぼったりする)
git log -n コミット数

 

2. ブランチを作成し切り替える(作業ブランチに移動する)

作業用のブランチを作成し切り替えます。

1. git branch

ブランチを確認するコマンドですが、ブランチを新規作成するときも使います。

#ブランチを新規作成
git branch ブランチ名

 

2. git checkout

git branchで今いるブランチが * で表示されます。
自身の作業するブランチにいない場合は切り替えます。

#ブランチ切り替え
git checkout ブランチ名
# 新規作成+切り替えを同時に行うこともできます
git checkout -b 新ブランチ名

 

git checkout はブランチ切り替え以外にファイルの変更の取り消しもできます。
以下のようなコマンドになります。
#ファイルへの変更を取り消す
git checkout -- ファイル名

#ディレクトリへの変更を取り消す
git checkout -- ディレクトリ名

#全変更取り消し
git checkout -- .

※- -はブランチ名とファイル名をGitが判別するために記載が必要です。
※前回git addした内容に戻すというような処理が行われるそうです。
(前回のステージと同じ状態になる=更新前に戻る)

たか
たか

作業用のブランチへの切り替えが完了したら、いよいよローカルフォルダ(自身のPCフォルダ)で作成や編集です🧐

3. ファイルの編集が完了したらGitに記録

作業用のブランチでファイルを編集した後は、Gitに変更を記録します

1. git add

ステージといわれる場所に記録したいインデックス(変更内容)を記録します。
※git commit 前の準備を行うような場所

#全ファイルをステージに追加
git add .

#ファイル名、ディレクトリ名の指定もできます
git add ファイル名
git add ディレクトリ名

 

なお git add の取り消しはこちらです。

#ステージ(add)を取り消したい
git reset HEAD ファイル名

 

インデックスの記録で行われることの概要

リポジトリに作業したファイルを暗号化+圧縮化した「ファイル1」が作成され、
ステージに今回の作業ファイルは「ファイル1」だと紐づけたものがインデックスとして保存されます。

 

2. git commit

リモートリポジトリにあげる(git push)前に必要なコマンドです。

git addでステージ作成したインデックスをもとにツリーを作成し、コミットといわれる情報をリポジトリに保存します。

#リポジトリに変更を記録(ツリー、コミット作成)
git commit -m"コミットメッセージ"

※コミットメッセージは更新内容を簡潔に短く書きましょう。
※Windowsのコマンドプロンプトだと日本語が表示できないので、英語が基本なのだろうか?

# -m がない場合はテキストエディタかコマンドプロンプト上でメッセージを記載する必要があります。
git commit

#コミットメッセージを -m で改行したい場合は -m を改行したいポイントで追加します。
git commit -m"1行目" -m"2行目"
#ファイルの変更内容をcommit実行前に確認できます
git commit -v 
#直前のコミットを取り消したい、やり直したい
git commit --amend
直前のコミットを取り消し(amend)について
Push済みのコミットは戻したらいけません。

Pushした後に誰かがクローンしたら、履歴が違うのでクローンした人があげれなくなるそうです。
そのためPushしたコミットは修正しないほうが良いそうです。

Push後の修正はgit commitでもう一回今の状況をコミットするが正解です。

コミットに入っている情報

ツリー
作成者
日付
メッセージ

add、commitまでしたときにリポジトリがもっているデータ

暗号化+圧縮化されたblobファイルのハッシュID
ツリー
コミット

この三つを「Gitオブジェクト」と言うそうです。
※確認するコマンドもあります git cat-file -p <オブジェクト名>

ハッシュIDとは

ヘッダー(ファイル内容の文字数など、ファイルのメタ情報)とファイル内容を、SHA-1というハッシュ関数で40文字の英数字に変換したもの。

ハッシュIDのうち、先頭2文字をディレクトリ名に、残り38文字をファイル名にして保存されています。

保存先はローカルの .git/objects という場所です。

4. Gitへの記録が完了したら、リモートリポジトリにアップする

いよいよリモートリポジトリにアップします。

※git push する前も「1. 現在の状態を確認し把握する」で紹介しているコマンドを利用して、状況の確認はしておきましょう。

git push

ローカルリポジトリで行った編集内容をリモートリポジトリにアップします。
git add、git commit を行ったものがアップされます。

git push リモート名 ブランチ名 というコマンドになります。

#ブランチ名は自分が作成したブランチ名が主になると思います。
git push origin ブランチ名
よく見るpushコマンド「git push origin master」は
「originというリモート名のmasterというブランチにpushする。」という意味になります。

チーム開発ではプルリクエストを行い、masterへ統合される流れがおおいので、masterを指定することはあまりないと思います。

リモート名のoriginとは

リモート名とは「アクセス先のリモートリポジトリのデフォルトの名前」です。

以下のページのように初回に
「git remote add origin リモートリポジトリのURL​」
でリモートリポジトリのURLをoriginというリモート名で紐づけるのですが、originはGitのデフォルト値のようで一般的にoriginになっていることが多いようです。

【Git/GitHub】Gitでバージョン管理を始めるときに最初にするコマンド

なお、リモート名の確認は 「git remote」で確認できます。

 

たか
たか

これでローカルリポジトリの内容が、リモートリポジトリにアップされました。

GitHubにログインしてWEB上でリモートリポジトリを確認すると、反映されているはずです。

プルリクエストはGitHubにログインしてWEB上で行います。
サクッと手順記載するので、参考になれば幸いです。

プルリクエスト(Pull requests)をする場合

プルリクエストの仕方

  1. GitHubへ移動
  2. Pull requestsをクリック
  3. New Pull Requestをクリック
  4. compareには自身が作成したブランチを選択する※compareがbaseにとりこまれます。
    baseが統合先のブランチでcompareには自身が作成したブランチを選択するケースが多いと思います。
  5. 適宜コメント入力+Reviewersで誰にレビュー依頼するかを選択する
  6. Create Pull requestをクリック
たか
たか

ここまでが、開発中によく使うコマンドや流れになります

他に調整時に使うコマンド(git fetchとかpullとか)もありますが、また後日記載していきます