問題

gitの（グローバル）コミットネーム、コミットメールアドレスの設定時にタイトルのようなエラーが出て、設定できない
具体的にはコミットメールアドレスの設定時（先にやったコミットネームの設定は通った）。
は？

環境

• Windows 10 home 1903
• wsl (Ubuntu 20.04.1 LTS)
• Git 2.25.1

原因

不明
有識者の方々お願いします。

エラーメッセージにchmodとかあるのでアクセス権限周りの問題か？
not permittedって書いてもいるしね。

また、調べていくうちにローカルのconfig周りで同様の症状になっている人を見つけた。
そちらでは、*.lockなるファイルが生成されていたようだが、筆者の環境においてはそのようなファイルは確認できなかった。

対処

.configファイルをvimから編集したらいけた。

まとめ

wsl、初心者が手を出していい代物ではないな…？

pushするときにいちいちリモートのブランチ名を書くのがすごくめんどくさかったので、省略することにしました。

が、引数なしのgit pushは危険とのことです（全branchをpushしてしまうとか）
というわけで、安全なgit pushを簡単なコマンドで実行できるbashを書きました。
普段あまりshellを書かないので何かあったらお願いします。

※bashコマンドの追加方法については最下部のURLをご参照ください。

gitp.sh

#!/bin/bash
tmp=(`git branch --contains | xargs`)
current_branch=${tmp[${#tmp[@]}-1]}

if [ $current_branch = "master" ]; then
  echo "masterブランチです"
  exit 
fi
git push origin $current_branch

masterにpushはできないようにしました。
使い方は

$git branch
* dev
  master

devブランチにpushしたいとして、まずはそのgitディレクトリにきたら

$gitp

これでpushされます
うっかりmasterにpushしないように、masterだったらpushしないよう書きました。

参考：（bashコマンドの追加方法について）
https://qiita.com/CyberMergina/items/57ba95d777e8f3389a93

前回深夜テンションで書いた記事が軽くバズってしまった @tsuboyataiki です。

一つの大きな機能作成で、複数の作業が同時並行になってしまい、別ブランチの特定の作業（コミット）が必要になるタイミングがありました。

そこで社員の方からcherry-pickの使い方を教えていただいたので残しておこうと思います。

cherry-pickって？

"cherry pick"は直訳すると「（いいところだけ）つまみ食いする」みたいな意味があるそうです。

Gitの機能としては、リファレンスより以下のような記述があります。

Given one or more existing commits, apply the change each one introduces, recording a new commit for each.
訳：1つ以上の既存のコミットを前提として、それぞれが導入する変更を適用し、それぞれの新しいコミットを記録します。

要は「別のブランチ（ワークツリー）にある変更（コミット）を持ってこれるよ」という感じです。

ユースケースは？

プロダクト・システムで大きな機能を作成するとき、表示部分、管理部分、データの関連付けなどごとにブランチを分けて作業することが多いでしょう。

その時、「管理部分作成で作ったメソッド持ってきたい」とか「別ブランチで定義した配列が必要になった」みたいなことがよく起きます。

そのような際にcherry-pickを使うことで、コミットログの整合性を取りながら特定の変更を持ってくることが出来ます。

使い方

コマンドの基本は以下の感じです。

$ git cherry-pick コミットのハッシュ値

実際に使用する際は、以下のように$ git logなどで確認してから使うのが一般的かと思います。

使用例

$ git log
commit 645b44d687dea267b8b15657fb91fd7bc88f8bca (HEAD -> tsuboya-20200608, origin/tsuboya-20200608)
Author: TsuboyaTaiki <tsuboyataiki@taiki-mac.local>
Date:   Mon Jun 8 17:13:50 2020 +0900

    パスワードのバリデーション修正

　（　.. 省 略 ..　）

$ git switch tsuboya-20200607
$ git cherry-pick 645b44d687dea267b8b15657fb91fd7bc88f8bca
[tsuboya-20200607 d719a90] パスワードのバリデーション修正
 Author: TsuboyaTaiki <tsuboyataiki@taiki-mac.local>
 Date: Mon Jun 8 17:13:50 2020 +0900
 1 file changed, 1 insertion(+), 1 deletion(-)

↑で、別ブランチでのコミットを持ってこれました。

ここで$ git logで変更が反映されているか確認すると...

$ git log
commit d719a90b3667b1e866ea3938f1ca400782e2d133 (HEAD -> tsuboya-20200607)
Author: TsuboyaTaiki <tsuboyataiki@taiki-mac.local>
Date:   Mon Jun 8 17:13:50 2020 +0900

    パスワードのバリデーション修正

うまく行っていれば、このようにコミットログで確認できます。

コンフリクトが起きた場合

上記で紹介した例はあくまでコンフリクト（各ブランチの変更内容の競合）が起きてない場合に過ぎません。

ただ実際のところ体感半分くらいの確率でコンフリクトは起きるのでその場合の対処も紹介します。

実際にコンフリクトを起こした例

$ git cherry-pick a37ed09019cc569c5d95e253d5f39729f7e2b2b5
Auto-merging app/models/account.rb
CONFLICT (content): Merge conflict in app/models/account.rb
error: could not apply a37ed09... change coment BBB
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
$

実際にコンフリクトが起きると、このようにコンフリクトが起きている箇所や、該当する編集内容が表示されます。また、先ほどうまく行った場合と違ってこの時点ではコミットはまだ反映されていません。

では、エディタで該当箇所を見てみると...

Current ChangeとIncoming Changeという形で分かれている状態になっていますね。

Current Changeを反映したい場合は、下の画像の赤丸の「Accept Current Change」を選択し、Incoming Changeの場合は青丸の方を選択すると、選択した方が反映されます（僕の場合はVSCodeで操作しています）。

あとは忘れずに$ git addと$ git commitをして終了です。

もしcherry-pickの操作をなかったことにしたい場合は、以下のようにHEADとステージングをリセットすれば大丈夫です（まだコミットしてない変更内容も消えてしまうので注意）。

$ git reset HEAD
$ git restore .     # コンフリクトが起きたファイルだけでもOK

※このやり方は僕が試しただけなのでもっと適したやり方があれば教えていただけると幸いです。

ちょこちょこつまづいたので、どう解決したか順を追って書いておきます。

HomebrewでGoをインストール

$ brew install go

インストールされた場所を確認する

?  /usr/local/Cellar/go/1.15: 9,769 files, 494.3MB

Homebrewだと/usr/local/Cellar/直下に入っていきます

versionを確認する

$ go version
go version go1.15 darwin/amd64

適当なディリクトリにファイルを作成

$ mkdir -p ~/go/src/practice

Hello woldしてみる

practiceディリクトリにhello.go を作成する
参考 Golang公式:Test your installation

hello.go

package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}

buildしてみる

hello.go:3:8: cannot find package "fmt" in any of:
    /Users/miztakahashi/go/src/fmt (from $GOROOT)
    ($GOPATH not set. For more details see: 'go help gopath')
package hello: cannot find package "runtime" in any of:
    /Users/miztakahashi/go/src/runtime (from $GOROOT)
    ($GOPATH not set. For more details see: 'go help gopath')

cannot find packageのエラー・・・
$PATH が通っていないのかな？

いろいろ調べました。

go envで環境変数一覧を確認すると理由がわかるようです。

Mizukimbp:hello miztakahashi$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/miztakahashi/Library/Caches/go-build"
GOENV="/Users/miztakahashi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH=""
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/miztakahashi/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/miztakahashi/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
.
.
.

通常homebrewでインストールすると、

? /usr/local/Cellar/go/1.15: 9,769 files, 494.3MB

/usr/local/Cellar/の直下に入るようなので、
以下のpathを正しい場所に書き換えてやる必要がありそうです。

GOPATH=""
GOROOT="/Users/miztakahashi/go"
GOTOOLDIR="/Users/miztakahashi/go/pkg/tool/darwin_amd64"

/usr/local/Cellar/直下にgoが入るように環境変数を修正していきます。

$ echo 'export GOPATH=$HOME/go' >> ~/.bash_profile
$ echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.bash_profile 
$ echo 'export GOROOT=/usr/local/Cellar/go/1.15/libexec' >> ~/.bash_profile
$ echo 'export GOTOOLDIR=/usr/local/Cellar/go/1.15/libexec/pkg/tool/darwin_amd64' >> ~/.bash_profile

$ source ~/.bash_profile // これをやらないと反映されない

反映されているか$ go envで確認

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/miztakahashi/Library/Caches/go-build"
GOENV="/Users/miztakahashi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/miztakahashi/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/miztakahashi/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"

GOPATH
GOROOT
GOTOOLDIR　のパスが、

/usr/local/Cellar/直下にgoが来ている形になってればOK！

正しくパスを通せたので、もう一度buildしてみる

$ cd ~/go/src/practice
$ go build 

問題なくbuildできました。特に何も結果は返ってきません
正しくbuildできているかファイル(バイナリファイル)を実行してテストしてみます

$ ./hello
hello, world

大丈夫そうです。

次はA Tour of Goをローカルで起動させてみる

A Tour of Goはローカルで起動できるらしいのでやってみることにしました。
https://tour.golang.org/welcome/3

go get golang.org/x/tour

Permission deniedで git cloneできない問題

# cd .; git clone -- https://go.googlesource.com/tour /Users/miztakahashi/go/src/golang.org/x/tour
fatal: could not create work tree dir '/Users/miztakahashi/go/src/golang.org/x/tour': Permission denied
package golang.org/x/tour: exit status 128

どうやらgo get golang.org/x/tourは
git clone https://github.com/golang/tour と同じのようです。(こちらも同じエラーが返ってきました。)

そもそもsshは通っているか確認

Mizukimbp:~ miztakahashi$ ssh -T git@github.com
Hi AnnieMizukiTakahashi! You've successfully authenticated, but GitHub does not provide shell access.

通っているようでした。

sudoをつけて実行するとうまくいきました。

sudo git clone https://github.com/golang/tour
sudo go build
sudo cp tour $GOPATH/bin
tour //これでローカルのブラウザが開きます

ブランチ運用のナレッジが溜まってきたので、まとめてシェアします。
現場ごとにいろいろ考え方があると思うのですが、自分がやっていて合理的だと感じている活用を書きます。

チーム開発でのPR　WIPブランチの活用

大体の開発はタスクの中に子タスクがあることがほとんどなので、コードレビューをしてもらう際はタスクを切り分けてPR(プルリクエスト)を出していくとよい

たとえばこんなタスクを開発する時、

あるステータスのユーザーにはアイコンに青いバッジをつける　(wip)

子タスク1　プロフィールのアイコンにバッジをつける (子1)

子タスク2 　Cardのアイコンにバッジをつける (子2)

子タスク3　アイコンの名称の翻訳を17か国語で入れる (子3)

WIP branchを使おう

WIPブランチは細かいタスクをまとめた親ブランチのような、空っぽのフォルダのような存在。WIPとはwork in progress。

リリースブランチに直接PRを出していくより、リリースブランチと差分のないwip ブランチのような空のブランチにPRを出す方がレビューの時、自分の開発した差分だけを相手に見せやすくなる。

WIP branchを作るメリット

• タスクを小分けにすることでdiff(差分)が見やすいのでレビュワーにミスに気付いてもらいやすい
• 小さいタスクごとに開発するので進捗が可視化されやすい
• 開発に着手し始めたことがチームに伝わりやすい(最初のcommitまで時間がかかる時、PR が作成されるのに時間がかかってしまい、いつ開発が始まったかわからない)
• 複数の開発者で子タスクの分担がしやすい

wip branch(空っぽ)に

• change_requirement_project_button
• add_multiple_notification
• change_layout
• add_translation
• fix_template

のような子タスクbranchを切ってPRを出していく

一つずつ開発してLGTMをもらったら空っぽのwip branchにどんどん入れていく。

wip branchの向き先はreleaseのためのブランチになる

WIP を使った開発でのbranchの向き先の例

master ← release_branch ← wip/add_something ← add_something_1　add_something_2

なぜメリットが大きいのか　→ PRに自分が開発した場所のdiff(差分)だけがはっきり出るから

wipに向けて複数の子ブランチへPRを出していくと、release_branchに直でPRを出すよりも良い

• 他の誰かが先にrelease_branch にコードをmergeしてもwipとその子ブランチに無駄なdiff(差分)が生まれない。
• wipに紐づいたタスクが2つある場合、add_something_1 とadd_something_2を2人の開発者で分担する時、それぞれの開発の変更が干渉し合わないので、diff(差分)がみやすくなる

空コミットの方法

普通、コードに何も変更のない場合commitはできず、リモートへpushできない。

ただし、これを使うと空commitができ、リモートへpushすることができる

git commit --allow-empty -m "wip commit" 

子branchの開発が終わり、LGTMもらったら？

wipにmergeして子branchは消しておく。気づくとリポジトリ内にめっちゃ溜まってる...

github チーム開発における基本のワークフローをざっくりまとめる

まず開発を始める時にローカルでwip(例:wip/something)と子ブランチ(例:new_cool_feature_branch)作成

git checkout release/0.0.1 //新しいreleaseブランチなどコードが最新のブランチに移動
git checkout -b wip/something　// releaseブランチからwipブランチをcheckout
git checkout wip/something　// wipに移動(このコマンドを打たなくても多分もう移動している)
git commit --allow-empty -m "wip commit" // 先述のように、空のコミットをします
git push origin wip/something　// wipをリモートにpushしてgithub上でcreate pull requestします

// 子ブランチを作る
git pull origin wip/something // wip ブランチを最新にします
git checkout -b new_cool_feature_branch // 子ブランチをcheckoutします

これで子ブランチにて開発を進めます

開発中のコミット

git commit -m "Add layout"　// add とか　fix とか　remove とかわかりやすいメッセージにする
git commit -m "Add logic"
git commit -m "..."

子ブランチをPRする時

git checkout wip/something // **一旦wipに移動します**
git pull origin wip/something　// PR前に必ずwipが最新にする！(余分な差分を生まないため)
git checkout new_cool_feature_branch　// wip ブランチから　new_cool_feature_branch(子ブランチ)へ移動
git merge wip/something　//  他の人が別の開発をmargeしたためwipが最新ではなかったので、wip/somethingの内容をnew_cool_feature_branchに**merge**
[ここでコンフリクト出たら修正]
git push origin new_cool_feature_branch　// 子ブランチをリモートへpush

ポイントは、PR前に一旦必ずwipの方を最新にすること。

そしてそれを子ブランチにmargeしておくこと。

wipの最新の内容を子branch (new_cool_feature_branch)にmargeせずをpushするとコンフリクトになることがある。

gitでのコンフリクトによるミスを防ぐために意識すること

• 1, merge時は必ずリモートの変更を優先する気持ちでいる(他の誰かのコードを消してしまうとかなり大変)
• 2, ローカルエディターで両方の変更を取り込む選んで、気をつけて手動で直す

• 

• 3, github上でコンフリクトを解消しない(直したコードが動くかどうか確認ができないまま,mergeすることになるから)

例

子 branchを[wip]branchにmergeしたい時、コンフリクトが起こった場合、

1. エディタでまずは両方の変更を取り込む
2. 必要ないコードを確認しながら編集する (スーパーウルトラダブルチェック)
3. その状態で自分の開発環境でbuildしてエラーが起こらないかチェックする。
4. 解決したコードを子 branch にpush
5. [wip]branch にmerge

ポイントはコンフリクト解消後は自分の開発環境でbuildしてエラーが起こらないかチェックすること

これで、コンフリクトの解消に万が一ミスったとしても、エラーに気付けることが多い

テストしたい時のコンフリクト

integration環境で自分が開発したところをテストしたい! しかし、

integrationブランチ(test環境)に自分の開発をpushしようとするとコンフリクトが発生するとき

いつものようにこのプロセスでintegrationに今回のリリース用の開発をデプロイしようとしたらコンフリクト発生

1. // ローカルのintegrationとrelease/branchを最新にする
2. git checkout integration　//integrationブランチへ移動
3. git merge release/branch // integrationブランチに今回のリリースブランチの内容をmergeする
// [コンフリクト発生?]
4. git push origin integration

integrationブランチにこれからreleaseする内容をdeployしようとしてたくさんコンフリクトが発生する場合、それを直すより integrationブランチを作り直した方が早いかもしれない。

→ 誰がどんな変更をintegrationに加えたか全ては追いきれないため。

git branch -D integration　//今あるローカルのintegration branchを一旦**-D**で消します
git checkout release/0.0.1　// 今の最新のbranchに移動
git checkout -b integration　// 新しくintegration　branchを作り直します
git commit --allow-empty -m "deploy commit" // リモートに空コミットをします
// [他の人のwipブランチがあればマージする] //　テストしたい開発をこのタイミングでマージします
git push -f origin integration　// -fつけてリモートにpushします

しかし毎回作り直しを行うと、他の人がテストしている場合、適用されていたものを消してしまう。他の人がテストをしていない時にコンフリクトした場合だけ、integrationブランチを新しく作成するとよい。作り直していいかチームに確認を取ること。

大事なこと

レビューしてくれる人に差分をわかりやすく伝える気遣いが大事

wipを使うとわかりやすくタスクを細分化すると進捗が整理されやすい

デプロイするときコンフリクト起こると焦るけど、落ち着いてダブルチェック。慣れないうちはgithub上でのコンフリクト解消機能は使わず、ローカルでちゃんと動作するか確認してからデプロイする

動作環境

• macOS Catalina version 10.15.5
• git version 2.28.0

前提

GitHubへのユーザ登録が済んでいること

手順

00. Git確認

$ git --version

git config --system -l システム設定
git config --global -l グローバル設定
git config --local -l ローカル設定 ← 今回はここを設定します

→ Mac Gitの初期設定からGitHub SSH接続までの手順

01. Gitサブアカウント設定

$ cd サブアカウントを設定するリポジトリ
$ git init 
$ git config --local user.name "ユーザ名"
$ git config --local user.email "メールアドレス"

ここで設定するメールアドレスは他の人にも見えるため、私はGitHubのEmail settingsの「Keep my email addresses private」にチェックを入れ、「xxxxxxxxxx+GitHub@users.noreply.github.com」形式のメールアドレスを使用しています。

local設定を確認します。
設定が反映されていることを確認してください。

$ git config --local -l

*local設定ファイルの場所は サブアカウントリポジトリ内の.git/config、global設定ファイルの場所は ~/.gitconfigです。

02. .sshファイルの設定

configファイルを開きます。ない場合は作成してください。

$ touch ~/.ssh/config
$ vi ~/.ssh/config

configにサブアカウントの内容を追加します。

Host github_sub
    HostName github.com
    Identityfile ~/.ssh/github_sub
    Port 22
    User git
    TCPKeepAlive yes
    IdentitiesOnly yes

03. SSH key作成

SSH keyを登録していないと接続時にpermissionエラーがでるため、SSH keyを作成します。

$ ssh-keygen -t ed25519 -N パスフレーズ -f ~/.ssh/github_sub -C "メールアドレス"

ここで設定するメールアドレスは、GitHubに登録したメールアドレスにします。
作成した鍵をコピーします。

$ cat ~/.ssh/github_sub.pub

04. SSH keyをGitHubに登録

SSH keyをGitHubに登録するために、GitHubのSSH and GPG keysを開きます。
SSH keysの[New SSH key]からSSH keyを登録します。

「Title」は識別しやすいものにします。
「key」にコピーした鍵を貼り付け、「Add SSH key」で登録を完了します。

05. SSH接続確認

SSH接続を確認します。

$ ssh -T github_sub.com
Enter passphrase for key '/Users/xxx/.ssh/github_sub': 設定したパスフレーズを入力

Hi xxx!You've successfully authenticated …

上記のようにYou've successfullyと表示されたら接続成功です。

06. サブアカウントのリポジトリURL設定

リポジトリURLをサブアカウント用に設定したホスト名に置き換える必要があります。

$ git remote add origin git@github.com:xxx/xxx.git

この通常のgithub.comを部分を、サブアカウント用に設定したホスト名に書き換えます。

$ git remote add origin git@github_sub:xxx/xxx.git

これで設定は終わりです。

pushして確認してください。
お疲れ様でした！

*

globalを設定せずに、複数のアカウントをlocalで設定する方法もあります。

動作環境

• macOS Catalina version 10.15.5
• git version 2.28.0

前提

GitHubへのユーザ登録が済んでいること

手順

00. Git確認

$ git --version

git config --system -l システム設定
git config --global -l グローバル設定
git config --local -l ローカル設定 ← 今回はここを設定します

→ Mac Gitの初期設定からGitHub SSH接続までの手順

01. Gitサブアカウント設定

$ cd サブアカウントを設定するリポジトリ
$ git init 
$ git config --local user.name "ユーザ名"
$ git config --local user.email "メールアドレス"

ここで設定するメールアドレスは他の人にも見えるため、私はGitHubのEmail settingsの「Keep my email addresses private」にチェックを入れ、「xxxxxxxxxx+GitHub@users.noreply.github.com」形式のメールアドレスを使用しています。

local設定を確認します。
設定が反映されていることを確認してください。

$ git config --local -l

*local設定ファイルの場所は サブアカウントリポジトリ内の.git/config、global設定ファイルの場所は ~/.gitconfigです。

02. .sshファイルの設定

configファイルを開きます。ない場合は作成してください。

$ touch ~/.ssh/config
$ vi ~/.ssh/config

configにサブアカウントの内容を追加します。

Host github_sub
    HostName github.com
    Identityfile ~/.ssh/github_sub
    Port 22
    User git
    TCPKeepAlive yes
    IdentitiesOnly yes

03. SSH key作成

SSH keyを登録していないと接続時にpermissionエラーがでるため、SSH keyを作成します。

$ ssh-keygen -t ed25519 -N パスフレーズ -f ~/.ssh/github_sub -C "メールアドレス"

ここで設定するメールアドレスは、GitHubに登録したメールアドレスにします。
作成した鍵をコピーします。

$ cat ~/.ssh/github_sub.pub

04. SSH keyをGitHubに登録

SSH keyをGitHubに登録するために、GitHubのSSH and GPG keysを開きます。
SSH keysの[New SSH key]からSSH keyを登録します。

「Title」は識別しやすいものにします。
「key」にコピーした鍵を貼り付け、「Add SSH key」で登録を完了します。

05. SSH接続確認

SSH接続を確認します。

$ ssh -T github_sub.com
Enter passphrase for key '/Users/xxx/.ssh/github_sub': 設定したパスフレーズを入力

Hi xxx!You've successfully authenticated …

上記のようにYou've successfullyと表示されたら接続成功です。

067. サブアカウントのリポジトリURL設定

リポジトリURLをサブアカウント用に設定したホスト名に置き換えます。

$ git remote add origin git@github.com:xxx/xxx.git

通常のgithub.comを部分を、サブアカウント用に設定したホスト名に書き換えます。

$ git remote add origin git@github_sub:xxx/xxx.git

これで設定は終わりです。

pushして確認してください。

*

globalを設定せずに、複数のアカウントをlocalで設定する方法もあります。

こんにちは、rickyです。
今回はgitについてはまったので情報をまとめてみました。

問題点

今回はgit repositoryをロカール環境に作ってbranchを切ろうとしたら詰まったので対処法と原因の追究を行います。
まず、ことの起こりは
github上でリポジトリの作成を行いました。
その後sshでローカル環境にcloneし、そのリポジトリの階層に移動しました。
そしてgit branchを行ったところfatal: Not a valid object name: ''.
この翻訳は有効なオブジェクト名ではありません。という意味でした。
これはgitにマスターが作成されていないとブランチを切ることができないことに起因しているようです。

解決策

そのため適当なファイルなどをプッシュしてやればブランチが切ることができるようになります。

結論

ブランチは 1)『新しい機能を追加したり、バグを修正したりするときは、どんなに大きくても小さくても、変更をカプセル化するために新しいブランチを生成します。』と記載されているようにあくまで修正や変更のための機能のため、何もpushされていない状態では使えなかったと推察されます。

参考記事

1)https://www.atlassian.com/git/tutorials/using-branchesより抜粋

gitで環境別のコンフィグを管理するベストプラクティス

やりたいこと

• 接続系のコンフィグファイルを、ローカルで変更する（例えば"DB:localhost"とか）
• 当然commitには含めたくない
• だけどpullもされたくない
• でも、git管理はしたい（できればリモートには雛形かprodの状態で）

背景

• gitignoreすると、管理そのものがされなくなるので困る
• いちいちcommit/pullのときstashするのはめんどくさすぎるし、忘れた人がローカルをリモートにあげがち
• なぜトーパルズは「gitignorelocal」を用意しなかったのか！

という問題に何度か遭遇して考えて自分の結論を出したので残しておく
（あとググってもそういう記事があんまりなかった）

答え

• 本来あるべき場所、正規パスのコンフィグファイルはgitignoreする
• このignoreはcommitに含めて各開発者が同様になるようにする
• config置き場を作り、そこにdev/stg/prodのファイルをおく
• デプロイの瞬間に対応するコンフィグを正規の場所に配置するようにする
• ローカル設定ファイルはそのまま自分の環境で正規のパスに置いておく

後書き

• もっといいやり方知っている人は教えてください
• 後からプロジェクトに参画したときはすでに開発者のコンフィグがcommitされている場合しかなかった
• トーパルズはいつも正しい。

はじめに

こんにちは。突然ですが皆さんはこのような経験がありませんか？

"コミットメッセージをしっかり決めずにpushしちゃった！"
"コミットメッセージにissue番号つけ忘れた！"
"コミットメッセージにadd/modifyの文字をつけ忘れた！"

誰しもとは言いませんが、pushしたコミットメッセージを編集したい時はありますよね、、、
自分は何回かあったので記事にしようとと。

①　まずはgit log --onlineにて修正したコミットを確認

$ git log --online

faaa223 [add]投稿詳細ページの作成 #39    //一番新しいコミット
b79cf0e [modify]投稿一覧ページ修正 #38
640522e [modify]新規投稿ページ修正 　　　//修正したいコミット //issue番号をつけ忘れた！

今回は例として3番目のコミットを修正していきます。

②　git rebase -iにて内容を修正

ここで登場するのがgit rebase -iコマンド
一番最新のコミットが1として今回変更したいコミットは3個前なので3。"HEAD~"の前に3を入れます。

$ git rebase -i HEAD~3

そうするとviエディタが起動します。

③　viエディタにて編集

先程のコマンドを打つとこのような画面が出てきます。しかしこのままでは文字が打てないので
i を打ちINSERTモードにします。(画面下部にINSERTと表示されます)

pick faaa223 [add]投稿詳細ページの作成 #39    
pick b79cf0e [modify]投稿一覧ページ修正 #38
pick 640522e [modify]新規投稿ページ修正

# Rebase 86abff0..33d7b8d onto 86abff0 (2 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
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# 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.
#
#
# Note that empty commits are commented out

--INSERT-- 　　//iを打って編集モードになると表示される。

変更したいコミットのpickをeに変更

pick faaa223 [add]投稿詳細ページの作成 #39    
pick b79cf0e [modify]投稿一覧ページ修正 #38
e 640522e [modify]新規投稿ページ修正         //pickをeに変更

# Rebase 86abff0..33d7b8d onto 86abff0 (2 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
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# 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.
#
#
# Note that empty commits are commented out

--INSERT-- 　　//iを打って編集モードになると表示される。

eに変更したらESCキーを押してコマンドモードに切り替えます。（コマンドモードに切り替えるとINSERTが消えます)

:wqを押して上書き保存して終了。

④　git commit --amend にてコミットメッセージを変更

$ git commit --amend -m "[modify]新規投稿ページ修正 #37"  　　//issue番号を追加

これでコミットメッセージの変更が完了になります。

⑤　git rebase --continue

$ git rebase --continue 

もし他にeに変更したコミットがある場合は順次移動します

⑥　git log --onelineにて確認

$ git log --oneline

faaa223 [add]投稿詳細ページの作成 #39    
b79cf0e [modify]投稿一覧ページ修正 #38
640522e [modify]新規投稿ページ修正 #37　　　//修正完了

⑦　git push -f origin ブランチ名　にて強制push

$ git push -f origin ブランチ名

-fにて強制pushしてリモート上でメッセージ変更完了

強制pushを行うときは、想定外のことが起こる可能性もあるので注意！（チーム開発をしていたり。）

初めに

タイトルの通りです。
Windows環境上でコミット時、タグやコミット時にサインすることで本人が行った動作と証明します。

想定している人

• ラクに✔マークをつけたい人
• ほかのページだと断片化しすぎててわかんなかった人

Verifiedとは

GitHubのcommitなりtagなりについてるこんな感じのやつです。

このマークがついているとああいった署名をつけることができるのは本人のみなので、
結果としてその本人がやったことが確実とのこと。
また、GitHubでも署名を行ったコミットが上がってきたときに、本当に自分のかをチェックする機構があり、
それに通ればVerifiedマークがつく、といった流れです。
Gitの公式サイトを見る限りには「ぜひやってくれ」的な体制らしいです。

やり方

前提環境

• Git for Windows 2020/08/23時点でのStable Buildは2.28.0だそうです
• GnuPG 署名確認: Git組み込みのものもあります。今回はこちらで。
• GitHubのアカウント: それはそう

使用する個人名とメールアドレスの確認

GitHubでは、メールアドレスを晒すのは…という人向けに、GitHub側でメールアドレスを隠してくれる機構(EmailのKeep my email addresses private)があります。
もしその機構を利用しているのであれば、そのメールを、利用していないのであればGitHubのPrimary email addressを利用して下さい。

鍵の作成

対話型で作成可能な方法もあります。今回は省略します。

• gpg --quick-gen-key "名前 <メルアド>" future-default - 0で、最も短い形で鍵の作成が可能です。パスフレーズはダイアログとして出てくるので、そちらにコミットする際のパスフレーズを指定してください。
  これで作成完了すると下の様に出力されたはずです。 この例でいうEB13FBB100DB367482FE6826A5F9ED5C4F044D21をこの後使用します。　　

C:\Users\kazu0617>gpg --quick-gen-key "kazu0617 <kazu0617@**********.com>" future-default - 0
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。
gpg: 鍵A5F9ED5C4F044D21を究極的に信用するよう記録しました
gpg: 失効証明書を 'C:/Users/kazu0617/AppData/Roaming/gnupg/openpgp-revocs.d\EB13FBB100DB367482FE6826A5F9ED5C4F044D21.rev' に保管しました。
公開鍵と秘密鍵を作成し、署名しました。

pub   ed25519 2020-08-22 [SC]
      EB13FBB100DB367482FE6826A5F9ED5C4F044D21
uid                      kazu0617 <kazu0617@**********.com>
sub   cv25519 2020-08-22 [E]

• GitHubに使用する鍵を伝えるため、公開鍵を出力します。
  

C:\Users\kazu0617>gpg --armor --export EB13FBB100DB367482FE6826A5F9ED5C4F044D21
-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEX0Fr0BYJKwYBBAHaRw8BAQdAKaJSb/8su93/TeaOqUm4IU71wAQp2pSuvap/
OqmBbTq0ImthenUwNjE3IDxrYXp1MDYxN0Bwcm90b25tYWlsLmNvbT6IkAQTFggA
OBYhBOsT+7EA2zZ0gv5oJqX57VxPBE0hBQJfQWvQAhsDBQsJCAcCBhUKCQgLAgQW
AgMBAh4BAheAAAoJEKX57VxPBE0hbJkA/2BBxW/YlkHvn13GhEpIZTRXL3dw3oTP
zKOt9xgWuiwwAP9adwB+lHPEfGJXpETl09P2Nuwn4e6oRMZOL+vZOoY/C7g4BF9B
a9ASCisGAQQBl1UBBQEBB0AoHDxYTEJAW0lViP6tYkUjdIJI/j5Tl8qdAvrD3aRE
dwMBCAeIeAQYFggAIBYhBOsT+7EA2zZ0gv5oJqX57VxPBE0hBQJfQWvQAhsMAAoJ
EKX57VxPBE0hm/IA/3RO+iNvvXrleq1l8qhg/QnV5DnqjdXTrN/CMRl9OyDaAQCy
UDcITSqFmZSxb5ivd9+BQcrZovyqpx67t7601mDYCA==
=gT34
-----END PGP PUBLIC KEY BLOCK-----

ここまで来たらこの後これら公開鍵情報を使用するため、ここの内容を全てコピーしてください。

GitHub上での設定

1. GitHubから、SSH and GPG Keysにアクセス。ここでSSHやPGPの鍵を確認します。

2. New GPG Keyをクリック。出てきた枠に先ほどコピーした内容を貼り付けて、Add GPG Keysで登録します。
   

3. 画面が遷移し、鍵が追加されたことが確認できるはずです。ここのDeleteをクリックすれば鍵を削除可能です（今回の鍵は無期限指定のため、何か問題がない限りはずっと使用し続けることができます）。
   

P.S. CUI上で行う方法もあるみたいです。何度もやってて面倒だという方はどうぞ。
https://qiita.com/yusuke_konishi/items/6fa51372a895c831ab2b

git側の設定

gitに登録する際にkeyidを指定しなければいけないため、それをgpg --list-secret-keys --keyid-format LONGから確認します。

今回の例であればsecである2651E81CE5ACB365が今回使用する秘密鍵となります

(ssbであるA5F9ED5C4F044D21も利用できますし、そういったポストもありますが、現実でいうマスターキーで常に施錠する形なので、基本的には署名には使用せず鍵の更新とかだけに使用するのが望ましいと言われています)。

C:\Users\kazu0617>gpg --list-secret-keys --keyid-format LONG
sec   ed25519/A5F9ED5C4F044D21 2020-08-22 [SC]
      EB13FBB100DB367482FE6826A5F9ED5C4F044D21
uid                 [  究極  ] kazu0617 <kazu0617@**********.com>
ssb   cv25519/2651E81CE5ACB365 2020-08-22 [E]

次の通りに実際に情報をgit側に反映させます。

gpg.programやcommit.gpgsignはもしかするとインストール時に入っているかもしれません。その場合は改めて追加する必要はありません。user.nameやuser.emailを既に指定している場合はuser.signingkeyだけで十分です。

(よくわからない場合はgit config --global --editやgit config --editから現在情報を確認可能)

git config --global add gpg.program "c:/Program Files (x86)/GnuPG/bin/gpg.exe"
git config --global add commit.gpgsign true
git config --global add user.name kazu0617
git config --global add user.email kazu0617@**********.com
git config --global add user.signingkey 2651E81CE5ACB365

一応それぞれについて補足
- gpg.program ... gpgのプログラムを指定してます
- commit.gpgsign ... コミットに対しgpgを標準でサインする
- user.name ... 自分の名前
- user.email ... 今回使用したメールアドレス(GitHubで使えるもの)
- user.signingkey ... KeyID.上の例だと2651E81CE5ACB365

他サービスと共存する場合は、user.emailとuser.signingkeyはローカルに保存することでリポジトリごとにキーを変更できるため、GitLabとの共存も可能のためお勧めです。

コミットの仕方

先ほどcommit.gpgsignを適用したため、通常と同じやり方でコミットしてもらえればコミットされます。変更点といえばコミットする際に鍵を使用するため、その際のパスフレーズが求められるぐらいです。

gpgsignを適用しない場合

公式サイトの記述から、おおよそ次のような感じです。

• コミットをする際には-Sをつける
• タグをつける際には-sを使う

そのため、例えばコミットの場合であればgit commit -S ...といった形で引数を付与してあげることで任意のコミットに引数を付与することができます。

参考

• What do 'ssb' and 'sec' mean in gpg's output?
• Telling Git about your signing key
• GnuPG チートシート（鍵作成から失効まで）
• そろそろ GnuPG でも ECC を標準で使うのがいいんじゃないかな

最後に

失効させる場合や鍵の更新などについては機会があれば投稿します。また、何か問題点や質問があればコメントやTwitter等に直接どうぞ。

はじめに

gitとはプログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのことです。

記事を書こうと思った経緯

開発中にgithubを使用しており、コマンドが多く覚えるために記録用として。

gitコマンド集

初期設定

git config --global user.name "XXXX"
git config --global user.email "XXXX@hogehoge.com"

リポジトリを新規に作成

git init

initコマンドを実行すると、現在のディレクトリまたは指定したディレクトリに「. git」というリポジトリを構成するディレクトリが作成されます。

変更のあったファイルをステージングします

git add (ファイル名)  /*特定ファイル*/
git add .          /*全て*/ 
git add -A         /*全て*/

ステージングされた変更をコミット(確定)します

git commit -m "コミットメッセージ"

前回のコミットと統合する

git commit --amend -m "コミットメッセージ"

commitした内容をローカルからリモートにpush

git push origin ブランチ名
git push origin　HEAD　現在のブランチでpush

強制push

git push -f origin ブランチ名

過去のコミットを変更した際等に使用。チーム開発等を行なっている際は、チーム開発者の編集がなかったことになる恐れもあるため細心の注意が必要。

リモートからローカルに反映

git pull origin ブランチ名

github等でマージした際にローカルでは反映されていないため、このコマンドが必要。

ログ確認

git log

現在の変更ファイル確認

git status

ファイル編集をした際に確認。削除したファイルや追加したファイルが表示される。

現在の変更コード確認

git diff

コードを編集した際に確認。削除コード追加コードが表示される。

git add取り消し

git reset HEAD
git reset HEAD　(ファイル名)  /*特定ファイル*/

直前に戻る

git reset --hard HEAD

指定したlogに戻る

git reset --hard コミットid

コミットIDはgit logにて確認できる。

一旦コミットを退避させる

git stash

現在のブランチでコード編集している途中で、別ブランチにてコードを編集を行いたい時に使用。

退避した作業をみる

git stash list

退避した作業を戻す

git stash apply <stash名>

退避した作業を消す

git stash drop <stash名>

退避した作業を全て消す

git stash clear

リポジトリ内の最適化

git gc

リポジトリが使用するストレージを最適化。頻繁に使う必要はないが、大量マージした際に行うとよし。

ブランチの切り替え

git checkout <ブランチ名>

新規ブランチ作成

git checkout -b <ブランチ名>

おすすめ拡張機能8選
の記事をみて、jupyterlab-gitを使おうとして、詰まったのでメモ

環境

• JupterLab v 2.1.5
• anaconda

jupyterlab-gitをインストールする

READMEから以下のコマンドを打つ(conda環境なのでcondaでインストールしました。)

$conda install jupyterlab-git #pipの方は、pip install --upgrade jupyterlab-git
#インストール完了
$jupyter lab build
#エラー

JupyterLabの拡張機能画面から、gitと打って@jupyterlab/gitからインストールできますが、多分nodejsが入っていないと同じエラーが出ると予想されます。

エラー発生

詳しいエラーを出力してくれました。
結論から言うとnodejsのバージョンを上げろってことらしい。
読みたい方はエラー内容を最後に貼りましたので参照してください。

やること

最後の最後に答えがありました。
?ValueError: Please install nodejs >=10.0.0 before continuing.

``コマンドでnodejsのバージョンを確認。

$ conda list

#結果
nodejs | 6.13.1 0 |conda-forge

無事バージョンが10.0以下で低かったのでバージョンを上げる作業をしたいと思います。

nodejsをインストールしていない人

まずnodejsをインストールしていない人はこのコマンドを叩いてインストールしてください！

$conda install -c conda-forge nodejs

※インストールしてバージョンが10以下だったら下のコマンドを打ってください。

nodejsのバージョンを上げる

私はconda環境を使っているのでcondaコマンドを用います。pipでもいけると思います。

$conda update nodejs

nodejs-10.13.0

バージョンアップが完了したら最後にjupyter-gitをビルド、

もう一度jupyter lab build

jupyter lab buildが終わったら、jupyter labを実行!

エラーが出る場合、キャッシュが残っている可能性があるため、⌘ + R でキャッシュをクリアして現在のページを再読み込みしてください。
バージョンがアップされていれば更新されるはずです。

最後に

condaやnodejsを使い慣れている人は詰まらないかもしれませんが、もしも大量のエラーログをみて諦めそうになった人のためにこの記事を書きました。

これから、flake8の記事も描こうと思います。

少しでも参考になったら幸いです！

[付録]エラー内容

教訓:エラーログエラーログは最初と最後が肝心

$jupyter lab build

[LabBuildApp] JupyterLab 2.1.5
[LabBuildApp] Building in /Users/hirokazu/opt/anaconda3/share/jupyter/lab
Build failed.
Troubleshooting: If the build failed due to an out-of-memory error, you
may be able to fix it by disabling the `dev_build` and/or `minimize` options.

If you are building via the `jupyter lab build` command, you can disable
these options like so:

jupyter lab build --dev-build=False --minimize=False

You can also disable these options for all JupyterLab builds by adding these
lines to a Jupyter config file named `jupyter_config.py`:

c.LabBuildApp.minimize = False
c.LabBuildApp.dev_build = False

If you don’t already have a `jupyter_config.py` file, you can create one by
adding a blank file of that name to any of the Jupyter config directories.
The config directories can be listed by running:

jupyter --paths

Explanation:

- `dev-build`: This option controls whether a `dev` or a more streamlined
`production` build is used. This option will default to `False` (ie the
`production` build) for most users. However, if you have any labextensions
installed from local files, this option will instead default to `True`.
Explicitly setting `dev-build` to `False` will ensure that the `production`
build is used in all circumstances.

- `minimize`: This option controls whether your JS bundle is minified
during the Webpack build, which helps to improve JupyterLab’s overall
performance. However, the minifier plugin used by Webpack is very memory
intensive, so turning it off may help the build finish successfully in
low-memory environments.

An error occured.
ValueError: Please install nodejs >=10.0.0 before continuing. nodejs may be installed using conda or directly from the nodejs website.
See the log file for details:  /var/folders/sk/rwp7z_r93q92lx1xzwmbxcxr0000gn/T/jupyterlab-debug-rm7nmhd3.log

中間くらいのエラーログは、「メモリが足りないよ。」というメッセージでした。終わり