20200208のGitに関する記事は7件です。

Gitの内部の動きを知ろう ~その2~

目次

今回の確認内容

その1で作ったリポジトリに対して、さらにファイルを追加してcommitまで実施します。すでにあるファイルへの変更も実施してみます。

git add

初期状態のおさらいです。前回ファイルをひとつ追加してcommitまでしたことで以下のようになっています。

$ tree -a
.
├── .git
│   ├── COMMIT_EDITMSG
│   ├── HEAD
│   ├── branches
│   ├── config
│   ├── description
│   ├── hooks
│   │   ├── applypatch-msg.sample
│   │   ├── commit-msg.sample
│   │   ├── fsmonitor-watchman.sample
│   │   ├── post-update.sample
│   │   ├── pre-applypatch.sample
│   │   ├── pre-commit.sample
│   │   ├── pre-push.sample
│   │   ├── pre-rebase.sample
│   │   ├── pre-receive.sample
│   │   ├── prepare-commit-msg.sample
│   │   └── update.sample
│   ├── index
│   ├── info
│   │   └── exclude
│   ├── logs
│   │   ├── HEAD
│   │   └── refs
│   │       └── heads
│   │           └── master
│   ├── objects
│   │   ├── 04
│   │   │   └── fc877e35cb6c9bd038084d6b0fa8eae043884d
│   │   ├── 17
│   │   │   └── e88b45fdb1b3e8831df0c209204f290d6ca614
│   │   ├── af
│   │   │   └── 5626b4a114abcb82d63db7c8082c3c4756e51b
│   │   ├── info
│   │   └── pack
│   └── refs
│       ├── heads
│       │   └── master
│       └── tags
└── l_helloworld.txt

16 directories, 24 files

では早速ファイルを追加してみます。

$ echo "create new one" > l_createnewone.txt
$ echo "Hello, world!" > l_helloworld2.txt
$ ls
l_createnewone.txt  l_helloworld.txt  l_helloworld2.txt

前回作った「l_helloworld.txt」と同じ内容で「l_helloworld2.txt」を作りました。
この状態でインデックスにファイルを追加します。

.
├── .git
│   ├── objects
│   │   ├── b4
│   │   │   └── c191b61e50e6416dfa68f3042973539b2655f5

2つのファイルを追加したはずなのになぜかobjectsには1つのファイルしか追加されていません。gitはblobオブジェクトのハッシュ値はファイルの内容で決まっています。「l_helloworld2.txt」は「l_helloworld.txt」と全く同じ内容だったので、新しくオブジェクトが作られていません。
新しく作られたb4c191b61e50e6416dfa68f3042973539b2655f5の中身を見てみます。

$ git cat-file -p b4c191b61e50e6416dfa68f3042973539b2655f5
create new one

ついでに「l_helloworld.txt」の中身を書き換えてからcommitしてみます。

$ cat l_helloworld.txt
Hello, world!
Add new line
$ git add .
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   l_createnewone.txt
        modified:   l_helloworld.txt
        new file:   l_helloworld2.txt

差分は以下の通りです。

.
├── .git
│   ├── objects
│   │   ├── 56
│   │   │   └── 2f17cd3ece43f0d38e93ace1048baec07beeda

中身を確認します。

$ git cat-file -p 562f17cd3ece43f0d38e93ace1048baec07beeda
Hello, world!
Add new line

内容が書き換わったので、新たなハッシュ値としてオブジェクトが追加されました。

git commit

では、コミットしてみます。

$ git commit -m "2nd commit. add and modify"
[master 2deb1b0] 2nd commit. add and modify
 3 files changed, 3 insertions(+)
 create mode 100644 l_createnewone.txt
 create mode 100644 l_helloworld2.txt

オブジェクトの変更点を確認します。

├── .git
│   ├── objects
│   │   ├── 2d
│   │   │   └── eb1b0751cbfeffdc75683b2f61e476ef970640
│   │   ├── e6
│   │   │   └── c5d9e73c33771f1878aa6edc1a5df1939e6351
$ git cat-file -t 2deb1b0751cbfeffdc75683b2f61e476ef970640
commit
$ git cat-file -p 2deb1b0751cbfeffdc75683b2f61e476ef970640
tree e6c5d9e73c33771f1878aa6edc1a5df1939e6351
parent 17e88b45fdb1b3e8831df0c209204f290d6ca614
author Chapa <hoge@hoge.com> 1581171878 +0900
committer Chapa <hoge@hoge.com> 1581171878 +0900

2nd commit. add and modify
$ git cat-file -t e6c5d9e73c33771f1878aa6edc1a5df1939e6351
tree
$ git cat-file -p e6c5d9e73c33771f1878aa6edc1a5df1939e6351
100644 blob b4c191b61e50e6416dfa68f3042973539b2655f5    l_createnewone.txt
100644 blob 562f17cd3ece43f0d38e93ace1048baec07beeda    l_helloworld.txt
100644 blob af5626b4a114abcb82d63db7c8082c3c4756e51b    l_helloworld2.txt

今回のcommitで複数のblobオブジェクトが紐づいていることがわかりました。
また「parent 17e88b45fdb1b3e8831df0c209204f290d6ca614」から親となるcommitオブジェクトとの紐づけがされていることもわかります。

今回のおさらい

今回は、すでにcommitがされているリポジトリに対して、ファイルの追加・変更を実施したうえでインデックスへの追加、リポジトリへのcommitを実施しました。
ファイルの内容からハッシュ値が作られること、2回目のcommitオブジェクトには、親となるcommitオブジェクトのハッシュ値が記載されていることがわかりました。

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

Cent OS8のコマンドラインでGitを使う為の準備

参考

https://xn--o9j8h1c9hb5756dt0ua226amc1a.com/?p=1434
https://qiita.com/kusanoiskuzuno/items/c323446f2707f9950ebb

Gitの準備

  • Gitのインストール
$ sudo yum install git
  • Gitのバージョンを確認
$ git version
  • テストリポジトリを作成
$ mkdir /home/ユーザー名/testrepo.git
  • リポジトリを初期化

cdコマンドで先程作成した/home/ユーザー名/testrepo.gitまで移動して、

$ git init

を実行する。

Visual Studio Codeの準備

  • rpmをインポート設定
$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo'
  • アップデートをチェックして、yumでインストール
$ sudo yum check-update
$ sudo yum -y install code

その後、Visual Studio Codeを日本語化。
codeコマンドでVisual Studio Codeを起動する。

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

バージョン管理について

はじめに

エンジニアとして最低限知っておくべきバージョン管理についての基礎についてまとめる。私自身エンジニア歴3年にも関わらずずっと少人数チームにいたせいで(?)まともにバージョン管理について意識して来なかったため自分用の情報整理のために残そうと思った次第である。

バージョン管理とは

複数人で進行するプロジェクトの中で、更新されていく成果物(ソースコード、ドキュメントなど)の変更の履歴を記録として残していくことである。

ここで言う変更の履歴とは「いつ」、「誰が」、「何を」、「どのように」手を加えたかを後から振り返った時に確認できる形にしてあるものを指す。

バージョン管理の分類

バージョン管理は大きく分けて「集中型」と「分散型」に分類される。

集中型バージョン管理(CVS,SVNなど)

ネットワーク上のサーバにリポジトリを作成しメンバはそこから最新のファイルを取得(update)しローカルで編集した後、編集が完了したら直接リポジトリに反映(commit)させる。
SVN.png

メリット
  • 構造が単純
デメリット
  • 柔軟性が低い
  • ネットワーク上のリポジトリにアクセスできないと変更履歴を刻めない

分散型バージョン管理(Gitなど)

こちらはネットワーク上のサーバだけでなく各ローカル環境にもリポジトリを作成する。
基本的には以下のようなフローとなる

  1. メンバーはサーバ上のリモートリポジトリをローカルリポジトリとしてローカル環境に複製する。
  2. 複製したローカルリポジトリから最新のファイルを取得し編集する。
  3. 編集した内容はローカルのリポジトリに対して反映していく。
  4. 2と3を繰り返しある程度まとまった内容がローカルリポジトリに反映できたらローカルリポジトリの内容をリモートリポジトリに反映する。 git.png
メリット
  • ネットワーク上のリポジトリにアクセスできない状態でもローカルリポジトリに変更履歴を残していける
  • ローカルリポジトリの下にさらにリポジトリを作るなどの階層構造を取れる
  • ローカルリポジトリはリモートリポジトリの複製であるためリモートリポジトリのバックアップを兼ねる(障害に強い)
デメリット
  • 集中型と比較して複雑で、操作や構造を正しく理解する必要がある

まとめ

  • バージョン管理には集中型と分散型がある
  • それぞれメリット、デメリットがあるためプロジェクトがどちらに適しているか見極める必要がある
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git初心者のためのGitコマンド集

はじめに

この記事ではGitのコマンド集をまとめたものです。

ですので、本記事は

・プログラミング初心者
・Gitをこれから勉強しようと思っている人
・Gitは難しそうだからなかなかて手を出せずにいる人

を対象に書いていますので、ぜひ最後までご覧いただけますと幸いです。

また、本記事はUdemyの「もう怖くないGit!チーム開発で必要なGitを完全マスター」(山浦清透さん)という講座で勉強しながら、その内容を基にまとめております。
→Udemyの講座はこちら

本記事を書いた理由

本記事を書いた理由は

駆け出しエンジニアが現場で出てGitに1番苦労する

と言われているからです。

執筆者である私自身、受託開発メインの企業様に内定をいただいているものの、実務未経験ですので
「Gitが重要すぎる・・・もっと勉強していればよかった・・・」
と実際に体感したことではないのですが、

一足先にエンジニア転職された先輩方や現役エンジニアの方々が口を揃えて

未経験の人は実務が始まるまでにGitを勉強しておいた方が良い!!!

とおっしゃっています。(僕調べ)

ですので、プログラミング初心者に向けてGitの概要、コマンド集をまとめてみようと思いました。
(あとは僕自身の勉強のためです)

※まだ勉強途中ですが、区切りの良いところまで勉強が終わったので、現時点で投稿します。
引き続き勉強をしていきますのでどんどん追記していきます。

Gitとは?

ズバリ、「ファイルのバージョン管理ツール」です。
開発しているファイルが現在どの状態にあるか、これまでどのような修正を誰がしてきたかを管理するためのものです。

こちらにもわかりやすく解説されていますのでご参考までに。
サルでもわかるGit入門

Gitの使い方

Gitはパソコンに標準で搭載されている黒い画面(笑)を使っていきます。

Macではあればターミナル、Windowsであればコマンドプロンプトを使用します。

Gitによるだファイルのバージョン管理をするためには、
まずはGitをインストールする必要があります。
MacではGitが標準でインストールされているのでインストールする必要はありませんが、
Windowsの場合はおそらくインストールが必要となります。(インストールはこちら

コマンド集

それではGitで使用するコマンドを種類と使い方について解説していきます。

git version

インストールされているGitのバージョンを表示

git config --global user.name "GitHubの名"

初期設計。Gitにユーザー情報(ユーザー名)を登録

git config --global user.email GitHubのメールアドレス

初期設計。Gitにユーザー情報(メールアドレス)を登録

git config --global core.editor "エディター名 --wait"

初期設計。Gitにエディターを登録

git config user.name

登録したユーザー名を表示

git config user.email

登録したメールアドレスを表示

git config core.editor

登録したエディターを表示

git config --list

Gitの設定を一気に確認する場合に使う

cd ディレクトリ名

ディレクトリに移動
change directoryの略

ls

現在のディレクトリの中身を表示

ls -a

現在のディレクトリの中身を隠しファイルを含め表示
ls デイレクトリ名と入力するとそのディレクトリの中身を表示することができる
-aのaはallの意味

mkdir ディレクトリ名

ディレクトリを新規作成
make directoryの略

mv ファイル名

ファイルを移動する(ファイル名を変更する)

cp ファイル名

ファイルをコピーの作成

cat ファイル名

ファイルの中身を表示

git init

.gitディレクトリ(ローカルリポジトリ)を作成(ディレクトリ=ファイル)
initはinitializeの略

実際にGitを使ってファイルのバージョン管理を始める時に最初に使うコマンド

ちなみに、.gitディレクトリは隠れファイルなので実際にフォルダの中を見ても(もしくはlsコマンドで見ても).gitディレクトリはありません。
.gitディレクトリができているか確認するためにはls -aコマンドで確認してください。

git clone リポジトリ名

すでに作られているgitリポジトリ(GitHub)のコピーを自分のワークツリーに作成する

git add

変更をステージに追加する(ワークツリー→ステージ)

git add ファイル名
ファイル名のファイルの変更をステージに追加する

git add ディレクトリ名
デイレクトリ名のディレクトリの全てのファイルの変更をステージに追加する

git add .
ワークツリーにある全てのディレクトリの全てのファイルの変更をステージに追加する

基本的には
git add ファイル名git add ディレクトリ名が使われる

git commit

変更を記録する(コミットする、という)
(ステージ→リポジトリにスナップショットを登録)

git commit
Gtiのエディターを立ち上げてコミットする
Gitのエディターにメッセージを記述するとメッセージ付きでコミットできる
(Gitのエディターは勝手に立ち上がります)

git commit -m "メッセージ"
Gitのエディターを立ち上げることなくメッセージ付きでコミットできる
いちいちGitのエディターが立ち上がるのが鬱陶しい人はこのコマンドがオススメ

git commit -v
変更したファイルの変更内容もGitのエディターに表示することができる(ファイル名+変更内容が表示される)
通常のgit commitの場合、変更したファイルのファイル名しかわからない

git status

変更されたファイルの変更状況を確認する

git diff

変更差分を確認する
diffはdifferenceの略

git addする前の変更差分を確認する方法(ワークツリーとステージの差分)

git diff
変更差分を確認する
git diff ファイル名
特定のファイルの変更差分を確認する

git addした後の変更差分を確認する方法(ステージとリポジトリの差分)

git diff --staged
stagedとあるので「ステージにaddされた」という意味ですね。

git log

変更履歴を表示する
オプションコマンドとしては以下がある

git log --oneline
変更履歴を一行で表示する

git log -p ファイル名
特定のファイルのみの変更履歴を表示するう

git log -n 数字
直近の数字回の変更履歴のみ表示する

git rm

ファイルの削除を記録する
rmはremoveの略

ファイルごと削除(ワークツリー、リポジトリから削除)

git rm ファイル名
ファイルの削除を記録する
git rm -r ディレクトリ名
ディレクトリの削除を記録する

ファイルを残したい時(リポジトリからのみ削除)

ファイルは必要だけどGitの記録からだけ削除したい場合
git rm --cached

git mv 旧ファイル名 新ファイル名

ファイルの移動(=ファイル名の変更)を記録する
mvはmoveの略
ワークツリーのファイル名の変更はステージにも反映される
以下3行のコマンドでも同じ操作ができる
rm 旧ファイル 新ファイル
git rm 旧ファイル
git add 新ファイル

git remote add リモート名 リモートリポジトリのURL

任意のリモート名(ショートカット)でURLのリモートリポジトリをGitに登録する

リモート名=リポジトリ名ではなくてOKです。
ここでいうリモート名というのは作成済みのリモートリポジトリをGit上で使うための略称をつけるイメージ。
SQL文のasみたいなもの。

ローカルの内容をGitHubなどのリモートリポジトリにアップする(プッシュする)前準備として使う
このコマンドを入力しなければプッシュする時に毎回リモートリポジトリのurlを入力しなければならない

git push リモート名 ブランチ名

GitHubなどのリポートリポジトリにローカル(ローカルリポジトリ)の内容をアップすることをプッシュするという。
開発での一連の流れは
1.ワークツリー→ローカルリポジトリにコミット
2.ローカルリポジトリ→リモートリポジトリ(GitHub)にプッシュ
コミットした内容をプッシュするという流れ
具体的なコマンドの使い方はgit push origin masterで使う

git push -u リモート名 ブランチ名

-uをつけると次回プッシュ時以降、
git pushと入力するだけでgit push origin masterとして操作可能
コマンドの登録みたいなイメージ

コマンドにエイリアス(別名)をつけて登録する

代表的なものは以下だが、
他にも自分で「このコマンド長いな〜」っていうコマンドがあれば同様にエイリアスをつけて簡単にできる

git config --global alias.ci commit

commitciとして登録する
git ciと入力するとgit commitと入力した場合と同じ結果を得ることができる

git config --global alias.st status

statusstとして登録する

git config --global alias.br branch

branchbrとして登録する

git config --global alias.co checkout

checkoutcoとして登録する

touch ファイル名

空ファイルを作成する

git checkout

ファイルへの変更を取り消す

git checkout -- ファイル名
特定のファイルの変更を取り消す

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

git checkout -- .
全変更を取り消す

--をつけているにはブランチ名とファイル名が被った時にどちらを指しているのかGitがわからなくなるのを防ぐため

git reset HEAD

ステージに追加した変更を取り消す

git reset HEAD ファイル名
特定のファイルのステージに追加した変更を取り消す

git reset HEAD ディレクトリ名
特定のデイレクトリのステージに追加した変更を取り消す

git reset HEAD .
全てのステージに追加した変更を取り消す

ステージに追加した変更を取り消すだけなので、ワークツリーのファイルには影響しない

git commit --amend

直前のコミット(ステージ→ローカルリポジトリ)をやり直す
リモートリポジトリにプッシュしたコミットはやり直したらいけない

git remote

登録(設定)しているリモートリポジトリのリポジトリ名を表示する

git remote -v
登録(設定)しているリモートリポジトリのリポジトリ名+URLを表示する

git fetch リモート名

リモートから情報を取得する(フェッチ)
取得した情報はローカルリポジトリに追加される。
ワークツリー(自分のPCでの作業場)には反映されない。
ワークツリーに反映するためにはgit mergeコマンドを使用する。
(後ほど解説します)

git pull リモート名 ブランチ名

リモートから情報を取得してマージ(ステージ→ワークツリー)する
git fetch+git mergeと同じ操作

git remote show リモート名

リモートコの詳細情報を表示する
git remoteより詳しい情報が表示される

git remote rename 旧リモート名 新リモート名

リモー名トを変更する

git remote rm

リモートを削除する

おわりに

本記事ではGitコマンド集をまとめました。
コマンド毎のまとまりはありませんが、
最後まで読んでいただきありがとうございます。感謝です。

内容はいかがだったでしょうか。
ぜひ、いいねコメントをいただけましたら今後のモチベーションに繋がりますし、
単純に嬉しいです。

開発現場ではGitは必須だと思うので、僕と一緒に実務に入る前にGitの基本を一通り触って、
ぜひ慣れておきましょう。

本記事は辞書のように使っていただければ便利だと思います。

ブランチ、マージ、プルリク、コンフリクトなどについてはこれから勉強していきますので
順次追記していきます。

最終的にはこの記事を見ればGitコマンドを網羅できる!!というレベルまで持って行き
少しでも多くの方の役に立てば非常に嬉しいです。

他の記事も良かったら覗いてみてくださいね!

また、僕のTwitterアカウントもフォローしていただけると嬉しいです。
https://twitter.com/shimotaroo

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

【環境構築】 Git を使えるようにする 【備忘録】

Windows で Vagrant を使って、VM (Ubuntu) に Git を導入して
GitHub に push できるようになるまでの記録です。
完全に自分用の備忘録なので、説明等ほぼありません:sweat_smile:

前提

  • Git はインストール済み
  • GitHub のアカウントは作成済み

個人の識別情報を登録する

GitHubに登録したユーザー名とメールアドレスを登録します。

$ touch ~/.gitconfig
$ git config --global user.name "(ユーザー名)"
$ git config --global user.email "(メールアドレス)"

SSH Key を作成する

$ ssh-keygen -t rsa -b 4096 -C "(メールアドレス)"

SSH Key の保存先を入力します。
passphrase を決めて、入力します。

GitHub に SSH Key を登録する

~/.ssh/id_rsa.pub の内容を全てコピーします。

GitHub にログインして、自分の Settings にアクセスします。
SSH and GPG KeysNew SSH Key をクリックします。

自分が分かるタイトルを Title に入力して、
先ほどコピーしたものを Key にペーストします。
Add SSH Key をクリックして登録完了です。

確認する

$ ssh -T git@github.com

GitHub's SSH key fingerprints と一致するか確認して、yes と入力します。

参考にさせていただいた記事

お前らのSSH Keysの作り方は間違っている
1.6 使い始める - 最初のGitの構成

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

gitignoreで指定したディレクトリが読み込まれない

現象

node_modulesディレクトリはリモートリポジトリへpushしなくてよいので、プロジェクトの最上層ディレクトリに.gitignoreを作成し、

.gitignore
node_modules/

を記載。しかし、
git add *するとあらゆるnode_modules/内のファイルがステージされてしまう。

ポイント

.gitignoreは、
「ファイル名」で指定すると配下のフォルダすべてから同名のファイルをすべて該当させるが、
「ディレクトリ名」の場合は現在位置からの相対パスの記載が必要になる。

原因と対処

.gitignore設置ディレクトリからみたnode_modulesディレクトリの位置が

./project/app1/node_modules/

となっていたため、

.gitignore
/project/app1/node_modules/

のように記載。

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

備忘録_レンタルサーバーにLaravelのプロジェクト作って、git管理する

Laravelのプロジェクトを作る

  1. composerが動く環境を用意する

    備忘録_レンタル共用サーバーでcomposerを使う 参照

  2. プロジェクトを作成する

    composer create-project --prefer-dist laravel/laravel ~/{プロジェクト名} "5.8.*"

  3. (動作確認用)

    ln -s {ドキュメントルート} ~/{プロジェクト名}/public

git管理する

  1. さっき作ったプロジェクトのディレクトリに移動

    cd ~/{プロジェクト名}

  2. リポジトリ作る(ついでに、開発用ブランチも作ったりする)

    git init
    git add -A
    git commin -m "init"
    
    git checkout -b developer
    
    mkdir ~/git_repo
    git clone --bare ~/{プロジェクト名} ~/git_repo/{プロジェクト名}.git
    
  3. ローカルに落とす

    git clone {レンタルサーバーのユーザー名}@{レンタルサーバーのSSHドメイン}:git_repo/{プロジェクト名}.git

いやーーーーー

「git clone」とかで調べてもよく分からず詰まってましたが、最終的にgit公式のドキュメントが全て解決してくれました。

【まずは、公式ドキュメントから読む】はマジで癖つけんとアカンです。。。

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