ある程度Javaの基礎は学んだ私ですが、Git操作が正直わかっておりませんでした。ですので、このGWの期間にどうせなら勉強しちゃおうということで学んだことを記事としてアップすることにしました。
アウトプットすることで定着もしますし、備忘録として使える為この機会に覚えていきます!
今回はめっちゃ長めですが自分のためだけに色々頑張ってみました。なんたってGWは頑張るウィークなので!!(学生時代は勉強三昧だった自称進学校だったので・・・笑)
では、早速内容に入っていきましょう!
- Gitとは
- GitHubとは
- Gitインストール手順
- Gitの初期設定
- ターミナル頻出コマンド
- ローカルリポジトリの新規作成
- Gitリポジトリのコピー作成
- ステージングとコミット
- 現在の変更状況の確認
- 変更したファイルの中身を確認
- 変更履歴の確認
- ファイルの削除を記録
- ファイル名称を変更
- リモートリポジトリ(GitHub)を新規追加
- リモートリポジトリ(GitHub)へPush
- コマンドに別名をつける(エイリアス)
- バージョン管理しないファイルを無視する
- ファイルへの変更を取り消す
- 直前のコミットをやり直す
- リモートリポジトリの情報を確認する
- リモートリポジトリを新規追加する
- リモートリポジトリから情報を取得
- リモートリポジトリの変更・削除
- ブランチの新規作成
- ブランチの一覧表示
- ブランチを切り替える
- ブランチの変更・削除
- プルリクエストを行う
- タグの一覧を表示する
- 注釈付きタグを作成する
- タグのデータを表示する
- タグをリモートリポジトリに送信する
- 作業を一時避難する
- 避難した作業を確認する
- 避難した作業を復元する
- 避難した作業を削除する
- 追記(実践向け)
- Source Tree(ソースツリー)
Gitとは
Gitはファイルのバージョンを管理するのに使います。
いつ、誰が、何を変更したのかが把握できる上、上書きしようとすると警告が出るので安心して開発を進めることが出来ます。
GitHubとは
Gitで行っているファイルの変更履歴やファイルをオンライン上で扱ってくれるサービスです。
同様のサービスにBitbucketもありますが、違いとしては「非公開リポジトリが有料か無料か」というところにあります。Bitbucketは非公開リポジトリが無料なので、2〜3人位でのスモール開発ではGitbucketがおすすめとされています。
Gitインストール手順
MacBookの場合はデフォルトでインストール済みのため、下記画像のところからターミナルで操作が可能となります。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/3a33d8c95aaf8bbef50615e04c82dfe1-2.png)
git version
と入力することでGitがインストールされているか確認ができます。
Gitの初期設定
GitHubで登録した「ユーザー名」「メールアドレス」と使用する「エディタ」を登録していきます。
ユーザー登録
git config --global user.name "GitHubで登録したユーザー名"
メールアドレス登録
git config --global user.email "GitHubで登録したメールアドレス"
エディタの登録
git config --global core.editor "使用するエディタ名 --wait"
設定確認は
git config --list
と入力することで確認できます。
ターミナル頻出コマンド
cd:ディレクトリを移動
ls:ディレクトリの内容を表示
ls -a:隠しファイルを含めたディレクトリ全内容を表示
mkdir:ディレクトリを新規作成
rm:ファイルを削除
cp:ファイルをコピー
mv:ファイルの移動とファイルの名称変更
cat:ファイルの中身を表示
ローカルリポジトリの新規作成
git init
Gitリポジトリのコピー作成
他の人がGitリポジトリに作成したプロジェクトを自分のローカルリポジトリに作成できる
git clone<リポジトリ名>
GitHub(リモートリポジトリ)上に公開されているリポジトリは下記画像のようにしてコピーし、git cloneすることで自分のローカルリポジトリにコピーできます。
![GitHub](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/c0aeea7cc4831446bd926ac4c2a8ca8c.png)
ステージングとコミット
ステージに変更を追加
「ステージング」は、手元の作業場で変更した内容をステージに追加する作業のことです。
git add<ファイル名>
git add<ディレクトリ名>
<全ての変更をステージに追加する場合>
git add .
リポジトリに変更を記録
コミットすることでステージに追加された変更を記録することが出来ます。
git commit
<エディタを起動せずにコミットメッセージを追加する場合>
git commit -m "コミットメッセージ"
<エディタ上で変更内容も確認したい場合>
git commit -v
〜commitだけでなくaddもする理由〜
1つのコミットに含まれる修正を1つだけにしてコミットログを分かり易くする為。
例えば、setting.htmlとtop.htmlの2つのファイルで①新機能の追加と②既存機能の編集を行なった際、コミットだけを行うと、複数の機能変更に対して1つのコミットとなってしまう為管理が複雑になってしまいます。
逆に、addしてステージに変更を追加してからコミットを行うと、その機能変更ごとにコミットできる為管理がしやすくなります。
また、作業途中のファイルなどコミットしなくてよいファイルをコミットせずに済みます。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/01a9f165712e29f79d95852d7c1d29c8-1.png)
コミットメッセージは分かり易く書こう!!
1行目:変更内容の要約
2行目:空行
3行目:変更した理由
現在の変更状況の確認
変更されたファイルを確認します。
git status
ファイルを変更したら「git add」して、「git status」、「git commit」して「git status」をします。「何のファイルが変更されたかを確認」してからステージングやコミットをする癖をつけていきましょう!
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/af51ca702e5b689acc2bca977c427605.png)
変更したファイルの中身を確認
変更したファイルの中身に関して、変更差分を確認します。
<ステージング前の変更差分を確認>
git diff
git diff <ファイル名>
<ステージング後の変更差分を確認>
git diff --staged
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/54fe0d5f0b12ad72bc556a8913014af0.png)
変更履歴の確認
以前どのような変更があったかを確認します。
git log
<要点だけ1行で表示させる>
git log --oneline
<特定のファイルだけの変更履歴を表示させる>
git log -p <ファイル名>
<表示するコミット数を制限する>
git log -n <コミット数>
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/64dde6acd19611389db7b790027c6596.png)
ファイルの削除を記録
<Gitにコミットされた記録やワークツリーの記録全てから削除>
git rm ファイル名
git rm -r<ディレクトリ名>
<ワークツリーには記録を残し、Gitの記録からだけ削除する場合>
git rm -cached<ファイル名>
ファイル名称を変更
git mv<旧ファイル><新ファイル>
リモートリポジトリ(GitHub)を新規追加
git remote add origin リモートリポジトリのURL
「git remote add」でURLを登録しておくことで今後「origin」という名前でGitHubリポジトリとやり取りができます。
リモートリポジトリ(GitHub)へPush
ローカルリポジトリの内容をリモートリポジトリに送ることをプッシュと呼びます。
git push <リモート名><ブランチ名>
(git push origin master)
※originは登録したリモートリポジトリのショートカット名です。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/e38fede130b6380d6bea355859627f50.png)
GitHub側での操作
1.アクセストークンの生成
GitHubでログイン後下記操作を行います。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/e74484bb940517161ae7c71db1651dff.png)
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/9f816fd3373ab315e43037d9099d7fd3.png)
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/ae37a75f7b4b59c83ea6fa39bd7fd430.png)
Generateしてトークンを発行するとこの次の画面でトークンが表示されますが、一度しか表示されない為これはメモ帳等にコピーしておきましょう。もし、トークンを失くしてももう一度この操作をやり直して発行し直せば大丈夫です。
2.リポジトリを作成
マイページよりリポジトリを作成していきます。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/acce5ffd59534e92f0b184f2d8503b2a.png)
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/2859173056b2bc6d316273b38b7e17f0.png)
Create repositoryすることで、GitHub上にリポジトリが作成されます。
ターミナル側での操作
GitHub上でリポジトリが作成されると「… or push an existing. repository from the command line」というのがあるのでその下の行にある
「git remote add origin https://github.com/~~~~~~~~~~~」
という1行をコピーし、ターミナルに貼り付け、実行します。これで登録が完了となります。
また、この後に下記コマンドを実行することで次回以降pushする際に「git push」だけでpushが実行できるようになります。
git push -u origin master
上記コマンドを実行すると、ユーザー名とパスワードが聞かれるので、GitHubで登録したユーザー名と先ほどのアクセストークンを入力します。
プッシュに成功しているとGitHub上で確認ができます。
コマンドに別名をつける(エイリアス)
git config --global alias ci commit
上記の例では、今後コミットする際に「git ci」でコミットができるようになります。
「git config」は設定を変更するコマンドで、「–global」はPC全体の設定の変更を行うコマンドになります。
バージョン管理しないファイルを無視する
自動生成されるファイルやパスワードが記載されているファイルはGitの管理から外します。そのためには「.gitigreファイルに指定」します。
touch .gitignore
.gitignoreはデフォルトでは存在していないので、必要に応じて自分で作成する必要があります。
touchコマンドでgitignoreを作成します。
生成方法はとても簡単で、普通のファイルを作成するのと同じ要領です。作成場所は「.git」ファイルがあるディレクトリ(git initしたディレクトリ)です。
.gitignoreファイルの書き方に関しては参考サイトをいくつか貼っておきます。
ファイルへの変更を取り消す
ワークツリーのファイルの変更を取り消す
ワークツリーのファイルの変更を元の状態に戻したい場合に使用します。
git checkout --<ファイル名>
git checkout --<ディレクトリ名>
<全変更を取り消す場合>
git checkout -- .
ステージングした変更を取り消す
ステージングされたファイルの変更を元の状態に戻したい場合に使用します。
但し、ステージングされた変更のみを取り消すため、ワークツリーには何も影響を及ぼしません。
git reset HEAD <ファイル名>
git reset HEAD <ディレクトリ名>
<全変更を取り消す場合>
git reset HEAD .
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/2de67c2d12bf53e2c7f6a0e72b2f3f2e.png)
直前のコミットをやり直す
git commit --amend
Pushした後にこのコマンドを実行してしまうと、Pushされたリモートリポジトリのデータを取り込んだ第三者の人が変更を加えて統合しようとした時に、リモートリポジトリの履歴とその第三者の人のローカルの履歴が異なってしまい統合ができなくなります。
なので、絶対にPushする前の状態でこのコマンドを使用するようにしましょう。
もしPush後にそのコミットをやり直したい場合は、上記コマンドを使用するのではなく、「git commit」コマンドでもう一度新しいコミットを作成して修正するようにしましょう。
リモートリポジトリの情報を確認する
設定しているリモートリポジトリの情報を表示します。
<リモート名のみ表示させる>
git remote
<URLまで表示させる>
git remote -v
<詳細情報を表示させる>
git remote show <リモート名>
リモートリポジトリを新規追加する
登録したいショートカット名でリモートリポジトリのURLを登録します。
git remote add<リモート名><リモートURL>
(例)git remote add practice https://github.com/~~~~~
リモートリポジトリから情報を取得
フェッチ
リモートリポジトリからローカルリポジトリに情報をとってきますが、ワークツリーには反映されません。
git fetch <リモート名><ブランチ名>
マージ
ローカルリポジトリから情報を取ってきて、ワークツリーに反映させます。
git merge <リモート名>/<ブランチ名>
プル
ざっくり「フェッチ+マージ」と同じ意味です。
git pull (※<リモート名>/<ブランチ名>) ※省略可能
今masterブランチにいる状態でリモートリポジトリから別のブランチをpullしてしまうと別ブランチの情報が統合されてしまいファイルがぐちゃぐちゃになってしまうため、なるべく私のような初学者は「フェッチ+マージ」を意識して使いましょう。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/5eab3da7cbeaa3b4e2c45b9a27292415.png)
リモートリポジトリの変更・削除
リモートリポジトリ名の変更
git remote rename <旧リモート名><新リモート名>
リモートリポジトリの削除
git remote rm <リモート名>
ブランチの新規作成
ブランチを新規作成しますが、ブランチの切り替えまでは行われないので注意しましょう。
//新規ローカルブランチを作る
git branch <ブランチ名>
//リモートのあるブランチを元に新規ローカルブランチを作る
git branch <新しいブランチ名> <元にするブランチ名>
ブランチの一覧表示
何のブランチがあるかを確認したいときに使用します。
git branch
<全てのブランチを表示したい場合>
git branch -a
ブランチを切り替える
git checkout <既存ブランチ名>
<ブランチを新規作成して切り替える場合>
//新規ローカルブランチを作りそのブランチに移動する
git branch -b <新しいブランチ名>
//リモートのあるブランチを元に新規ローカルブランチを作りそのブランチに移動する
git checkout -b <新しいブランチ名> <元にするブランチ名>
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/2c821e28505e99bbb1b64af808d8d8c0.png)
ブランチの変更・削除
ブランチ名の変更
自分が作業しているブランチの名前を変更します。
git branch -m <ブランチ名>
ブランチの削除
git branch -d <ブランチ名>
上記コマンドは、まだmasterにマージしていない変更が残っている場合そのブランチは削除されない為、安全なコマンドとも呼ばれています。
<強制削除する場合>
こちらのコマンドは、masterにマージされていない変更が残っていたとしても削除したい場合に使用します。
git branch -D <ブランチ名>
ローカルで変更したブランチをリモートリポジトリに反映
※2023/4/21追記
ローカルで作成・削除・変更したブランチをリモートリポジトリに反映します。
git push origin <変更したブランチ名>
プルリクエストを行う
自分の変更したコードをリポジトリに取り込んでもらうよう依頼する機能です。コードレビューをしてもらう過程で生じる作業となります。
ターミナル側でPushした後、GitHub側で操作を行います。
プルリクエストを選んでNew Pul requestを押下します。l
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/3eba1e7c15da0bc82735816902c83950.png)
基盤となるブランチをbaseに、プルリクエストするブランチをcompareに設定してcreate pull requestを押します。
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/248458a33b65b1ede08bc320e819c929.png)
するとプルリクエストのタイトルと本文が設定できるので、記入した後create pll resuestボタンを押下するとプルリクエストが作成されます。作成が確認できた後は、コードレビューを依頼したいので、Reviewersからレビュワーを選ぶことでレビュワーにプルリクエストを送信できます。
タグの一覧を表示する
コミットを参照し易くするためにわかりやすい名前を付ける為に使用します。
git tag
<パターンを指定してタグを表示させる場合>
git tag -l "20220501"
注釈付きタグを作成する
mオプションを付けることでエディタを立ち上げずにメッセージが入力できます。
git tag -a<タグ名> -m"<メッセージ>"
タグのデータを表示する
git show <タグ名>
下記情報が表示されます。
タグ付けした人の情報
タグ付けした日時
注釈のメッセージ
コミット
タグをリモートリポジトリに送信する
git push <リモート名><タグ名>
<タグを一斉に送信する場合>
ローカルにあってリモートリポジトリに存在しないタグを一斉に送信します。
git push<リモート名> --tags
作業を一時避難する
コミットするまではいっていない作業から、途中で別のブランチで作業する必要が出てきた場合に変更分をstashに一時避難させます。
git stash
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/stash1.png)
避難した作業を確認する
すべての避難した作業の一覧を表示させます。
git stash list
![](https://hiro-hobbyblog.com/wp-content/uploads/2022/05/stash-list-1.png)
避難した作業を復元する
<最新の避難した作業を復元する場合>
git stash apply
<ステージの状況も復元する場合>
git stash apply --index
<特定の避難した作業を復元する場合>
git stash apply <スタッシュ名>
(例)git stash apply stash@{1}と入力。git stash listで確認可能です。
最新の避難した作業が番号0となりそこから順に1、2・・・となります。
避難した作業を削除する
<最新の避難した作業を削除する場合>
git stash drop
<特定の避難した作業を削除する場合>
git stash drop <スタッシュ名>
(例)git stash drop stash@{1}と入力。
<避難した全作業を削除する場合>
git stash clear
追記(実践向け)
gitのpushまでの流れ
※2022/9/8追記
ざっと手順だけ追記しておきます。
①Github上でリポジトリを作成する
②現在の作業ディレクトリにローカルリポジトリを新規作成する
git init
②下記コマンドを実行してリモートリポジトリを登録する
git remote add origin リポジトリのURL.git
③下記コマンドで登録されているかを確認
git remote -v
④下記のように表示されていればOK
origin リポジトリのURL.git (fetch)
origin リポジトリのURL.git (push)
⑤下記コマンドでデフォルトブランチ名にmainを登録
git branch -M main
git push -u origin main
⑤下記コマンドを実行して完了。
git add .
git commit -m "コミットメッセージ"
git push
git add .
上記コマンドを実行すると下記のようなエラーが発生することがあります。
error: 'ディレクトリ名' does not have a commit checked out
fatal: adding files failed
このような場合はディレクトリの中にさらに同じ名前のディレクトリが作成されてしまっている可能性があるので、不必要なディレクトリを削除すると解決できます。
指定したファイルを管理対象から除外する
※2022/10/27追記
指定したファイルを削除せずに管理対象から除外する方法。
git rm --cached [ファイル名]
この時–cached オプションを付けることにより、ファイルを残したまま管理対象から外すことができます。
git rm [ファイル名]
–cached オプションつけていないと、ファイルごと削除してしまうので注意しましょう。
プロジェクト参画時の流れ
※2022/12/05追記
①GitHubからソースコードをクローン
例えば作業用フォルダとしてworkspaceフォルダ(任意)を作成し、その配下にソースコードをクローンする。
cd C:\workspace
git clone <URL>
②master(親)から別ブランチを作成、切り替え
ベース(親ブランチ)をmasterとする別ブランチを作成して、masterからコードの修正・追加等の作業を切り離す。
git branch <作成するブランチ名>
ブランチを作成した後、そのブランチへ切り替える。
git checkout <先ほど作成したブランチ名>
適切なブランチに切り替えられているかを確認する。
git branch --contains
③add、commit、pushまでを行う
修正したファイルは相対パスで指定する必要があるため下記コマンドで確認する。
git status
これで変更したファイルの相対パスが確認できるので、これを利用してaddしていく。
git add <先ほど確認した相対パス>
addした後にメッセージ付きコミットを行う。
git commit -m "任意のコミットメッセージ"
コミットした後にpushを行うが、初回のpushだけは-uコマンドをつけて行う必要がある。
初回のpush
git push -u origin <先ほど作成したブランチ名>
2回目以降のpush
git push origin <先ほど作成したブランチ名>
うまくいかない場合
add・commit・pushがうまくいかない場合何らかの問題が発生しているが、どうにもならない場合は自己責任で下記を試してほしい。
①修正したファイルを物理的にデスクトップなどに退避させる
②リモートリポジトリの情報をローカルリポジトリに反映させる
git fetch origin master
③現在のブランチの状態を強制的にmasterブランチの状態に合わせる
git reset --hard origin/master
④退避したファイルを適切な場所に配置して、再度add、commit、pushの操作を実行する
④GitHub上でプルリクエストを行う
GitHub上で参画しているPJ内の「Pull requests」を押下すると、先ほどpushした自分の作成したブランチ名が画面上部に色付きで表示されます。
プルリクエストを作成する的なメッセージが英語で書いてあるのでボタンを押下し、タイトルをつけるとプルリクエストを作成できます。この時、画面右側にある「Reviewers」に担当者を追加することで追加した人に通知が届くようになります。
その後は、作成したプルリクエストにコミットを重ねていく形でレビューをしてもらう流れとなります。
⑤検証(ステージング)環境へ反映させる
開発環境での製造・テストが終了すると、本番環境に近い環境のステージング環境でテストを行う必要があります。
ベース(親ブランチ)をstaging(検証環境ブランチの仮称)とし、新たなブランチを作成することでステージング向けのプルリクエスト作成していきます。
git checkout -b <新しく作成するブランチ名><親にするブランチ名>
作成したブランチに切り替え、開発環境で行なった操作と同様にadd、commit、pushを行い、GitHub上でプルリクエストを作成してマージプルリクエストを依頼します。
リリーストラブル時用の打ち消しコミット
※2023/7/15追記
①打ち消しコミット用ブランチを作成(事前準備)
⚫️リリース用のブランチfeature/develop_releasetには、
以下のコミット履歴があると仮定。
=============================
①資材修正2(※最新のコミット)
②資材修正1
③first commit(※初回コミット)
=============================
→
※masterにマージ後トラブルが発生した場合は、
「②資材修正1」のみ省いたものを再リリースしたい。
⚫️打ち消しコミット用のブランチfeature/develop_revertでは、
以下の操作を行う。
1. 資材修正2(最新のコミット)をリバートする。
→②、③のみの変更がされている状態
2. 資材修正1をリバートする
→③のみの変更がされている状態
3.「資材修正1」が削除され、「資材修正2」がある資材状態でコミットする。
or 「資材修正1」が削除され、「資材修正2」がある資材状態を別ブランチからマージする。
※以下のようなコミット履歴の状態にしておく
==========================================================
①Merge branch 'feature/test' into feature/develop_revert
②revert"資材修正1"
③revert"資材修正2"
④資材修正2
⑤資材修正1
⑥first commit(初回コミット)
==========================================================
②masterブランチにリリース用ブランチをマージ
③マージ後に本番環境でトラブルが発生!
・正常時
develop ---> feature/develop_release ---> master(develop)
・事前に作成しておいた打ち消しコミット用ブランチをmasterにマージ
develop ---> feature/develop_release master(develop)
| ^
feature/develop_revert ----|
④masterの資材がリリース作業前、もしくは想定の状態であることを確認
Source Tree(ソースツリー)
※随時追記中です。
WindowsでSource Treeが起動しない時の対処法
Windows10で何度立ち上げようとしても起動せず、PCの再起動でも解決できない事象が発生しました。
解決方法
以下のディレクトリの「名前が長い方のSourceTree.exe_〇〇」を削除するだけでした。
C:¥User¥ユーザー名¥AppData¥Local¥Atlassian¥名前が長い方のSourceTree.exe_〇〇