20190728のGitに関する記事は10件です。

投稿日：2019-07-28T22:48:56+09:00

git rebaseのeditで過去のリビジョンを変更する

git rebase -i のsquashとrewordはよく使っているが、editもなんとなくわかったのでメモ。
具体例として「ファイルをあるリビジョンから別のRev.に移動する」、「リビジョンを分離する」の例を示す。

git rebae の edit の動き

リビジョン（以降Rev.）が下記のようにあるとする（上ほど古い）。

aaa1111
bbb2222
ccc3333
ddd4444
eee5555 ← HEAD

この状態から Rev.bbb2222 と Rev.ddd4444 を変更したい場合、git rebase -iで次のように bbb2222 と ddd4444 のコマンドを e（またはedit）と変更する。

pick aaa1111 change a
e bbb2222 chnage b
pick ccc3333 chnage c
e ddd4444 chnage d
pick eee5555 change e

すると、まず e と変更したRev.のうち、一番古い Rev.bbb2222 が コミットされた直後の状態となる（HEADが Rev.bbb2222を指している）。

aaa1111
bbb2222 ← HEAD

コミット直後の状態なので、modifiedなファイルもstagedなファイルもない。

リビジョンの変更の方法

ここから変更内容によって以下のように操作する。

新たなファイルの追加する場合

Rev.bbb2222 に含まれていないファイルをaddしてcommit --amendする。
1. git add ＜追加するファイル＞
2. git commit --amend

変更対象Rev.に含まれているファイルを再編集する場合

Rev.bbb2222 に含まれているファイルを変更し、addしてcommit --amendする。
1. ファイルを編集する。
2. git add ＜編集したファイル＞
3. git commit --amend

変更対象Rev.からファイルを除外する場合

reset @^で1つ前のRev.に戻る。そして除外するファイル以外をaddしてコミットする。
1. git reset @^
2. git add ＜Rev.に残すファイル＞
3. git commit

modifiedのまま残っているファイルは、以下のように処理する。
・変更を捨てるならcheckoutする。
・直後に別なRev.としてコミットするならaddしてcommitする。
・もっと先のRev.で使うなら一旦stashする。

rebase --continue

Rev.bbb2222 に対する編集が終わったら git rebase --continue を実行する。
すると次の変更対象Rev.の Rev.ddd4444 に移動する（HEADが Rev.ddd4444 を指すようになる）。
Rev.ddd4444の変更が終わって git rebase --continue を実行すると、git rebase が完了する。

例

具体例として

y.into@pc01 MINGW64 /c/git_test (master)
$ git log --oneline --name-status -4
41f8473 (HEAD -> master) change d
M       d1.txt
M       d2.txt
d07aa72 change c
M       c1.txt
f721de1 change b
M       b1.txt
M       b2.txt
1109412 change a
M       a1.txt
M       a2.txt
M       c2.txt

という状態から次の変更を git rebase で行う。

Rev.1109412 "change a" に含まている c2.txt の変更を Rev.d07aa72 "chanage c" に移す。
Rev.f721de1 "change b" を2つのRev.に分割する。

環境は Windows10、Git for Windows、gitbash。

まず、git rebase -i @~4 を実行する。

pick 1109412 change a
pick f721de1 change b
pick d07aa72 change c
pick 41f8473 change d

# Rebase 1544237..41f8473 onto 41f8473 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
＜以下略＞

変更対象のRev.1109412、f721de1、d07aa72 のコマンドを "e"（＝edit）と変更する。

e 1109412 change a
e f721de1 change b
e d07aa72 change c
pick 41f8473 change d

viを終了すると、最初の変更対象Rev.である Rev.1109412 をコミットした直後の状態となる（HEADが Rev.1109412 を指している）。

y.into@pc01 MINGW64 /c/git_test (master)
$ git rebase -i @~4
Stopped at 1109412...  change a
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git status
interactive rebase in progress; onto 1544237
Last command done (1 command done):
   edit 1109412 change a
Next commands to do (3 remaining commands):
   edit f721de1 change b
   edit d07aa72 change c
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'master' on '1544237'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git log --oneline --name-status -1
1109412 (HEAD) change a
M       a1.txt
M       a2.txt
M       c2.txt

reset で1つ前のRev.に戻し、残したい変更だけaddしてcommitする。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git reset @^
Unstaged changes after reset:
M       a1.txt
M       a2.txt
M       c2.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git status
interactive rebase in progress; onto 1544237
Last command done (1 command done):
   edit 1109412 change a
Next commands to do (3 remaining commands):
   edit f721de1 change b
   edit d07aa72 change c
  (use "git rebase --edit-todo" to view and edit)
You are currently splitting a commit while rebasing branch 'master' on '1544237'.
  (Once your working directory is clean, run "git rebase --continue")

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:   a1.txt
        modified:   a2.txt
        modified:   c2.txt

no changes added to commit (use "git add" and/or "git commit -a")

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git add a1.txt a2.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git commit -m 'change a'
[detached HEAD dcd363b] change a
 2 files changed, 2 insertions(+)

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git log --oneline --name-status -1
dcd363b (HEAD) change a
M       a1.txt
M       a2.txt

残されたmodifiedな c2.txt は後のRev.に追加するのでstashで退避しておく。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git status
interactive rebase in progress; onto 1544237
Last command done (1 command done):
   edit 1109412 change a
Next commands to do (3 remaining commands):
   edit f721de1 change b
   edit d07aa72 change c
  (use "git rebase --edit-todo" to view and edit)
You are currently splitting a commit while rebasing branch 'master' on '1544237'.
  (Once your working directory is clean, run "git rebase --continue")

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:   c2.txt

no changes added to commit (use "git add" and/or "git commit -a")

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git stash push
Saved working directory and index state WIP on (no branch): dcd363b change a

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git status
interactive rebase in progress; onto 1544237
＜省略＞

nothing to commit, working tree clean

最初の変更対象Rev.の操作は終わったので、git rebase --continue で次の変更対象Rev.まで進む。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 1/4)
$ git rebase --continue
Stopped at f721de1...  change b
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git status
interactive rebase in progress; onto 1544237
Last commands done (2 commands done):
   edit 1109412 change a
   edit f721de1 change b
Next commands to do (2 remaining commands):
   edit d07aa72 change c
   pick 41f8473 change d
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'master' on '1544237'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git log --oneline --name-status -1
207e142 (HEAD) change b
M       b1.txt
M       b2.txt

第2の変更対象である Rev. は2個に分割する。
resetで1つ前のRev.に戻した後、2つのファイルをそれぞれ別々にコミットする。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git reset @^
Unstaged changes after reset:
M       b1.txt
M       b2.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git status
interactive rebase in progress; onto 1544237
Last commands done (2 commands done):
   edit 1109412 change a
   edit f721de1 change b
Next commands to do (2 remaining commands):
   edit d07aa72 change c
   pick 41f8473 change d
  (use "git rebase --edit-todo" to view and edit)
You are currently splitting a commit while rebasing branch 'master' on '1544237'.
  (Once your working directory is clean, run "git rebase --continue")

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:   b1.txt
        modified:   b2.txt

no changes added to commit (use "git add" and/or "git commit -a")

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git add b1.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git commit -m 'change b1'
[detached HEAD b23ff21] change b1
 1 file changed, 1 insertion(+)

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git add b2.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git commit -m 'change b2'
[detached HEAD fb3874d] change b2
 1 file changed, 1 insertion(+)

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git log --oneline --name-status -2
fb3874d (HEAD) change b2
M       b2.txt
b23ff21 change b1
M       b1.txt

第2の変更対象Rev.の操作も終わったので、git rebase --continueで最後の変更対象Rev.に進む。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 2/4)
$ git rebase --continue
Stopped at d07aa72...  change c
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git status
interactive rebase in progress; onto 1544237
Last commands done (3 commands done):
   edit f721de1 change b
   edit d07aa72 change c
  (see more in file .git/rebase-merge/done)
Next command to do (1 remaining command):
   pick 41f8473 change d
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'master' on '1544237'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git log --oneline --name-status -1
41567ce (HEAD) change c
M       c1.txt

Rev.89f04bc "change c" に Rev.9b59dca "change a" から取り除いた c2.txt を追加する。
stashから取り出してaddしてcommit --amendする。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git stash pop
interactive rebase in progress; onto 1544237
Last commands done (3 commands done):
   edit f721de1 change b
   edit d07aa72 change c
  (see more in file .git/rebase-merge/done)
Next command to do (1 remaining command):
   pick 41f8473 change d
  (use "git rebase --edit-todo" to view and edit)
You are currently splitting a commit while rebasing branch 'master' on '1544237'.
  (Once your working directory is clean, run "git rebase --continue")

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:   c2.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (28cf2135c67665f5ca212664692fd66ad8a5d050)

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git status
interactive rebase in progress; onto 1544237
Last commands done (3 commands done):
   edit f721de1 change b
   edit d07aa72 change c
  (see more in file .git/rebase-merge/done)
Next command to do (1 remaining command):
   pick 41f8473 change d
  (use "git rebase --edit-todo" to view and edit)
You are currently splitting a commit while rebasing branch 'master' on '1544237'.
  (Once your working directory is clean, run "git rebase --continue")

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:   c2.txt

no changes added to commit (use "git add" and/or "git commit -a")

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git add c2.txt

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git commit --amend --no-edit
[detached HEAD 90c4996] change c
 Date: Sun Jul 28 20:44:25 2019 +0900
 2 files changed, 2 insertions(+)

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git log --oneline --name-status -1
90c4996 (HEAD) change c
M       c1.txt
M       c2.txt

3つのRev.の変更が終わったので最後の git rebase --continue で作業完了。
下記のgit logの結果にあるようにRev.の変更がなされた。

y.into@pc01 MINGW64 /c/git_test (master|REBASE-i 3/4)
$ git rebase --continue
Successfully rebased and updated refs/heads/master.

y.into@pc01 MINGW64 /c/git_test (master)
$ git log --oneline --name-status -5
5043827 (HEAD -> master) change d
M       d1.txt
M       d2.txt
90c4996 change c
M       c1.txt
M       c2.txt
fb3874d change b2
M       b2.txt
b23ff21 change b1
M       b1.txt
dcd363b change a
M       a1.txt
M       a2.txt

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T22:44:04+09:00

GithubへのpushでPermission denied (publickey)が出た時の対処法

$ git push origin masterを実行した際に次のエラー文が返ってきました。
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
対象のリポジトリへのアクセス権限がなくプッシュは許可されなかった。

１：鍵を作成する
$ ssh-keygen -t rsa -C GitHubに登録したメールアドレス
Enter file in which to save the key (/home/vagrant/.ssh/id_rsa):
  [鍵ファイルを保存するフォルダはどこか]
Enter passphrase (empty for no passphrase):
  [パスフレーズを入力してください]
Enter same passphrase again:
  [パスフレーズを再度入力してください]
・ssh-keygenは認証用の鍵を作成するコマンド
・-t rsa はRSA暗号というタイプの暗号鍵を生成する
・ssh-keygen実行時の質問はEnterを３回で先へ進める
・パスフレーズはパスワードのようなもの

２：ssh-agentへ登録する
$ ssh-add -K ~/.ssh/github
3：登録の確認
$ ssh-add -l
The agent has no identities.（登録できていない）
2048 SHA256:ReBd~~~~~~~(RSA)（登録完了）

４：作成した鍵をコピーする

鍵ファイル id_rsa id_rsa.pubができているか確認
$ ls ~/.ssh/
id_rsa id_rsa.pub
id_rsaが秘密鍵
id_rsa.pubが公開鍵
→この公開鍵をgithubに登録し直す

id_rsa.pubを開く

$ less ~/.ssh/id_rsa.pub
↓こんな文字列が書かれているかと思います。鍵の情報です。
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx mail@mail.com
id_rsa.pubの中の文字列 ssh-rsa〜xxxxxの終わりまでをコピーします。 （mail@mail.comは不要です）
５：githubで鍵を登録する

次はgithubのマイページで、この鍵を登録します。
GitHub右上プロフィール画面、settings → SSH and GPG keys → new keysの順でクリックする
先ほどコピーした（xxxxx）を公開鍵 id_ras.pubの文字列をkeyの箇所に貼り付ける

６：ターミナルで設定する

configファイルを作成する
$ vim ~/.ssh/config   
~/.ssh/config

を実行して、以下のコードを貼り付ける

Host github.com
  HostName github.com
  IdentityFile ~/.ssh/id_rsa
  User git
7:接続確認
$ ssh -T git@github.com
Hi xxxxxxxxx! You've successfully authenticated, but GitHub does not provide shell access.
これでsuccessfullyの文字が出れば接続成功！

再度、$ git push origin masterを実行する

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T20:36:39+09:00

git rebase の使い方を覚える

記事を書くきっかけ

ゴールデンウイークにgitのハンズオン勉強会に参加していました。
https://oss.connpass.com/event/129794
今は7月の終わりです。三ヶ月弱経ってから当時の資料を見直すと、もう何をやっていたのか思い出せません…。
そこで、記憶に定着させるために自分自身で記事を書いてみたいと思います。

適宜、勉強会で使用されたスライドを確認します。
https://kslides.page.link/2019-05-01_GitLv3

環境

MacBook Air (13-inch, 2017)
macOS Mojave 10.14.6
git version 2.21.0
Sourcetree Version 3.1.2(216) ※コミットログの確認に使用します

準備

以下のコマンドを実行し、コミットを作成しておきます。
REPOS_NAME=repos35

cd
rm -rf $REPOS_NAME
mkdir $REPOS_NAME
cd $REPOS_NAME
git init
echo 1 > 1.txt && git add . && git commit -m "1"
echo 2 > 2.txt && git add . && git commit -m "2"
echo 3 > 3.txt && git add . && git commit -m "3"
echo 4 > 4.txt && git add . && git commit -m "4"
git checkout -b BranchX HEAD~~
echo A > A.txt && git add . && git commit -m "A"
echo B > B.txt && git add . && git commit -m "B"
git log --graph --all --oneline
作成後のコミットツリーをSourceTreeで確認すると、次のようになります。

masterブランチの 2.txt が追加されたコミット。画像だと「e830b49」のコミットを起点とし、
masterブランチでは、「f27dd54」「01d1a9a」のコミットが、
BranchXブランチでは、「45f4255」「ea5e56c」のコミットが追加されています。

この準備作業は何度も行うので、コミットIDはそのたびに変わります。

以降では、コミットの説明にある、1, 2, 3, 4, A, Bで、コミットの識別をします。

git rebase

git rebase -i　からできる操作をいくつか確認します。

コミットの削除

準備

現在はBranchXのHEAD（コミットBの後ろ）にいます。
この状態からコミットAを削除するために、git rabase を使用します。
git rebaseには -i オプションをつけます。git rebase -i のあとに、コミット2のIDを指定します。

余談ですが、rabaseは「土台」という意味で、特定のコミットを土台にして作業することを意味するようです。
コミット2のIDを指定するのは、「コミット2を土台としてコミットを編集する」ことですね。

-i オプションは「--interactive」の略で、interactiveは「対話的」を意味します。
まとめると、「コミット2を土台としてコミットを編集する」を「対話的」に行う。ということでしょうか。

さて、本題に戻ります。

git rebase -i にコミット2のIDを指定します。コマンドにすると次のようになります。
git rebase -i e830b49
実行すると自動的にviが起動し次のような画面になります。

この状態で1, 2行目の編集を行い、保存することでコミットの編集が可能になります。
コミットAを削除するために、1行目を削除し、保存します。

ここまで操作したら、SourceTreeでコミットツリーを確認します。

コミットAが消えました。
作業コピーを確認すると、コミットAで追加したA.txtも削除されています。

コミットの順序入れ替え

準備のコマンドを実行し、コミットを再作成します。

コミットAとコミットBを入れ替えます。
git rebase -i にコミット2のIDを指定します。
git rebase -i 2986ff9
viが起動します。

コミットAとコミットBを入れ替えます。
viでの操作としては、コミットAの行で
dd
を入力し切り取り、
コミットBの行で
p
を入力し貼り付けます。

保存し、SourceTreeのコミットツリーを確認すると、コミットAとコミットBの順序が入れ替わっています。

コミットメッセージの変更

準備

過去のコミットメッセージを変更します。
git rebase -i にコミット2のIDを指定します。
git rebase -i 11d2af2
viが起動します。

コミットAのコミットメッセージを変更するために、コミットAの「pick」を「reword」に書き換え、保存します。
rewordは「書き換え」という意味です。

保存後にviを終了すると、コミットAのコミットメッセージ変更のために再度viが開かれます。

コミットメッセージを変更し保存します。

SourceTreeで確認すると、コミットAのコミットメッセージが変更されていることが確認できました。

コミット統合

準備

コミットAとコミットBを一つにまとめます。
git rebase -i にコミット2のIDを指定します。
git rebase -i 9783485
viが起動します。

コミットBの「pick」を「squash」に変更します。
squashは押しつぶすといった意味で、この指示によりコミットBで行った変更は、一つ前のコミットであるコミットAと一つにまとまります。

保存しviを終了すると、一つにまとめるコミットメッセージを編集するために再度viが起動します。

コミットBのコミットメッセージを削除し、コミットAのコミットメッセージを変更してみました。

SourceTreeで確認すると、コミットAとコミットBが一つになったコミットが作成されています。

変更内容にはコミットAとコミットBの両方の変更内容が含まれています。

分岐元の変更

準備

いまBranchXはコミット2を分岐元としています。
これを、コミット4が分岐元となるように、分岐元のコミットを変更します。
git rebase masterを実行します。
git rebase master
SourceTreeで確認すると、BranchXの分岐元がコミット2からコミット4に変更されています。
この、「git rebase master」は、
ブランチを切ったあとにmasterブランチが更新された場合に使用されることが多いそうです。
コミットログが見やすくなりますし、マージの回数をへらすことが出来ます。

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T18:58:54+09:00

環境変数で失敗: Git pullできない(fatal: Not a git repository)

コマンドプロンプトでgit pullしようとするとfatal: Not a git repository: 'C:\Program Files\Git\bin'というエラーが出てしまい、何が何だかわからない事態に陥った。git-cmdでは動くからgit自体は問題なさそうなのに、なんでこんなことが起きるのかと思っていたら、「Gitディレクトリ外からgitコマンドを実行する」を読んでようやく理解できた。気付きにくい残念な失敗だったので残しておく。

原因: 意図せず意味のある環境変数"GIT_DIR"を定義していた

Node.jsを実行するコマンドプロンプトを開く際、PATHやPYTHONなどの環境変数を設定したかったので、以下のようなバッチファイルを作っていた。その中で、GitのバイナリへのPATHのつもりで環境変数GIT_DIRを定義していた。この環境変数は一時的な用途のつもりだったのだが、悪さをしてしまった。
setting.bat
set NPM_DIR=E:\node\9_5_0\npm_global
set NODE_DIR=E:\node\9_5_0
set GIT_DIR=C:\Program Files\Git\bin ←これが良くなかった
set PYTHON=E:\Python\2_7\python.exe
set PYTHON_DIR=E:\Python\2_7
set PATH=%NODE_DIR%;%NPM_DIR%;%GIT_DIR%;%PYTHON_DIR%;%PATH%

cd /d %~dp0
cmd /K npm config set prefix %NPM_DIR%
環境変数設定画面を開く手間、環境変数が増え過ぎ防止、複数バージョンをインストールすることなどを考慮し、起動用のプロンプトを作っていた。それがこんな悪さをするなんて…

「Gitディレクトリ外からgitコマンドを実行する」によると、GIT_DIRはgit pull などを実行する際の.gitの場所を指定するための環境変数ということだった。一時的な環境変数のつもりが、実は意味があって.gitフォルダを指定してしまったことで、「リポジトリじゃない！」と怒られてしまうのだった。(しかもこの環境変数は、-Cオプションより強いため、無効化しないといけなかった)

対処: GIT_DIRの定義を削除(改名)した

環境変数GIT_DIRさえ定義しなければよいので、以下のようにして解決…しょぼい。
setting.bat
set NPM_DIR=E:\node\9_5_0\npm_global
set NODE_DIR=E:\node\9_5_0
set GIT_PATH=C:\Program Files\Git\bin
set PYTHON=E:\Python\2_7\python.exe
set PYTHON_DIR=E:\Python\2_7
set PATH=%NODE_DIR%;%NPM_DIR%;%GIT_PATH%;%PYTHON_DIR%;%PATH%

cd /d %~dp0
cmd /K npm config set prefix %NPM_DIR%
もっと別な名前があるかもしれないが、とりあえず動いたのでこれで良し…

気を付けること

一時的な用途のつもりで作った環境変数でも、誰かにとって意味があるかもしれない。意図せず何かの設定をいじってしまい、不可解なトラブルを起こす可能性がある。環境変数を作るときは、MY_abcとかTMP_xyzのような、まず被らない名前を付けるべきだったと思う。

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T16:52:38+09:00

Git使い方メモ

はじめに

gitとGitHubを勉強して、自分なりに実際に使用してみたので、その流れをメモしておきたいと思います。

git管理の開始

GitHubの操作

リポジトリ作成
まず、GitHub上でリモートリポジトリを作成します。
GitHubのRepositories欄の「New」ボタンから作成できます。

リポジトリ名を入れれば作成できます。

git操作

既にあるファイルの管理を始める場合は、管理するファイルがあるディレクトリに移動後に、git initコマンドを実行します。
git init
次に、git remoteコマンドでリモートリポジトリを登録します。
以下のコマンドによって、originというの名前でリモートリポジトリにアクセスできます。
git remote origin "アドレス"
以下のコマンドで現在登録しているリモートリポジトリを確認できます。
git remote -v
ブランチの操作

git branchコマンドでブランチを作成できます。
git branch "ブランチ名"
以下のコマンドで、ブランチの一覧を確認できます。
-aオプションをつけることで、リモートブランチを含めて確認できます。
また、*がついているものが現在のブランチになります。
git branch
git branch -a
作成したブランチに移動するには、git checkoutコマンドを使用します。
-bオプションをつけることで、ブランチの作成しつつ移動できます。
git checkout "ブランチ名"
git checkout -b "ブランチ名"
不要なリポジトリは、git branch -dで削除できます。
git branch -d "ブランチ名"
リモートブランチの場合は、git push --deleteコマンドになります。
git push --delete origin "ブランチ名"
ファイルの管理

ここからはファイル修正後の話です。

修正したファイルをインデックスに登録します。
簡単に言うと、コミットするファイル一覧みたいなものです。
git addコマンドで登録します。
git add "ファイル名"
git statusで現在の変更を確認できます。
git status
次にファイルをローカルリポジトリにコミットします。
デフォルトだとvimでコメント入力が起動するので、iで入力モード、
入力後は、escで入力モード終了、:wqで保存して終了します。
git commit
最後に、リモートリポジトリにプッシュして反映します。
git push origin "ブランチ名"
プルリクエスト

リモートリポジトリにプッシュされた内容を別のブランチにマージする際に、プルリクエストを送ります。
GitHubのPull requests欄の「New pull request」を押します。

マージ元とマージ先のブランチを指定して、「Create pull request」を押して、必要項目を入力すると作成できます。

GitHubの内容を取得

まず、取得したいブランチに移動します。
git checkout "ブランチ名"
git pullコマンドでリモートリポジトリの内容をローカルに反映します。
git pull origin "ブランチ名"
参考URL

以下の方の記事にコマンドがまとまっていて参考にしました。
【Git】基本コマンド
 基本的なGitコマンドまとめ

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T15:28:48+09:00

個性のあるタップ時間の設定方法

過去に、コントールキーとエンターキーの組み合わせ自作関数を作ろうとしたことがあった。
しかし、複雑で挫折した。

自作する目的は、他の組み合わせは90ミリ秒程度のタップ時間で操作したいが、上記の組み合わせは60〜70ミリ秒あたりに設定したかった。
エンターキー押下だけは短い時間に設定しなければ、コントールキーを瞬間的に使えない。
そのため、TAPPING_TERMをより低い値に設定し、PERMISSIVE_HOLDを有効にするならば、問題を低減できそうに感じるが、押下速度に依存するため、受け入れ難い。
そして、個別設定ができない・・・と思っていた。

結論はget_tapping_term関数を使うことで、タッピング時間を個別に変更することが可能になる。
自作すら必要なくなる。

素晴らしい。

関数にキーコードを設定するだけ

カスタムタッピング時間を使うための準備はたいして不要だ。
既存のソースファイルに、少し追加するだけで完了するからだ。

config.h

下記を新規に追加するだけで終わる。
config.h
#define TAPPING_TERM_PER_KEY
簡単でしょ？
もちろん、#define TAPPING_TERM 90は、必要なままだ。
※時間は任意で。

keymap.c

仮に、CTL_T(KC_ENTER)の挙動をTAPPING_TERM時間に加えて、300ミリ秒を追加するとしよう。

以下のコードそのもの。
keymap.c
uint16_t get_tapping_term(uint16_t keycode) {
    switch (keycode) {
        case CTL_T(KC_ENTER):
            return TAPPING_TERM + 300; // 390ミリ秒(極端な例)
        case LGUI_T(KC_ENTER):
            return 39; // 高橋名人以上の素早さが必要(これも極端な例)
        default:
            return TAPPING_TERM; // 90ミリ秒
    }
}
上記の他に、LGUI_T(KC_ENTER)は、39ミリ秒を設定している。これは、無茶苦茶尋常ならざるほどの速度でタップしなければEnterキーが動かない時間設定になる。

キーコードの設定

当たり前だが、上記で設定したCTL_T(KC_ENTER)などを実際のキーコードとして使わなければ意味がない。
（以下、大分省略したキーマップ）
keymap.c
 * |------+------+------+------+------+------+------+------+------+------+------+------|
 * |Ctrl/Ent|      |      |      |      |      |      |      |      |      |      |      |
 * `-----------------------------------------------------------------------------------'
 */
[BASE] = LAYOUT_planck_grid(
    CTL_T(KC_ENTER),・・・,・・・,・・・　・・・
後はよしなに。

ここまでがタップ時間の設定方法だ。
以下、ソースコード最新化について。

Gitコマンド

わざわざここのページで記載する理由は、今回の件でGithubでのCloneしたソースコードを最新化できなかったため、備忘録として残すのが目的になる。

ドキュメントのUpdating your master branchを参照することで、最新化できた。

ちなみに、このdocs.qmk.fmは、githubリポジトリから生成されるため、どちらを参照しても問題ない。
同期がとれている・・・と言うより、githubから引っ張ってきているとのこと(Redditからの情報)。

get_tapping_term関数

自分のキーマッピングを確認するが、全く反映されず、にっちもさっちもいかず、かなり困った。
掲示板で助けを求めるが、サンプルコードのようにdefine値を追加するだけで使えるようになるという返事だけで終わってしまった。
しかし、リモート上のソースコードを確認したら明らかに私のローカル上のソースコードと全面的なプログラムが異なっていた。
そのため、ローカル環境を最新化する必要に迫られた。

Git

どうやらクローンした場合、クローン元で変更が行われたときもそれはクローン先に反映されないようだ。
クローンという名前をやめて、コピーの文言を使って欲しいよ。

プルで最新版を取得できると思い込んでいたのは内緒だ。

結論

以下のコマンドの打ち込みで何とか最新化にこぎつけた。

※見やすいように画像を加工済み。

現在のフォーク元を取得(add)

最新のFork元を自分のリモート先に追加する。
コマンドプロンプト
git remote add root_branch https://github.com/qmk/qmk_firmware.git
ちょっとしたコマンドなのに、理解できないほど複雑に思える。

現在の状態と比較(fetch)

先ほど取得した最新版のForkと自分のリポジトリを比較する。
コマンドプロンプト
git fetch root_branch
Tag付け

特に作業として必要ないのだが、一応の記録付けと言うことで、Tagを追加することにした。
コマンドプロンプト
git tag 'forkGet'
git tag -a 'forkGet' -m 'fork元取得(最新化)'
1行目は、Tagそのものの作成なので、一度実行すれば、二度目は不要だ。
2行目は、作業へのTag付けなので、適切なコメントとともに、実行する。

一時的な待避(Stash)

本来は、マージ作業をするだけなのだが、私の場合は作業途中のソースファイルが存在していたため、マージに失敗した。
そのため、作業中のファイルを待避させることで、マージを再開し、成功した。
コマンドプロンプト
git stash save
踏み込んで言えば、任意に名前付けを行え、その名前で出したり入れたりができるようだ(詳細は不明)。

ソースファイルの統合(マージ)

addで追加した最新版のソースファイルたちと自分のリポジトリ環境を統合する。
コマンドプロンプト
git merge root_branch/master
私の環境がmasterだったため、それに取り込んだ認識で合っているよね？
逆だったら凹むよ。

コメントを残す必要がある。

マージ後の反映(プッシュ)

プッシュコマンドで反映される。
コマンドプロンプト
git push origin master
リモート先に反映されたはずだ。

一時的な待避を戻す

上記で待避(Stash)したため、ここで戻す。
コマンドプロンプト
git stash pop
一つしか待避させていないため、この程度で事足りる。

最新化終了

ここまでで最新化が行われたはず。

注意

上記で、git remote addコマンドを使った。
そのとき、root_branchがリモート上に残ってしまったため、手動で削除した。
しかし、あかんかったわ。
それ以降の操作でエラーが出て続けてしまい、解消することができなくなってしまった。
むぅ。
今度は、この問題を解決しなければならない。
困った。

感想

今回の時間設定により、より柔軟なキーマッピングが可能になったのではないだろうか。
これで、自作関数を作る必要性から解放され、時間を有効活用できるようになった・・・つもり。
やはり、知っていなければ、車輪の再開発をしてしまい、時間の無駄をするところだった。
勉強こそが人間のあるべき姿であり、経験を重視するのは愚かであり、犬畜生にも劣る下の下の生き方だろうことがここでも実証された。
今後も勉強して、人間の立場を棄てないように頑張ろうと思う。

その前に、Gitの使い方を勉強するかな・・・やることが多い。。。
あぁ就職活動が先か・・・。

以上。

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T14:39:48+09:00

GitHub と GitLab で Git config を切り替えたい

設定方法

ディレクトリごとに読み込む設定ファイルを分岐させます。
/Users/iris/Documents/repos/
├── github.com
└── gitlab.com
github.com 以下には GitHub のリポジトリ、gitlab.com 以下には GitLab のリポジトリが配置されている状態です。

gitlab.com 以下にいる時だけ ~/.dotfiles/git/gitconfig.gitlab を読み込むようにして user.email を GitLab に登録した Email で上書きします。
.gitconfig
[user]
    name = peaceiris
    email = 30958501+peaceiris@users.noreply.github.com

[includeIf "gitdir:~/Documents/repos/gitlab.com/"]
    path = ~/.dotfiles/git/gitconfig.gitlab
~/.dotfiles/git/gitconfig.gitlab
[user]
    email = my-gitlab-email@gmail.com
includeIf について

以下を参照した。

Git - git-config Documentation

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T13:35:41+09:00

githubで共同開発招待方法

github共同開発したい時､
共同開発者を招待する方法｡

登場人物 Aさん､Bさん｡

Aさん↓

プロジェクトのディレクトリを作成し､
github画面からリポジトリ作成
githubのリポジトリの画面から､招待の操作
Settingタブ､collaborators
collaboratorsに追加したいユーザー名（githubの）を入力し､
Add Collaboratorsを押す｡
(メールアドレスでも追加できます｡)
Bさんに招待メールが届きます｡

↓
Bさん

招待メールが届くので､メールから招待をacceptする｡

※githubに登録しているメールアドレスが分からない場合は､
ターミナルで$git config --listをすると､アカウント名や登録のメールアドレスなど確認できます｡
※ちなみに2019年1月からgithubのPrivateリポジトリ（鍵付きリポジトリ）の作成は無料で出来るようになっていますが､1プロジェクトあたりのコラボレーターの数は無料だと3人までです｡

参考
https://code-schools.com/github-invite/

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T11:28:31+09:00

git submodule を削除する方法

git submodule addで追加したリポジトリを削除する方法のメモ。
間違っているかもしれません。

git submodule deinit -f <path>

.gitmodules .git/configから対応する行を削除する。

.git/modules/<path>を削除する。

<path>を削除する。

変更をコミットする。

なお、既にあるsubmoduleのURLを変更したい場合も、一度削除してから追加すればよいのではないかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2019-07-28T00:39:47+09:00

【Git】.gitignoreでファイル管理しよう

ソース管理にGitを使用しています。
基本的にはGitでバージョン管理をするわけですが、中には例外となるファイルも存在します。

今回はGitでソース管理をする上で、除外するファイルの管理方法についてまとめました。

Gitで管理すべきでないファイルとは？

自動作成されるファイル

ログファイル

パッケージファイル

バックアップファイル

ビルド後の成果物

エディタ特有のファイル

OSのファイル管理に使用されるファイル

Thumbs.db(Windows)

.DS_Store(macOS)

共有すべきでないファイル

パスワードが記載されたファイル

自動作成されるファイルをあえてGitでバージョン管理する必要はありません。
また、パスワードが記載されているファイルに関しては、セキュリティの兼ね合いからGitで管理するかをきちんと検討する必要があります。

.gitignoreを使って管理しよう

Gitで管理すべきでないファイルは.gitignoreファイルを作成し、管理しましょう。
.gitignoreとは、簡単に説明すると「Gitが無視してくれるファイル/フォルダの定義」のことです。

.gitignoreファイルは作成したディレクトリ配下のパスにのみ有効です。
ファイルを作成する際はどのパスを有効にしたいかを考えてから作成しましょう。

.gitignoreの作成方法

作成方法は簡単で、エディタで.gitignoreファイルを作成します。
作成したファイルにGitで管理したくないファイル名やフォルダ名を入力します。
.vscode/
node_modules/
dist/

*.log

Thumbs.db
.DS_Store
使用する技術やIDEやエディタを指定してgitignoreを生成してくれるサイトもあります。

gitignore.ioで検索し、.gitignoreを作成する参考にしてみるのもいいでしょう。

まとめ

Gitで管理すべきでないファイルというものは、個人で使用している場合は自分の判断で問題ありません。

ただ、業務で使用しているソース管理をGitでする場合に関しては、自分の判断だけで決めてはならない場合もあります。
そういった場合は、きちんとルールを確認し、判断することが重要です。

　 Tweet
Qiitaで続きを読む

20190728のGitに関する記事は10件です。

git rebaseのeditで過去のリビジョンを変更する

git rebae の edit の動き

リビジョンの変更の方法

新たなファイルの追加する場合

変更対象Rev.に含まれているファイルを再編集する場合

変更対象Rev.からファイルを除外する場合

rebase --continue

例

GithubへのpushでPermission denied (publickey)が出た時の対処法

１：鍵を作成する

２：ssh-agentへ登録する

3：登録の確認

４：作成した鍵をコピーする

id_rsa.pubを開く

５：githubで鍵を登録する

６：ターミナルで設定する

7:接続確認

git rebase の使い方を覚える

記事を書くきっかけ

環境

準備

git rebase

コミットの削除

コミットの順序入れ替え

コミットメッセージの変更

コミット統合

分岐元の変更

環境変数で失敗: Git pullできない(fatal: Not a git repository)

原因: 意図せず意味のある環境変数"GIT_DIR"を定義していた

対処: GIT_DIRの定義を削除(改名)した

気を付けること

Git使い方メモ

はじめに

git管理の開始

GitHubの操作

git操作

ブランチの操作

ファイルの管理

プルリクエスト

GitHubの内容を取得

参考URL

個性のあるタップ時間の設定方法

関数にキーコードを設定するだけ

config.h

keymap.c

キーコードの設定

Gitコマンド

get_tapping_term関数

Git

結論

現在のフォーク元を取得(add)

現在の状態と比較(fetch)

Tag付け

一時的な待避(Stash)

ソースファイルの統合(マージ)

マージ後の反映(プッシュ)

一時的な待避を戻す

最新化終了

注意

感想

GitHub と GitLab で Git config を切り替えたい

設定方法

includeIf について

githubで共同開発 招待方法

git submodule を削除する方法

【Git】.gitignoreでファイル管理しよう

Gitで管理すべきでないファイルとは？

.gitignoreを使って管理しよう

.gitignoreの作成方法

まとめ

日付別

タグ一覧

`includeIf` について

githubで共同開発招待方法