20201014のGitに関する記事は8件です。

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設定

とりあえず最低限の設定だけ行う

~/.vimrc
syntax enable
colorscheme desert

Gitのアップデート

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のインストール

https://anyenv.github.io/

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-update

nodenvのインストール

anyenv install nodenv
exec $SHELL -l
nodenv --version

pyenvのインストール

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 <バージョン>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【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でコミットが一致するところまで戻れば、問題なくマージできます。

まとめ

reflogresetを使えるようになってからgit開発がかなり捗りました。
この記事でgit初心者の方が少しでも理解を深められたら幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitのお勉強

Gitについてまとめていきます

最近gitを使う機会が増えてきて、理解しているつもりでも意外と理解できていないことがあったので自分なりにgitについてまとめていこうと思います。
何回かに分けて書いていこうと思いますので、「何かここ違うんじゃ、、、」等ありましたら指摘、アドバイスよろしくお願いします。

そもそもGitって?

分散型バージョン管理システムのこと
簡単に言うといろんなファイルのバージョン管理が簡単にできるシステムのこと、分散型なので複数人で編集したりする時に便利で、編集履歴を複数人で共有できたりします。バージョンを戻したりするのも簡単です。

分散型をもう少し詳しく

分散型というものを理解するにはSubversionと比較するとわかりやすいのでSubversionとの違いを見ていきたいと思います。
ちなみにSubversionというのは集中型バージョン管理システムです。大きな違いは。。

ローカルリポジトリの有無

集中型のリポジトリ(バージョン管理するためのデータベースのようなもの)がリモートにのみ存在するのに対し、分散型は各々のローカルにもリポジトリが存在します。
スクリーンショット 2020-10-14 16.42.59.png
イメージでいうとこんな感じです。

Subversion(集中型)はリポジトリが1つで仕組みがシンプルですがGit(分散型)はリポジトリが複数存在することになるので少し複雑になります。集中型と違い分散型はローカル上でコミットでき、尚且つ変更内容を共有(リモート)リポジトリに反映させるかは任意なので試験的や未完成なもので他の人に迷惑をかけることがなく作業できます。またローカルにリポジトリが存在するのでブランチやマージといった操作が手軽に行えます。


ざっくりとした説明でしたがなんとなくgit(分散型)についてイメージできたでしょうか、リポジトリやコミット、マージと言った言葉が出てきて難しいとは思いますが、それぞれの言葉についても記事を書いていきたいと思います。
あとはGitの仕組みについてなどもいろいろ試して書いていこうと思います。記事が完成次第こちらにもリンク等追加していこうと思いますのでよかったら見てみてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitの差分をSourcetreeで簡単にリセットする方法

Gitの差分、元に戻すのめんどくセーー

Gitの差分を元に戻したい時、ありますよねーー。
別のブランチに変更したい時とか、ぐちゃぐちゃになってやり直したい時とかw

実はSourcetreeを使えば、簡単にリセットができました!:joy:

Sourcetreeから差分をリセット

スクリーンショット 2020-10-14 18.36.34.png
コミットをクリック

スクリーンショット 2020-10-14 18.37.53.png

リセットしたいファイルを選択して右クリック→リセット!

これでローカルリポジトリは健全な状態に戻りましたとさ:blush:

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GitHubについて備忘録。。

clone

cloneコマンドは一言で言えばリポジトリ(ファイルやディレクトリの状態)をコピーするためのコマンド。主にみんなで活用しているリモートリポジトリをクローンして、自分の開発用にローカルリポジトリを作るために使います。

fork

一般的にフォークは、他のユーザのプロジェクトへの変更を提案するため、あるいは他のユーザのプロジェクトを自分のアイディアの出発点として活用するために使用します。
(他人のリポジトリを自分のアカウントのリモートリポジトリにコピーすること)

forkによるワークフロー

  1. 元となるリポジトリをfork
  2. forkしたリポジトリBをローカルにclone
  3. cloneしたリポジトリCで開発し、リポジトリBに反映
  4. リポジトリAの管理者にPull Requestを送信

フォークした後のワークフロー

GitHubでフォークした後にフォーク元の差分を取り込む時の手順になります。

ローカル環境で該当プロジェクトのディレクトリに移行して、フォーク元のリポジトリを登録します。

$ git remote add upstream git://github.com/ユーザー名/リポジトリ

上記はフォーク元のURLになります。

フォーク元からの内容を取得して、自分のmasterにマージします。

$ git fetch upstream
$ git merge upstream/master

これでフォーク元の差分を取り込むことができます!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

リモートリポジトリのブランチをローカルに取り込む

リモートリポジトリのブランチをローカルに取り込む

リモートリポジトリのブランチ(origin/[ブランチ名])を
任意のブランチ名でローカルに作成する

terminal
git checkout -b [ブランチ名] origin/[ブランチ名]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitで.onionなリモートリポジトリを扱う

gitで.onionドメインのような通常の方法で解決できないドメインを使うときは、sock5プロキシを使います。
sock5プロキシで利用するポートは9050ですが、9051の場合もあります。

git -c http.proxy=socks5h://127.0.0.1:9050 clone http://hoge.onion/foo.git
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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 clean

Step 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 hashHEADを利用し、そうでないなら、適切な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 File

Step 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 failed

Step 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回目のコミットを実行
結果、二つ前の状態に遷移

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む