- 投稿日:2020-10-14T22:31:27+09:00
Mac 環境構築メモ
MacBookProを購入した際に開発環境構築を行ったのでそのメモ。
3本指ドラッグ
https://support.apple.com/ja-jp/HT204609
デフォルトのシェルをzshからbashに変更
bashに慣れているため変更する。
https://qiita.com/___xxx_/items/c9a30e78196998f4160c
brewインストール
とりあえずインストール
https://brew.sh/index_ja/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"bashのアップデート
Macのbashはバージョンが古いみたいなのでアップデート
https://qiita.com/zaburo/items/1b990436ca45545959e9
→5.x系にアップデートされた$ bash --version GNU bash, バージョン 5.0.18(1)-release (x86_64-apple-darwin19.5.0) Copyright (C) 2019 Free Software Foundation, Inc.Vim設定
とりあえず最低限の設定だけ行う
~/.vimrcsyntax enable colorscheme desertGitのアップデート
MacのGitは少し古いみたいなのでアップデート
https://qiita.com/normalsalt/items/f200ba50363ebfd46df0
→v2.28.0にアップデート$ git --version git version 2.28.0ターミナルを見やすく&Gitのブランチを表示
https://qiita.com/hmmrjn/items/15d0fe15e5d03586ad46
VSCodeのターミナルも文字化けするので下記設定が必要
{ "terminal.integrated.fontFamily": "Menlo for Powerline" }Docker Desktop for Macのインストール
https://hub.docker.com/editions/community/docker-ce-desktop-mac/
anyenvのインストール
brew install anyenv
~/.bash_profile# 追記 eval "$(anyenv init -)"source .bash_profile anyenv install --init mkdir -p $(anyenv root)/plugins git clone https://github.com/znz/anyenv-update.git $(anyenv root)/plugins/anyenv-updatenodenvのインストール
anyenv install nodenv exec $SHELL -l nodenv --versionpyenvのインストール
anyenv install pyenv exec $SHELL -l pyenv --version # Pythonインストール pyenv install <バージョン> pyenv global <バージョン>goenvのインストール
anyenv install goenv exec $SHELL -l goenv --version # Goのインストール goenv install <バージョン> goenv global <バージョン>
- 投稿日:2020-10-14T20:15:20+09:00
【Git】Git基本用語とコマンドの解説
はじめに
曖昧だったgitの基本用語とコマンドを整理してまとめてみました。
git経験の浅い筆者が書いているため、間違った記載があればご指摘してもらえると嬉しいです。基本用語の解説
ワークツリー(作業ツリー、ワーキングディレクトリ)
現在表示されている実際のファイル群のことです。
ワークツリーのファイルを編集して作業をします。インデックス(ステージング)
git addで移動する領域のことです。
ワークツリーで編集した内容は、まずインデックスと呼ばれる領域に移動します。
ブランチを切り替えたときは、インデックス追加前後の内容(コミットしてないもの)は元のブランチを飛び越えて切り替え先のブランチに移動します。コミット
ある地点のセーブポイント
のことです。
git commitをすることで、インデックスに追加されていた変更が初めて記録されます。
コミットされた地点には、例え過去だろうと未来だろうと、自由に行き来することができます。HEAD
そのブランチにおける最新のコミットのことです。
また、コミット履歴が新しい順に、0番目、1番目...という風にHEADにも番号が割り振られています。ブランチ
別のセーブデータ
みたいなものです。
セーブデータごとに、それぞれのコミットの履歴があります。
通常、メインで使うmasterブランチが本番用のブランチです。
それ以外のサブブランチはmasterブランチや他のサブブランチから派生させたものです。
共同開発であれば、コードレビューなどを経て正式に採用されると、masterブランチにマージされます。マージ
別々のブランチどうしを合体して一つのセーブデータにします。
ブランチどうしでコミットの歴史が一致しない場合はマージが失敗し、コンフリクトが発生します。
コンフリクトを発生させないためには、現在のコミットの歴史さえ一致すればいいというのがポイントです。各コマンドの解説
- status
ステージングに追加されているかどうか確認します。
- log
現在のブランチでのコミットの履歴を表示します。
各コミットには、半角英数字40桁のコミットIDが割り振られています。
ここで表示されるHEAD -> master
とは、「masterブランチはこのコミットIDをHEADに持っているよ」ということを示しています。
ブランチを作成した場合など、HEAD -> master, dev
のように複数のブランチのHEADが同一のコミットIDを共有していることもあります。
- reflog
HEADが辿ってきた全てのコミットを確認できます。
単純にコミットの履歴だけではなく、リセットで消失したコミットやブランチを切り替えたときのHEADの状態も記録しています。
過去と未来あるいは平行世界(ブランチ)へのセーブポイントの移動を、同じ時間軸で一方方向に進むように見たときの歴史と考えると分かりやすいかなと思います。
- reset
git reset --<option> <commit>過去や未来のコミットに行き来したり、他のブランチのコミットに移動することもできます。
使いこなせばとても便利なコマンドです。optionには、主に以下の3つを指定できます。
soft
コミット履歴だけを復元します。
現在との差分は、復元したコミット地点からの変更点としてステージングに追加されます。
今のワークツリーのままコミットの歴史だけを書き換えたい場合に便利です。mixed
soft同様にコミットの復元に加え、ステージングも取り消します。
optionの引数なしで使った場合のデフォルトの挙動がこちらです。
git reset HEADは、ワークツリーはそのまま最新のHEADに復元してaddを取り消すので、振る舞いとしてはステージングだけ取り消すことができます。hard
HEAD、インデックス、ワークツリーを全て指定したコミットの状態に復元します。commitには、コミットのIDもしくはHEADを指定します。
HEAD
: 現在のHEADを指定します。HEAD^
: 1個前のHEADを指定することができます。HEAD~n
: 同一ブランチのn個前のコミットを指定できます。HEAD@{n}
: reflogで参照したn個前のHEADのコミットIDに移動できます。コミットID
: 直接コミットIDを指定します。
- merge
git merge <branch>現在のブランチに、指定したブランチをマージする。
マージは、コミットの歴史が途中まで一致していれば差分を合体してくれるコマンドです。
どれだけぐちゃぐちゃにしても、reset
でコミットが一致するところまで戻れば、問題なくマージできます。まとめ
reflog
とreset
を使えるようになってからgit開発がかなり捗りました。
この記事でgit初心者の方が少しでも理解を深められたら幸いです。
- 投稿日:2020-10-14T19:30:17+09:00
Gitのお勉強
Gitについてまとめていきます
最近gitを使う機会が増えてきて、理解しているつもりでも意外と理解できていないことがあったので自分なりにgitについてまとめていこうと思います。
何回かに分けて書いていこうと思いますので、「何かここ違うんじゃ、、、」等ありましたら指摘、アドバイスよろしくお願いします。そもそもGitって?
分散型バージョン管理システムのこと
簡単に言うといろんなファイルのバージョン管理が簡単にできるシステムのこと、分散型なので複数人で編集したりする時に便利で、編集履歴を複数人で共有できたりします。バージョンを戻したりするのも簡単です。分散型をもう少し詳しく
分散型というものを理解するにはSubversionと比較するとわかりやすいのでSubversionとの違いを見ていきたいと思います。
ちなみにSubversionというのは集中型バージョン管理システムです。大きな違いは。。ローカルリポジトリの有無
集中型のリポジトリ(バージョン管理するためのデータベースのようなもの)がリモートにのみ存在するのに対し、分散型は各々のローカルにもリポジトリが存在します。
イメージでいうとこんな感じです。Subversion(集中型)はリポジトリが1つで仕組みがシンプルですがGit(分散型)はリポジトリが複数存在することになるので少し複雑になります。集中型と違い分散型はローカル上でコミットでき、尚且つ変更内容を共有(リモート)リポジトリに反映させるかは任意なので試験的や未完成なもので他の人に迷惑をかけることがなく作業できます。またローカルにリポジトリが存在するのでブランチやマージといった操作が手軽に行えます。
ざっくりとした説明でしたがなんとなくgit(分散型)についてイメージできたでしょうか、リポジトリやコミット、マージと言った言葉が出てきて難しいとは思いますが、それぞれの言葉についても記事を書いていきたいと思います。
あとはGitの仕組みについてなどもいろいろ試して書いていこうと思います。記事が完成次第こちらにもリンク等追加していこうと思いますのでよかったら見てみてください。
- 投稿日:2020-10-14T18:41:48+09:00
Gitの差分をSourcetreeで簡単にリセットする方法
- 投稿日:2020-10-14T12:40:19+09:00
GitHubについて備忘録。。
clone
cloneコマンドは一言で言えばリポジトリ(ファイルやディレクトリの状態)をコピーするためのコマンド。主にみんなで活用しているリモートリポジトリをクローンして、自分の開発用にローカルリポジトリを作るために使います。
fork
一般的にフォークは、他のユーザのプロジェクトへの変更を提案するため、あるいは他のユーザのプロジェクトを自分のアイディアの出発点として活用するために使用します。
(他人のリポジトリを自分のアカウントのリモートリポジトリにコピーすること)forkによるワークフロー
- 元となるリポジトリをfork
- forkしたリポジトリBをローカルにclone
- cloneしたリポジトリCで開発し、リポジトリBに反映
- リポジトリAの管理者にPull Requestを送信
フォークした後のワークフロー
GitHubでフォークした後にフォーク元の差分を取り込む時の手順になります。
ローカル環境で該当プロジェクトのディレクトリに移行して、フォーク元のリポジトリを登録します。
$ git remote add upstream git://github.com/ユーザー名/リポジトリ上記はフォーク元のURLになります。
フォーク元からの内容を取得して、自分のmasterにマージします。
$ git fetch upstream $ git merge upstream/masterこれでフォーク元の差分を取り込むことができます!
- 投稿日:2020-10-14T12:07:28+09:00
リモートリポジトリのブランチをローカルに取り込む
- 投稿日:2020-10-14T11:55:26+09:00
Gitで.onionなリモートリポジトリを扱う
gitで.onionドメインのような通常の方法で解決できないドメインを使うときは、sock5プロキシを使います。
sock5プロキシで利用するポートは9050ですが、9051の場合もあります。git -c http.proxy=socks5h://127.0.0.1:9050 clone http://hoge.onion/foo.git
- 投稿日:2020-10-14T10:38:06+09:00
CI/CDをkatacodaで体験(初心者向け) - Part4(Undoing Changes)
CI/CD入門
このぺーじでは、katacodaと呼ばれる「ブラウザから無料で勉強用のインスタンスを起動できるWebサービス」を利用してCI/CDを実践します
内容は上記リンクに沿うので、不明点があればそちらへどうぞGitのバージョン管理について - Scenario4 - Undoing Changes
ここでは、CI/CDとして欠かせないGitによるバージョン管理について学習します
このシナリオで学習することをさっと確認する場合は概要を確認
理解に間違い等がございましたら、ぜひご指摘ください概要
git checkout
でワーキングディレクトリの状態を前回コミット時(変更前)に戻すgit reset
でステージングの状態をワーキングディレクトリの状態(git add
する前)に戻すgit reset
時にオプションとして--hard
を利用することで、ステージングの状態(git checkout
+git reset(オプションなし)
)を前回コミット時に戻すgit revert
で、前回あるいは、複数回前のコミット状態に戻す- どのbranchに対して戻すのかcommit hash(基本的には
HEAD
)を指定したほうが間違いが少ないStep 1 - Git Checkout
git checkout
はbranchの変更時に利用されるコマンドだが、編集中のワーキングディレクトリを前回コミット時の状態に戻すことも可能
状態が戻ったことは、git status
で確認可能$ ls -a . .. committed.txt .git staging.txt $ git branch * ESC[32mmasterESC[m $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: staging.txt no changes added to commit (use "git add" and/or "git commit -a") $ git checkout . $ ls -a . .. committed.txt .git staging.txt $ git branch * ESC[32mmasterESC[m $ git status On branch master nothing to commit, working tree cleanStep 2 - Git Reset
Step1では、ワーキングディレクトリ上にファイルがある状態->前回コミット時の状態に戻す操作
Step2では、ステージング上にファイルがある状態->ワーキングディレクトリ上にファイルがある状態へと戻す操作
git reset <file/directory>
で、実行可能$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: staging.txt $ git branch -a * ESC[32mmasterESC[m $ git reset HEAD . Unstaged changes after reset: M staging.txt $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: staging.txt no changes added to commit (use "git add" and/or "git commit -a")HEAD とは
HEAD
とは端的に言うと、「現在、作業しているブランチのバージョンを指定するもの」
そのため、下記ソースコードのようにgit reset HEAD .
のように記述しなくても今回は問題ありません$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: staging.txt $ git reset . Unstaged changes after reset: M staging.txt $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: staging.txt no changes added to commit (use "git add" and/or "git commit -a")では、なぜ
HEAD
が必要か?
作業しているbranchと異なるbranchに対して、何らかの操作を加えたり、以前のバージョンに対して操作を加える際にcommit hash
を指定する必要があります
作業しているbranchが最新のバージョンであれば、commit hash
にHEAD
を利用し、そうでないなら、適切なcommit hash
を選択
詳しくはこちらStep 3 - Git Reset Hard
step3では、step1,2の操作を一度に行う
それを確かめるため、staging.txt
はステージング上に、commited.txt
はワーキングディレクトリ上に存在させる
その後、git reset --hard
によって二つのファイルを前回コミット時へ戻す$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: staging.txt $ cat committed.txt Committed File $ echo 'test' >> committed.txt $ cat committed.txt Committed File test $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: staging.txt Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: committed.txt $ git reset --hard HEAD HEAD is now at 5d62819 New File $ git status On branch master nothing to commit, working tree clean $ cat committed.txt Committed FileStep 4 - Git Revert
続いて学習するのは
git revert
これは、誤ってコミットした場合に利用
commit_v0(前回の状態) -> commit_v1(間違い) -> git revert (HEAD) -> commit_v0(前回の状態)
git revert
はオプションとして、コメント(git commit -m
で用いるコミットメントコメント)を付与したりしなかったりできる
ログを残すことで後々確認しやすいので、オプションとして-e/--edit
を用いる方が良いその他のオプション
-e/--edit : コミットコメント書き込み
--no-edit : コミットコメントなし(前回のコミットコメント利用)
-n/--no-commit : コミットの取り消し(ステージングへの巻き戻し)
参考リンク$ git log ESC[33mcommit 676354469da2eff5cf7df1df0f17ba8183ce5bbeESC[mESC[33m (ESC[mESC[1;36mHEAD -> ESC[mESC[ Author: Katacoda Scenario <scenario@katacoda.com> Date: Wed Oct 14 00:03:04 2020 +0000 Commit To Revert $ git revert HEAD -e //"-e"オプションでeditorが表示される。適当なコメントを入力 [master 3240f2b] Revert "Commit To Test Revert" 1 file changed, 1 insertion(+), 1 deletion(-) $ git log ESC[33mcommit 3240f2b8b0a87363ed07fac7ade4a4c267e52bbdESC[mESC[33m (ESC[mESC[1;36mHEAD -> ESC[mESC[ Author: Katacoda Scenario <scenario@katacoda.com> Date: Wed Oct 14 00:06:56 2020 +0000 Revert "Commit To Test Revert" This reverts commit 676354469da2eff5cf7df1df0f17ba8183ce5bbe. ESC[33mcommit 676354469da2eff5cf7df1df0f17ba8183ce5bbeESC[m Author: Katacoda Scenario <scenario@katacoda.com> Date: Wed Oct 14 00:03:04 2020 +0000 Commit To Revert上の結果から分かる通り、logには新しく"Commit To Test Revert"と表示されている
注意
git revert
はステージングやワーキングディレクトリに対しては、何も操作しない$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: index.txt Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: working.txt $ git revert HEAD --no-edit error: your local changes would be overwritten by revert. //commitされていない修正のため、エラー hint: commit your changes or stash them to proceed. fatal: revert failedStep 5 - Git Revert
step4では、一つ前のコミットに戻していたが、二回以上前のコミットに戻すことも可能
現在の状態からいくつ前に戻るかはgit revert HEAD...HEAD~(n)
のように指定$ cat test.txt test 2 3 4 $ gi add test.txt bash: gi: command not found $ git add test.txt $ git commit -m 'fours commit' [master c3d82f1] fours commit 1 file changed, 1 insertion(+) $ git log --oneline ESC[33mc3d82f1ESC[mESC[33m (ESC[mESC[1;36mHEAD -> ESC[mESC[1;32mmasterESC[mESC[33m)ESC[m fours commit ESC[33m909ad91ESC[m third commit ESC[33m1cb550cESC[m second commit ESC[33m0062e56ESC[m first commit ESC[33m1d059eaESC[m Revert "Commit To Revert" ESC[33m12fcca9ESC[m Revert "Revert "Commit To Revert"" ESC[33md5aa2f3ESC[m Revert "Commit To Revert" ESC[33m3d950a6ESC[m Commit To Revert ESC[33m88e2869ESC[m New File ESC[33m43250bfESC[m Fixing Error ESC[33m22457e2ESC[m First Commit $ git revert HEAD...HEAD~2 [master 7dec1c4] Revert "fifth commit" 1 file changed, 1 deletion(-) [master 05804a9] Revert "third commit" 1 file changed, 1 deletion(-) $ git log --oneline ESC[33m05804a9ESC[mESC[33m (ESC[mESC[1;36mHEAD -> ESC[mESC[1;32mmasterESC[mESC[33m)ESC[m Revert "third ESC[33m7dec1c4ESC[m Revert "fifth commit" ESC[33mc3d82f1ESC[m fours commit ESC[33m909ad91ESC[m third commit ESC[33m1cb550cESC[m second commit ESC[33m0062e56ESC[m first commit ESC[33m1d059eaESC[m Revert "Commit To Revert" ESC[33m12fcca9ESC[m Revert "Revert "Commit To Revert"" ESC[33md5aa2f3ESC[m Revert "Commit To Revert" ESC[33m3d950a6ESC[m Commit To Revert ESC[33m88e2869ESC[m New File ESC[33m43250bfESC[m Fixing Error ESC[33m22457e2ESC[m First Commit $ cat test.txt test 2上記の結果の通り(分かりやすさのため、katacodaと異なる手順で確認してます)、
test.txt
は一行ずつコミットを行い、4回目のコミット後にgit revert
として5回目のコミットを実行
結果、二つ前の状態に遷移