はじめに

gitのsubmoduleを使う機会があったのですが、間違えて追加して再追加するときに、いろいろ戸惑ったので、まとめました。

submoduleの追加

$ git submodule add サブモジュール化したいリポジトリ パス/名前指定

submoduleの追加は上記のコマンドで行えます。
パス/名前指定を空白にすると、現在のディレクトリにリポジトリ名のままで作成されます。

submoduleの削除

$ git submodule deinit -f 追加したサブモジュール
$ git rm -f client 追加したサブモジュール
$ rm -rf .git/modules/追加したサブモジュール 

submoduleの削除は上記のコマンドで行えます。
忘れがちなのが、.git/modules/追加したサブモジュールですね。これを消し忘れると、ローカルに存在すると言われ再追加ができなくなります。

submoduleの再追加

$ git submodule add サブモジュール化したいリポジトリ パス/名前指定

再追加はsubmoduleの追加と同じコマンドです。
これがうまくいかない場合正しく削除できていないので、確認しなおしましょう。

まとめ

再追加できないときは、.git/modules/追加したサブモジュールの消し忘れの可能性があります。
vscodeではここの差分がでないので注意です。

gitのremote接続用の鍵を使い分けたい

本当はgithubのアカウントは１つだけで管理したいのだけど、仕事とプライベートで２つのgithubアカウントがある場合などは鍵ファイルも２つになってしまう。だけどPCは１台で作業したい時がある。
しかし、githubには２つのアカウントに同じ鍵は登録できない。でもhttpsとかにして毎回ユーザー名とかパスワード入力するのは面倒なので何とかしたい。

　結論

普段は個人用のid_rsaの鍵ファイルを利用しているか、仕事用の鍵をカレントディレクトリのみに適用させたい場合はgit config --local で以下の様にしていできる。

$ git config --local user.name "仕事アカウント名"
$ git config --local user.email "仕事@メールアドレス"
$ git config --local core.sshCommand "ssh -i ~/.ssh/仕事用_rsa -F /dev/null"

※git2.1.0以降のみ設定可能

参考

https時代のgitアカウントを使い分ける方法

はじめに

私が所属する開発チームでは、一つのリポジトリ内に複数製品が同居しており、それら製品の「企画→開発→リリース」の期間が同時期に並列して走る場合がある
その状況で運用しているフローを整理を兼ねて記す

概観

以下のように、Git-flowからreleaseブランチを除き、かつdevelopブランチが複数あるような運用フローとなっている

詳細

基本的なフロー

開発

• マイルストーンごとにdevelopブランチ（開発本線）を切る
• 開発タスクごとに作業ブランチを切り、コードレビュー完了後、developブランチにマージする

検証開始・再開前

• ビルド番号をインクリメントする
  • developブランチ上で直接コミットする
• 検証時にdevelopブランチがmasterブランチに後れを取っていないかを確認し、ある場合は差分をマージする
  • 他の進行中のdevelopブランチや、緊急リリース用のhot fixブランチを確認し、それらをマージする

検証

• developブランチの最新コミット上でビルドし、バイナリを検証チームに渡す

検証時の不具合対応

• 既に存在する作業ブランチで追加修正する場合、以下を確認
  • 作業ブランチの分岐元コミットが古く、developブランチにマージする際コンフリクトが起きる懸念がある場合は、developブランチを作業ブランチにマージした後で作業する
• 修正してコードレビュー完了後、developブランチにマージする
• 「検証開始・再開前」の項に戻り、再度検証開始

検証完了後

• developブランチをmasterブランチにマージする
• タグを打つ
• 他に進行中のdevelopブランチが存在する場合は、そのブランチにもマージする
• 作業ブランチを削除する

例外的なフロー

緊急リリース対応

• masterから直接hot fixブランチを切り、そのブランチ上でコードレビュー・検証を実施する
• 検証完了後、hot fixブランチをmasterブランチにマージする
• その後、進行中のdevelopブランチが存在する場合は、そのブランチにもマージする

参考

• https://qiita.com/KosukeSone/items/514dd24828b485c69a05

社内で、Git-flowもどきフローでGerritによるコードレビューを実施しているので、整理を兼ねてメモする

前提

内容について

記事で書くこと

• 開発時のGerritとの連携方針

記事で書かないこと

• Gerritとの連携の具体的な操作方法
• Git-flowの説明

開発環境

• バージョン管理：Gerrit v3.0.0 (Git)
• バージョン管理のGUIクライアント：SourceTree
• ブランチの運用方法：Git-flowもどき
  • Git-flowからreleaseブランチを除いたもの
  • 開発タスクごとに作業ブランチを切り、developブランチにマージしていく、という流れとなる

実施手順

コードライティング

• ローカルでdevelopブランチをPULL
  • ローカルにリポジトリをクローンしていない場合は、Change-Idのフックによる自動追加を含むコマンドを用いてクローンする
• ローカルでdevelopブランチから作業ブランチを切り、作業開始
  • バージョンやビルド番号を上げるなど作業ブランチを切るまでもない細かい作業は、直接developブランチ上で実施する
• 大きなタスクの場合は、バックアップとこまめな進捗共有のため、WIP(Work In Progress: 作業中)オプションをつけてGerritにPUSH¹しておく
• 作業期間が長い場合は、developブランチを適宜フェッチし、更新がある場合は作業ブランチをdevelopへリベースする

コードレビュー

• 作業が完了したら、Gerritのコードレビュー用ブランチにPUSH²し、レビュアーを割り当てる
  • WIPとして作業していた場合は、Web上でコードレビューを開始ボタンを押下するか、コードレビュー開始オプションをつけてGerritにPUSH³する
• コードレビューで指摘を受けた場合は、作業ブランチ内のコミットを修正し、再PUSHし、コードレビューを再開する
  • コミットメッセージ中のChange-Idは変更しないようにする
• コードレビューが完了したら、最後に承認した人にGerritのWeb上でsubmitしてもらう
  • これにより、リモートリポジトリへ変更がコミットされる

マージコードレビュー

• developブランチにfast-forwardなしでマージ
  • この際、developブランチにチェックアウトした状態で、SourceTreeの画面上部に表示されているマージボタンを押下し、マージされていないコミット一覧画面を利用してマージすると、マージ漏れなどの事故が防ぎやすくなる
• マージによりコンフリクトが発生した場合は適宜修正する
• developブランチをGerritのコードレビュー用ブランチにPUSHする
  • コンフリクトが発生しなかった場合は、自分でコードレビューを通しsubmitする
  • コンフリクトが発生して修正した場合は、前節のようにコードレビューを実施する

---

1. PUSH先リモートブランチをrefs/for/hogehoge%wipに指定 ↩

2. PUSH先リモートブランチをrefs/for/hogehogeに指定 ↩

3. PUSH先リモートブランチをrefs/for/hogehoge%readyに指定 ↩

.gitignoreのテンプレートを確認

ここに .gitignoreのテンプレートがあるので、ここからSwift.gitignoreを開く
https://github.com/github/gitignore/blob/master/Swift.gitignore

ローカルに.gitignoreを作成する

ターミナルで、Xcodeのプロジェクト直下に移動し、.gigignoreファイルを作成する
$ touch .gigignore

Finderでドット始まりのファイルが見れるようにする。

ターミナルで以下のコマンドを入力し、ドット始まりのファイルが見れるようにする。
$ defaults write com.apple.finder AppleShowAllFiles true
$ killall Finder

作成した.gitignoreファイルに、.gitignoreのテンプレートの中身を貼り付ける

ローカルに作成した.gitignoreファイルに、.gitignoreのテンプレートの中身を貼り付ける。

すでにコミットしていた場合は、git管理対象外のファイルの処理を行う

すでにコミットしている場合は、一度すべてのファイルを管理対象外にする。
ターミナルでプロジェクトのディレクトリに移動し、下記のコマンドを実行
git rm -r --cached . →これで一旦管理対象外にする
git add . →改めて管理対象にするコマンド

コミットする

XcodeのGUIでコミットする。

GitHubのURLをコマンドですぐ開けたら便利だなと思って調べてみました。
方法としては open コマンドと hub コマンドを使う場合の二通りあります。

1. openコマンド

HTTPSプロトコルの場合

open $(git config remote.origin.url)

シンプルに書けます。

SSHプロトコルの場合

open https://github.$(git config remote.origin.url | cut -f2 -d. | tr ':' /)

SSHプロトコルでリモートリポジトリを設定していると git@github.com: から始まるので置換してます。また、HTTPSプロトコルでもこのコマンドはそのまま使えます。

alias設定

~/.bash_profile 等に下記コードを追記します。

alias gh="open https://github.$(git config remote.origin.url | cut -f2 -d. | tr ':' /)"

2. hubコマンド

hubコマンドをインストールします。

brew install hub

hub browse コマンドでGitHubのリモートリポジトリのURL

hub browse

参考

• igrigorik/github.bash
• https://github.com/github/hub#git-browse

関連記事

• Mac Git 初期設定
• Mac GitHub SSH接続設定

コミット日時を上書きしたい

Gitのコミットの、差分とコミットメッセージは維持しつつ、コミット日時を書き換えたいことが稀にある。
こないだあったのは、テストのためにローカルホストの日時を未来に変更したままでコミットしてしまい、「未来のコミットになってますよw」という指摘がコードレビューで出たとき。

普通にamendしても上書きされない

通常のamendでは日付は書き換わらない。

$ GIT_PAGER= git log -1
commit 64c414eaa5084c765c79d2e061ced3d5724d00dd (HEAD -> master)
Author: foo <foo@example.com>
Date:   Sun Sep 29 09:59:00 2019 +0900

    an example
$ date
日  9 29 10:02:03 JST 2019
$ git commit --amend
[master 8f3cf01] an example
 Date: Sun Sep 29 09:59:00 2019 +0900
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename a => b (100%)
$ GIT_PAGER= git log -1
commit 8f3cf018573ad002c906e00bfa2facd38fc276ca (HEAD -> master)
Author: foo <foo@example.com>
Date:   Sun Sep 29 09:59:00 2019 +0900

    an example

これは、コミットには２つの日付 AuthorDate と CommitDate が記録されており、amendでは CommitDate の方が更新されるからである。実際、CommitDateの方は更新されている：

$ GIT_PAGER= git log -1 --pretty=fuller
commit 8f3cf018573ad002c906e00bfa2facd38fc276ca (HEAD -> master)
Author:     foo <foo@example.com>
AuthorDate: Sun Sep 29 09:59:00 2019 +0900
Commit:     foo <foo@example.com>
CommitDate: Sun Sep 29 10:02:08 2019 +0900

    an example

方法1: reset-authorオプション

お手軽なのは reset-author オプションを使うこと。以下のようにするとAuthorDateが現在日時になる

$ git commit --amend --reset-author

その名の通り、Authorもリセットされてしまうので、そうしたくない場合には使えない。
ちなみに reset-author オプションと一緒に author オプションを指定するとエラーになる。

$ git commit --amend --reset-author --author "foo <foo@example.com>"
fatal: Using both --reset-author and --author does not make sense

また、この方法だと、現在日時とすることしかできない。

方法2: dateオプション

date オプションで日時を指定するとそれが AuthorDate に設定される。例えば現在日時とするには

git commit --amend --date $(date --iso-8601=seconds)

日時の値を自分で設定すれば任意の日時にすることも可能。ただしこれで設定されるのは、AuthorDateであり、CommitDateの方は現在日時になる。CommitDateも合わせたい場合は、その後でgit rebaseのcommitter-date-is-author-dateオプションを使えば良い。

$ GIT_PAGER= git log -1 --pretty=fuller
commit 96fdf18c0d2580dacf6447d2669124684327de63 (HEAD -> master)
Author:     foo <foo@example.com>
AuthorDate: Mon Sep 30 06:14:11 2019 +0900
Commit:     foo <foo@example.com>
CommitDate: Sun Sep 29 10:14:11 2019 +0900

    an example
$ git rebase HEAD~ --committer-date-is-author-date
Current branch master is up to date, rebase forced.
First, rewinding head to replay your work on top of it...
Applying: an example
$ GIT_PAGER= git log -1 --pretty=fuller
commit c7fa00c0231b4a5505bd6fae2460dc8a65d08eb1 (HEAD -> master)
Author:     foo <foo@example.com>
AuthorDate: Mon Sep 30 06:14:11 2019 +0900
Commit:     foo <foo@example.com>
CommitDate: Mon Sep 30 06:14:11 2019 +0900

    an example

二つ以上前のコミットを対象にするには

git rebase -i で対象コミットをeditとして、amend commitの際に上で説明したいずれかの方法を使えば良い。

確認した環境

$ git --version
git version 2.19.1
$ date --version
date (GNU coreutils) 8.29
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

背景

Python勉強中。
学習用コードのバージョン管理にgitを使おうと、Visual Studio Code上のターミナル（PowerShell）にて、
gitignore.ioを利用して.gitignoreファイルを作成した。

PowerShell

git ignore Python > .gitignore

しかし こうかが なかった。
なぜか、キャッシュファイルであるはずの*.pyc が平然とステージ待ちしている。
.gitignore ファイルでは除外指定をしているはず。

.gitignore

### Python ###
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

#以下略

おかしい。

環境

• Windows 10
• Visual Studio Code 1.38.1
• git 2.13.2.windows.1

原因と対策

すでにgit管理になっている

ググるとよくこれが出てくる。
対象ファイルが既にgit管理対象になっているケース。
キャッシュクリアすることで解決するらしい。

$ git rm -r --cached .

しかし、今回は一度もコミットしておらず、そもそも「さあこれから管理しよう」という段階での問題…。

.gitignoreの文字コードがUTF-16

今回のケースはこれだった。
どうやらPowerShellでリダイレクトして作成したテキストファイルは文字コードがUnicode（UTF-16LE）になるらしく、gitが認識してくれなかった模様。
VSCodeで一度開き、UTF-8として保存し直すことで、正しく認識してくれるようになった。

参考ページ

.gitignore 設定が反映されない場合の対応

Mac にプリインストールされている Git は、ちょっとバージョンが低かったので、

$ git --version
git version 2.20.1 (Apple Git-117)

次のコマンドを実行して、最新版をインストールすると共に、Homebrew で管理できるようにしておきました。

$ brew install git

もし、新しくインストールした方の Git に、パスが通っていなければ、例えば、以下のような行を bash の設定ファイルに追記してみてください。

~/.bash_profile

export PATH=/usr/local/bin:$PATH

これで、最新の Git が使えるようになり、今後は、簡単にアップデートできるようになったはずです。

$ git --version
git version 2.23.0

Mac にプリインストールされている Git は、ちょっとバージョンが低かったので、

$ git --version
git version 2.20.1 (Apple Git-117)

次のコマンドを実行して、最新版をインストールすると共に、Homebrew で管理できるようにしておきました。

$ brew install git

もし、新しくインストールした方の Git に、パスが通っていないようなら、例えば、以下のようなコマンドを実行してください。

$ echo 'export PATH="/usr/local/bin:$PATH"' >> ~/.bash_profile
$ source ~/.bash_profile

これで、最新の Git が使えるようになり、今後は、簡単にアップデートできるようになったはずです。

$ git --version
git version 2.23.0