20190227のGitに関する記事は6件です。

Sakura EditorでGit管理フォルダを除外してGrepする

経緯

サクラエディタでGrep検索時、Git管理フォルダ(.git)を除外して検索したい

フォルダを除外すればよいはず

ググラビリティ不足なのか見つからない

ヘルプ見てみたらちゃんと書いてあった!

ファイルパターンの先頭に#を付ける(例: #*.svn)と、そのパターンに当たるサブフォルダをGrep対象から外します。(sakura:2.1.0.0以降)


と、いうことで以下のようにファイルパターンを指定すればちゃんと除外できました。

#*.git *.*

他のバージョン管理フォルダ(.svn等)や、ログフォルダなどもこれでうまいこと除外できます。
ヘルプ記載の通り、バージョン2.1.0.0以降を使用する必要があります。

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

git理解メモ

はじめに

なんとなーくadd,commit,push,pullくらいを軽く使うくらいしかしておらず理解が浅かったのですが、
svnを卒業してgitを使っていくこととなったので
学んだ内容をメモとしてまとめました

もし間違ってるところや、補足などがあれば
ぜひぜひコメントくださいmm

また、設定回りの記事も書いたのでよかったらこちらも
gitを便利にしよう めも

目次

ざっくりイメージ図
作業ごとの処理流れ(ざっくり)
  新しく管理を始める
  ファイルを変更したものを確認する
  ファイルを変更したものをリモートへ反映させる
  リモートから新しいコミット内容を取得する
コマンド解説

clone init remote status diff
log add rm mv commit
reset push fetch merge rebase
pull branch checkout branch

用語解説
 HEAD
 SHA-1
 上流ブランチ(Upstream branch)
 リモート追跡ブランチ
 detached HEAD
 プルリクエスト
まとめ
参考資料

ざっくりイメージ図

ブランチのイメージ図
image.png

ソース管理の動き図(受信)
image.png

ソース管理の動き図(送信)
image.png

作業ごとの処理流れ(ざっくり)

新しく管理を始める

cloneでの方法
  1. github、bitbucket、gitlabなどのgitホスティングサービス?にて リポジトリを作成
  2. git clone ${新しいリポジトリのパス} にてローカルにリポジトリの複製
    ※ この際にリモートとのひも付きも作られる
自分で紐づける方法
  1. github、bitbucket、gitlabなどのgitホスティングサービス?にて リポジトリを作成
  2. ローカルにて管理する場所の用意(ディレクトリの作成)
  3. git initにてgit管理用の設定ファイルなどの作成
  4. git remote add origin ${新しいリポジトリのパス} にてリモートと紐付ける
  5. add -> commit -> pushの流れ ※別途解説

ファイルを変更したものを確認する

  • git statusにて変更ファイルなどを確認
  • git diffにて変更差分を確認

ファイルを変更したものをリモートへ反映させる

  1. 対象のファイルをaddする
  2. すべての変更が揃ったらcommitする
  3. commitした内容をリモートへpushする

リモートから新しいコミット内容を取得する

  1. fetch + merge もしくは pullをする

コマンド解説

clone

指定されたディレクトリに元のリポジトリと同じものを複製するコマンド

git clone [クローンしたいリポジトリ] [クローン先のディレクトリ(省略可)]

クローン先を省略するとクローンしたいリポジトリと同一の名称のディレクトリが生成される

例:

$ git clone https://github.com/rytkmt/dotfiles.git

init

git管理のための初期化を行うコマンド
対象ディレクトリに.gitディレクトリが生成される

git init [初期化したいディレクトリ(省略可)]

ディレクトリを省略すると、カレントディレクトリとなる


remote

リモートリポジトリを追加・削除・確認・変更するコマンド

追加

git remote add [追加するリモートリポジトリ名] [追加したいリポジトリ]

削除

git remote rm [削除したいリモートリポジトリ名]

確認

git remote

確認(urlも表示)

git remote -v

変更(url)

git remote set-url origin [変更先のURL]

変更(リポジトリ名)

git remote rename [変更前リポジトリ名] [変更後リポジトリ名]

originはデフォルトで使用されるリモートリポジトリ名

例:

$ git remote
origin
$ git remote -v
origin  https://github.com/rytkmt/dotfiles.git (fetch)
origin  https://github.com/rytkmt/dotfiles.git (push)

status

ワーキングツリーの状態を表示コマンド
下記のファイルのパスをそれぞれ表示する

  • ワーキングツリーに追跡されていないもの(まだaddしたことない)
  • ワーキングツリーとインデックスに違いがあるもの(addしたものから更に変更がある)
  • コミットされたものとインデックスに違いがあるもの(コミットしてからaddされた)
オプション
  • --short
    ファイルパスと、簡略化した状態のマークで表示される

例:
a.txt, b.txt とファイルが有り
aを変更、bを削除、cを作成とした際

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    b.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:   a.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    c.txt
$ git status --short
 M a.txt
D  b.txt
?? c.txt

diff

ファイルの変更を表示するためのコマンド

下記の
<commit>HEADやらSHA-1の指定のことを意味する

ワーキングツリーとインデックスの差分を表示

git diff

ワーキングツリーとインデックスの特定のファイルの差分を表示

git diff [ファイルパス]

ワーキングツリーとコミットとの差分を表示

git diff <commit>

コミットとコミットの差分を表示

git diff <commit> <commit>

コミットとコミットの特定のファイルの差分を表示

git diff <commit> <commit> [ファイルパス]
オプション
  • --cached
    インデックス(ステージ領域)への変更を見るようになる

<commit> を省略するとHEADを指す

インデックスとコミットの差分を表示(add/rmされたものの内容確認)

git diff --chached <commit>
  • --name-only
    ファイル名だけを比較する
  • -b or --ignore-space-changes
    ファイル内のスペースの数の違いを無視する
  • -w or --ignore-all-space
    ファイル内のスペース/改行コードの違いを完全に無視する

log

コミットのログを表示する

$ git log
WARNING: terminal is not fully functional
commit e2d910d83280beb81e9196ce291b1c97437540c4 (HEAD -> master)
Author: rytkmt <r12tkmt@gmail.com>
Date:   Tue Feb 26 14:03:52 2019 +0900

    Mofify a

commit 7ce41173f6dc7312f812102818517d3a658136c7
Merge: d461a70 8c697e8
Author: rytkmt <r12tkmt@gmail.com>
Date:   Tue Feb 26 13:44:48 2019 +0900

    Merge
オプション
  • --oneline
    1コミット1行で結果を表示する
$ git log --oneline
WARNING: terminal is not fully functional
e2d910d (HEAD -> master) Mofify a
7ce4117 Merge
d461a70 Modify a
8c697e8 (origin/master, origin/HEAD) Add c / Remove b / Modify a
911b9a6 Add b
428dde2 Add a

他にもいろいろオプションにて指定できるようなので気になるひとは調べてみてください


add

ワーキングツリーの内容をインデックスに追加するコマンド

ファイルを指定

git add [ファイルパス]

正規表現でファイルを複数指定

git add *.csv

変更・削除があったファイルを全てをadd(新しく作られたファイルはaddされない)

git add -u

新規作成・変更があったファイルを全てadd(削除されたファイルはrmされない)

git add .

新規作成・変更・削除されたファイルを全てadd

git add -A

rm

特定のファイルを削除するコマンド
gitの管理から削除した履歴がインデックスに残るため、それをコミットすることリモートリポジトリの管理からも削除できる

ワーキングツリーで変更のないファイルを削除
=> addされたインデックスは削除され、deleteとしてインデックスに追加され、ワーキングツリーからも削除される

git rm [ファイルパス]
オプション
  • -d
    ディレクトリ毎削除する
  • -f
    強制的にファイルを削除する。ワーキングツリーにて変更があってもエラーにならない
  • --cached
    ワーキングツリーからは削除しない(インデックスからの削除、インデックスへの削除としての追加のみ)

mv

ファイルの名称変更、移動のためのコマンド

git mv [変更前ファイルパス] [変更後ファイルパス]

内部的に下記を行っているよう。そのため間違ってlinuxコマンドのmvをしてしまっても安心して大丈夫

  1. mv [変更前ファイルパス] [変更後ファイルパス]
  2. git add [変更後ファイルパス]
  3. git rm [変更前ファイルパス]

commit

インデックスの内容を全てまとめてローカルブランチに反映するコマンド
コミットメッセージを入力するためエディタが開かれる

git commit
オプション
  • -m [メッセージ] or --messsage [メッセージ]

    メッセージをエディタを開かず入力する

  • --amend
    最新のコミットを取り消してインデックスの内容をコミットをやり直す
    インデックスに変更が無い場合は、コミットメッセージのみを書き換えることもできる
    -mと組み合わせることも可


reset

取消を行うコマンド

git reset [モード] <commit>

[モード]は下記を意味し、指定しないときは--mixedとなる
--soft HEADの位置
--mixed HEADの位置・インデックス
--hard HEADの位置・インデックス・ワーキングツリー

どこの<commit>に戻すかを指定する

HEADの位置 はコミットを表す

コミットのみを取り消す(addまでのところに戻せる)

git reset --soft HEAD^

addしたものを取り消す(ワーキングツリーの変更時点へ戻せる)

git reset HEAD

コミットを取り消し、addの状態も取り消す(ワーキングツリーの変更時点へ戻せる)

git reset HEAD^

コミット後の変更を全て消す

git reset --hard HEAD

昔の状態で動作を確認したい(変更なども消えるため事前にpushしておくのを忘れないように)

git reset --hard <commit>

リモートリポジトリの状態と全く同じにしたい(先へも進めれる)

git reset --hard origin/master

push

ローカルリポジトリのコミットの履歴をリモートリポジトリへ送信するコマンド
リモートリポジトリに別のコミット履歴がある場合はエラーとなる(先にpullして競合解決などが必要)

リモートとローカルのブランチ名が同じ場合

git push [リポジトリ名] [ブランチ名]

リモートとローカルのブランチ名が違う場合

git push [リポジトリ名] [ローカルブランチ名]:[リモートブランチ名]

ローカルブランチを指定しない場合、リモートリポジトリを削除することができる(空を送信するイメージ)

git push [リポジトリ名] :[リモートブランチ名]

リモートブランチを削除(明示的)

git push --delete [リポジトリ名] [リモートブランチ名]

リポジトリ名、ブランチ名を省略した際は、configに設定されている現ローカルブランチの上流ブランチへ送信することとなる
上記が無い場合は、config.defaultのものが採用される。それもなければエラーとなる

オプション
  • -u
    送信したリポジトリ名、ブランチ名を上流ブランチとして設定する

例:

git push origin master

fetch

リモートリポジトリの内容を、リモート追跡ブランチへ反映するコマンド
もしローカルに該当名称のブランチがなければローカルブランチの作成もされる

指定した名称のブランチをリモートからリモート追跡ブランチへ反映する

git fetch [リポジトリ名] [ブランチ名]

リモートの全てのブランチをリモート追跡ブランチへ反映する

git fetch [リポジトリ名]

なければ作成されるというのを使って、別名としてローカルブランチを作る

git fetch [リポジトリ名] [リモートブランチ名]:[ローカルブランチ名]

merge

ローカルリポジトリのブランチの内容を、現在のブランチに反映させる

git merge [取り込みたいブランチ名]

ブランチ名はリモート追跡ブランチも指定できる

取り込むとマージコミットが作成される

: orangeブランチで git merge blue とするときのイメージ
image.png

no-fast-forward
現在のブランチと取込ブランチのそれぞれにコミットがあった場合
=> マージコミットが自動で行われ、コミットメッセージ編集のためエディターが開かれる

fast-forward
現在ブランチの先に取込ブランチがいるだけ(現在ブランチにコミットが無い)の場合
=> マージコミットは不要となる

同じ場所を変更していた場合コンフリクトするため、解消させてマージコミットを行う

オプション
  • -m [メッセージ]
    マージコミットのメッセージをエディターを開かず指定する
  • --no-ff
    fast-forwardの際もマージコミットを必要とする

例:
コンフリクトの解消

$ git merge master2
Auto-merging d.txt
CONFLICT (add/add): Merge conflict in d.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status --short
AA d.txt
d.txt
<<<<<<< HEAD
ddd
=======
d
>>>>>>> master2

rebase

rebaseは別ブランチのコミットを、特定ブランチのHEADの後ろにもってくるコマンド

これにより、ログとしては一直線の履歴となるためすっきりさせることができる

:現在blueブランチの状態でgit rebase orange
image.png

オプション
  • -i
    rebaseするブランチ(図のblueブランチ)に複数コミットがある際に、まとめて1つのコミットとして持ってくることができる エディタが開かれどのコミットをどうまとめるかを指定する pick: そのままもってくる squash: 上のコミットにまとめる(押しつぶす)※一番上のコミットはsquashにできない
-i
pick 8145f1c Fix screen rotation problem
pick d90db4a v1.2.4
pick 646bf79 Fix screen rotation problem
pick 71a6940 v1.2.4

# Rebase ed7420a..71a6940 onto ed7420a
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

image.png

git rebase HEAD~4など、いまのブランチの複数コミットをまとめることも可能
しかし、それをするとコミットのSHA-1が変更されるためリモートにすでに反映されているものがあると、pushでエラーになるのでgit push -fにて強制送信しなければならなくなる
git push -fは基本的にご法度と言われているのであまりrebaseは使わないほうがよい

そのほかにも運用により怖いリスクもあるので下記を見ておくべき
公式: Git のブランチ機能 - リベース ほんとうは怖いリベース


pull

pullは内部的にfetchmergeを行っている
1. git fetch <repository> <branch>
2. git merge FETCH_HEAD

この際に、fetchしたブランチ名をmergeするためにFETCH_HEADという

オプション
  • --no-ff mergeと同様

branch

ブランチを作成、確認、削除するためのコマンド

ローカルのブランチを表示する

git branch

リモートのブランチを表示する

git branch -r

ローカルとリモートのブランチを表示する

git branch -a

ローカルにブランチを作成する(現在のブランチから)

git branch [新しいブランチ名]

ローカルからブランチを削除する(HEADにマージされていなければエラー)

git branch -d [削除するブランチ名]

ローカルからブランチを削除する(HEADにマージ問わず)

git branch -D [削除するブランチ名]

checkout

下記の二つの処理をするコマンド

  • ①作業ブランチを切り替える
  • ②指定したコミット(もしくはインデックス)の状態を、現在の作業ツリーに展開する
  • ③特定のファイルのみ指定したコミットの状態に変更する
①作業ブランチを切り替える
git checkout [ブランチ名]

ワーキングツリーのuntrackingファイル(addしていない新しいファイル) と
インデックスの内容(addやrmされたもの)
はそのまま変更したブランチへも引き継がれる。

ブランチを切り替えると、ファイルも全て変更したブランチの状態へと変更される
=> 引き継ぐワーキングツリー、インデックスの内容と競合すると、エラーとなりブランチの切替を中止する

②指定したコミット(もしくはインデックス)の状態を、現在の作業ツリーに展開する
git checkout <commit>

特定のコミットの状態へ切り替えることができる
が、コミットを指定しているためdetached HEADとなってしまう

③特定のファイルのみ指定したコミットの状態に変更する
git checkout <commit> [ファイルパス]

HEADが変わるわけではないのでdetached HEADにはならない
該当ファイルが指定コミットの状態でワーキングツリーとインデックスに反映される

git checkout .

上記は既存ファイル(untracking以外)の変更をHEADの状態へ戻すことができる
untrackingなども考えると、インデックスが空の状態ならgit reset --hard HEADを使うほうがよい?かも

stash

ワーキングツリーの変更と、インデックスの内容を退避させておくことができるコマンド
デフォルトでは、untrackingファイルは退避されない

push

stashに登録?追加?するコマンド

git stash push
オプション
  • -p
    インタラクティブに1ファイルずつ差分が表示されstashさせる対象にするかどうかを選択するモード
  • -k
    インデックスに登録されている内容はstashをしない
  • -u
    untrackingファイルもstashする
  • -m [メッセージ]
    stashにタイトル?説明?を付ける

list

stashに登録されているものを表示するコマンド

$ git stash list
stash@{0}: On master: Add c
stash@{1}: WIP on master: Modify a
オプション

git logにて使用できるオプションを同じように使える

show

stashされているものの変更の詳細を表示するコマンド

git stash show [stash名]

[stash名]はstash@{0}など
[stash名]を省略すると、最新のstashが使われる

オプション
  • -p
    変更の内容の詳細まで表示する

apply

stashに登録された内容をワーキングツリーに反映させるコマンド
デフォルトだと、インデックスに登録された内容もnot staged(ワーキングツリーの変更状態)に戻されてしまう

git stash apply [stash名]
オプション
  • --index
    インデックスに入った状態で登録されたものはインデックスに反映させる

drop

stashに登録されたものを削除するコマンド

git stash apply [stash名]

pop

applyとdropを合わせたコマンド

git stash pop [stash名]
オプション
  • --index
    インデックスに入った状態で登録されたものはインデックスに反映させる

clear

stashに登録された内容を全て削除するコマンド

git stash clear

branch

stashに登録された内容を、stashした際のコミットの状態からブランチを作成し、stashの内容をワーキングツリーとインデックスに反映し
stashから削除し、新しいブランチへチェックアウトするコマンド

git stash branch [新しいブランチ名] [stash名]

用語解説

HEADとは

最新のコミットのことを指す

~ 〇世代前のコミットを指定できる。
^ 複数ある親コミットのなかから指定できる。

また、gitのバージョン1.8.5から
HEADのエイリアスとして@が使用できる

image.png

現状をCとすると

HEAD => C
@ => C
HEAD~ => B
HEAD~2 => A
HEAD^ => B
HEAD^2 => B'
@^2 => B'

^' と~`を連続して付けると、親の親みたいな形で辿る

image.png

現状をDとすると
HEAD^ => C
HEAD^2 => エラー(2つないから)
HEAD^^ => B
HEAD^^2 => B'
HEAD~^2 => B'

SHA-1とは

gitのリビジョン(コミット)毎に振られるハッシュ値のこと

git logなどをした際に黄色字のcommitの右に書かれているもののこと

image.png

リビジョンを指定するときにHEAD^だけでなく
SHA-1の値でも指定ができる

またSHA-1は4文字以上あればgitがよろしく一意なものを判断してくれるため全てを記入しなくてもよい

上流ブランチ(Upstream branch)とは

git remoteなどによって、ローカルブランチと紐づけられているリモートリポジトリのブランチのこと

「リモート追跡ブランチ」は特定のリモートブランチの状態をそのままコピーしたローカルブランチのことで
上流ブランチとは名称が別の可能性もあるので混同しないように注意

リモート追跡ブランチとは

リモートの状態を保持しておくためのブランチ
参照のみしかできないようになっており、かならず作られる

[リポジトリ名]/[リモートブランチ名] というブランチ名となる

このブランチがあるおかげで、毎回リモートへ接続を行わなくてもdiff/logなどの情報を確認できるようになっている

git branch -aにてリモート追跡ブランチも確認できる

detached HEADとは

git checkout <commit> にてブランチへ切り替えるのではなく、コミットへ切替を行った際に
自分のブランチがdetached HEADとなる

image.png

本来HEADはブランチを指すものだが
HEADがコミットを指す形となるためdetached(切り離された)HEADとなるよう
これは、元のHEADの位置のコミットを指定していたとしてもdetached HEADとなる

そのため、detached HEADを解消したいのであればgit checkout [ブランチ名]とすれば解消する

detached HEADの状態でもコミットを行うことができるが、ブランチが無いため宙ぶらりとなったコミットができあがる
コミットがある状態でgit checkout [ブランチ名]とすると
下記のような警告が表示される。

Warning: you are leaving 2 commits behind, not connected to
any of your branches:

  <commid-id-1> <commit-message-1>
  <commit-id-2> <commit-message-2>

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> <commit-id-1>

Switched to branch 'master'

これに従って、宙ぶらりのコミットをSHA-1の指定でブランチを作ることで
そのあとの元のブランチへマージなどへ繋げることができる

プルリクエストとは

コミットしたから見てねっていうgitホスティングサービス側(githubなど)での通知機能のこと

詳しくはこちらを
プルリクエストとは

おわりに

書き始めたら、大作となってしまった・・・
なんとなーくしか理解できていないと抵抗しかなかったですが、意味が理解できてくるとすごい勉強してて楽しい!

アウトプットって大事ですね。しっかり理解しようとするから自分にとってもプラスでした。

同じくsvnからgitへ移行される方の助けになれば幸いです。

参考資料

ありがとうございました。

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

これからLinuxやGitを学ぶ前に

はじめに

これからLinuxやGitを学んでいくので、その前提知識を学んだんので、忘備録としてまとめる。
初学者がまとめたものであるので、間違いや修正があれば連絡くださるとうれしいです。

前提知識

前提知識としてコマンドラインやLinux、Gitの概要を述べる。

コマンドライン

パソコンの操作を文字で行う入力行のこと。
例えば、ファイルを移動する、作成する変更するなど。
ターミナルという画面にコマンドラインを打ち込んでパソコンを操作することができる。
コマンドラインを学習するさいによく耳にした「UNIXコマンド」とはLinuxやMacOSで使用することのできるコマンドラインのこと

Linux

一言で表すと、UNIXというOSの一種である。
Linuxには様々な配布形式(Distribution)がある。
Ubuntuなどが有名。

Git

Gitとは、複数人で協力して開発を行う際に使用する共同開発環境である。
ターミナルで操作をすることができ、前提としてコマンドラインの知識をある程度知っておく必要がある。
Gitでは、共同で開発しているファイルを直接編集するのではなく、一度リポジトリ(編集したファイルの置き場)にアップロードされたものをダウンロードして共有することができる。
リポジトリには、リモートリポジトリとローカルリポジトリの2種類がある。
また、どの点を修正したかを表示させたりコメントに残すことができるので便利である。

コマンドライン

コマンドラインの基本操作を述べる。

操作する場所の移動やファイルの作成方法

ファイルの作成

$ touch ファイル名

ファイルの中身を表示

$ cat ファイル名

ディレクトリ(フォルダ)を作成

$ mkdir ディレクトリ名

ディレクトリの移動

$ cd ディレクトリ名

作業しているディレクトリを表示

$ pwd

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

$ ls

一番親のディレクトリを表示

$ cd ..

ホームディレクトリ(起点)に移動

$ cd

ファイルの変更や削除、移動

ファイルを移動

$ mv 移動させたいファイル 移動先のディレクトリ

ディレクトリごと移動

$ mv 移動させたいディレクトリ 移動先のディレクトリ

ファイル名やディレクトリ名の変更

$ mv 変更前の名前 変更後の名前

ファイルコピー

$ cp ファイル名 コピー先

ディレクトリのコピー

$ cp -r ディレクトリ名 コピー先

ファイルの削除

$ rm ファイル名

ディレクトリの削除

$ rm ディレクトリ名

Git コマンド

ファイルをリモートリポジトリにアップロードする準備からダウンロードまで

共有するファイルの選択

$ git add ファイル名

コメントを付ける

$ git commit -m "メッセージ"

リモートリポジトリを登録

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

リモートリポジトリにファイルをアップ

$ git push リモートリポジトリ名 リモートリポジトリのブランチ名

ダウンロード

$git pull リモートリポジトリ名 リモートリポジトリのブランチ名

変更したファイルの把握

変更したファイルがどれか

$ git status

変更内容を表示

$ git diff

コメントを見る

$ git log

変更内容を見る

$ git log -p 

さいごに

コマンドの知識を増やすことは勿論であるが、Githubの使い方やDocker等も積極的に学んでいきたい。
2回目ですが、初学者が書いた記事であるので間違いがあればご指摘よろしくお願いします。

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

Laravel 環境構築まとめ

概要

Laravelを学ぶ上で必要となる環境構築についてまとめていきます。
環境構築にはHomesteadかLaraDockを使っていくのですが、今回はHomesteadを使って環境構築していきます。Homesteadは標準で様々な機能を持っているので初めてLaravelに触れるにはHomesteadを使ったほうがいいかと思います。
macでの説明になります。

必要となるもの

必要となるものとしてgit, VirtualBox, vagrantが必要となります。
それぞれインストールできているか--versionで確認しましょう。

git --version
git version 2.17.2

vagrant --version
Vagrant 2.2.3

環境構築していく

はじめにvagrantを使ってHomesteadを使うためのBoxを追加します。

vagrant box add laravel/homestead

プロバイダの種類を聞かれると思うので、virtualboxの番号を選択しましょう。

環境によっては上記のコマンドが異様に遅いかと思います。
その時は以下の記事を参考にしてください。

Boxが追加できたらgithub上から色々と設定が入ったファイルをクローンします。
ホームディレクトリ以下にHomesteadとしてクローンします。

公式 https://github.com/laravel/laravel

git clone https://github.com/laravel/homestead.git Homestead

次にHomesteadに移動して初期化します。

cd Homestead

bash init.sh

初期化できたらHomesteadディレクトリにあるHomestead.yamlで必要であれば諸々の設定を行う必要があります。

Homestead.yaml
provider: virtualbox

folders:
    - map: ~/code
      to: /home/vagrant/code

sites:
    - map: homestead.test
      to: /home/vagrant/code/[フォルダ名]/public

色々書かれていますが、上記の3つを見ていきます。
providerには使うプロバイダの種類が入ります。
foldersには仮想環境とホストOSの間で共有するフォルダを設定します。
デフォルトではcodeディレクトリになっていると思うのでそのままにしておき後でcodeディレクトリを作ります。
sitesにはアクセスする場所を指定します。
上記ではhomestead.testにアクセスするとto:以下のものが出てくるよといったものです。
後で実際にコードを書いていく新規プロジェクトを作成するコマンドを打つのでその時に設定する名前を指定してあげます。

ホームディレクトリに戻ってcodeディレクトリの作成

cd

mkdir code

次にhostsファイルにIPアドレスを設定します。
hostsファイルの設定の仕方は以下を参照してください。

https://hazimaru.jp/820/

hostsファイルにIPアドレスを追加します。

192.168.10.10 homestead.test

Homesteadに移動してvagrantを起動させます。

cd Homestead

vagrant up

時間がかかるかもしれないです、、、

仮想環境の中に入って新規プロジェクトを作成します。

vagrant ssh

laravel new [フォルダ名]

上記のコマンドではlaravelの最新バージョンになるのでバージョンを指定したければ以下のコマンドを打ちます。

composer create-project laravel/laravel [フォルダ名] --prefer-dist "5.5.*"

上記では例としてバージョン5.5を指定しています。
ここまできたらhomestead.testにアクセスしてみます。

welcome画面が出ていれば成功です。

image.png

まとめ

laravelの環境構築についてまとめました。
色々ややこしいし時間がかかるなあと感じたのが率直な感想です。
ある程度勉強したらLaraDockを使って環境構築もしてどのぐらい違うかも理解したいです。

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

Mac で git send-email して Net/SMTP/SSL.pm がないと言われたら

エラーの内容

Gmail の SMTP server で git send-email しようとしたらエラーになった。
macOS High Sierra バージョン 10.13.6 で git のバージョンは

$ /usr/bin/git --version
git version 2.15.2 (Apple Git-101.1)

エラーメッセージは

$ /usr/bin/git send-email 0001-add-readme.patch
... 略 ...
Can't locate Net/SMTP/SSL.pm in @INC (you may need to install the Net::SMTP::SSL module) (@INC contains: /Applications/Xcode.app/Contents/Developer/usr/../Library/Perl/5.18/darwin-thread-multi-2level /Applications/Xcode.app/Contents/Developer/usr/share/git-core/perl /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2/darwin-thread-multi-2level /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .) at /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-send-email line 1450.

解決方法

$ sudo -H cpan5.18 Net::SMTP::SSL

でモジュールをインストールしたら解決した。

はまったこと

手元の環境では Homebrew でインストールした perl が存在していたため、バージョン明記して cpan5.18 とするのではなく cpan コマンドを実行したら、git send-email が使ってたのとは別のバージョンの perl に対してインストールしてて効かなかった。

教訓

エラーメッセージはちゃんと読もう(ちゃんと読んでいれば perl5.18 が使われているとわかった)

参考: Gmail を使う準備

.gitconfig に以下を記載

[sendemail]
        smtpencryption = tls
        smtpserver = smtp.gmail.com
        smtpuser = ユーザ名@gmail.com
        smtpserverport = 587

二段階認証の設定をしている場合は https://support.google.com/mail/answer/185833?hl=ja を参考にアプリパスワードを発行しておく

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

git cloneでHTTP request failedが出た時の解決法(sudo権限がない場合も紹介)

最初に

Githubで二段階認証を有効にしていると、HTTP経由でgit cloneしようとしてもエラーが出てしまう。
ssh経由であればエラーが出ないが、二段階認証をオンにしていてもHTTP経由でgit cloneする方法を調べたので紹介する。

具体的には
Linuxbrewをインストールしようとしたが

$ git clone https://github.com/Homebrew/brew ~/.linuxbrew/Homebrew


Initialized empty Git repository in /misc/home/misu/.linuxbrew/Homebrew/.git/
error:  while accessing https://github.com/Homebrew/brew/info/refs
fatal: HTTP request failed


http://wada811.blogspot.com/2014/05/failed-to-push-to-github-over-https.html

とのエラーが出てHTTPリクエストが通らない。

解決するためにやったこと

1. ~/.netrcにGithubのIDとPersonal access tokenを記述する。

~/.netrcに以下を記述

machine github.com
login Githubログイン名
password アクセストークン

アクセストークンはhttps://github.com/settings/tokens にアクセスし、Generate new tokenから得ることができます。repoだけ必ずチェックする必要があるようです。

しかしこれだけでは最初に出たエラー文と同じ結果に。この段階で解決するかもしれないので一度HTTP経由でのgit cloneを試してみてください。ここで解決すればハッピー

2. gitをアップデートする

$ git --version
git version 1.7.1

これだとgitのversionが低いので一度アップデートしてみることに。

アップデートの方法

rootユーザーの場合は(yumを使った例)

$ yum install http://opensource.wandisco.com/centos/6/git/x86_64/wandisco-git-release-6-1.noarch.rpm
$ yum install git

にて最新版のgitがインストールできます。
rootユーザーでない場合はyumが使えないのでsourceから$HOME以下にinstallします。

$ mkdir $HOME/src
$ cd src
$ wget https://github.com/git/git/archive/v2.17.1.tar.gz   
$ tar -zxvf v2.17.1      

$ mkdir ~/usr
$ cd git-2.17.1
$ make configure
$ ./configure --prefix=$HOME/usr
$ make
$ make install

その後bash_profileやzprofileに以下を追加します。(すでに$HOME/usr/binがPATHにあれば必要ありません。)

PATH="$HOME/usr/bin:$PATH"

アップデートの確認

$ which git
~/usr/bin/git

$ git --version
git version 2.17.1

とのことでアップデート完了。

git cloneの確認

gitコマンドをアップデートして同じようにHTTPS経由のgit cloneを実行するとエラー文に変化が

fatal: unable to access 'https://github.com/Homebrew/brew.git/': SSL connect error

3.関連するlibraryのアップデート

$ yum update -y nss curl libcurl

にてライブラリのアップデート行えば良いということだが、rootユーザーではないためyumが使えない。

ここで使用したのがcondaによるライブラリのインストールです。pyenvでpythonのversion管理をしているのですが、pyenvによるanaconda環境があるのでcondaコマンドを使用して必要なライブラリの最新版をインストールします。

$ conda install -c conda-forge nss
$ conda install -c anaconda curl             
$ conda install -c anaconda libcurl    

anaconda環境のPATHを通します。

$ which curl
/usr/bin/curl
$ export PATH=/path/to/anaconda3/bin:$PATH
$ which curl
~/anaconda3/bin/curl

git cloneの確認

git clone https://github.com/Homebrew/brew ~/.linuxbrew/Homebrew

Cloning into '/misc/home/xxxx/.linuxbrew/Homebrew'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 119501 (delta 14), reused 14 (delta 5), pack-reused 119466
Receiving objects: 100% (119501/119501), 28.34 MiB | 12.65 MiB/s, done.
Resolving deltas: 100% (87350/87350), done.

できた!!

まとめ

上のような手順を踏むことで問題が解決できました。
都合上rootユーザーの権限を持つことができないので、これからも環境構築に困ったらrootユーザーでない場合の対処法も紹介しようと思います!

参考文献

http://wada811.blogspot.com/2014/05/failed-to-push-to-github-over-https.html
https://stackoverflow.com/questions/21820715/how-to-install-latest-version-of-git-on-centos-7-x-6-x

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