最近だけど、あるブランチで作業をしていた時に
急遽他の作業依頼が来たんだよね。

あれ、今のブランチの作業履歴ってどうやって保存して
他のブランチを切ればいいん...?って困ったのがきっかけ。

stashを使うとコミットしていない変更履歴を退避させておくことが可能みたい。
まじでgitすごい。

実はstashのこと知る前は、ローカルに変更したファイル群をそのまま保存して
あとで1ファイルずつまた変更しなおしてたんだよね。
まじでなんでもっと早く教えてくれなかった？？？？？？ってブチギレそうになったことが以前ある。

まず変更を退避！

$git stash save "XXXXXX"

これでブランチ上の変更が退避される。
まあつまり、ブランチは変更が加えられていないクリーンな状態になる。
ちなみにXXXXXXのところはコメントだよ。後でこのstashってなんだっけ...?ってならないためのやつ。
俺はいつも"feature/XXXXXX_yyyymmdd"って感じでstash名に加えて年月日をアンダースコアの後に追記してるかな。

※commitしちゃってたらだめだよ。addされた変更もしくはaddされていない変更のみが対象だからね。
　やべえ、commitしちゃってたって人は戻す方法があるからそれはそれで調べてね。ごめん。

え、本当に退避できてんのかな？

$git stash list

// 出力はこんな感じ。もしかしたらちょっとちがうかも。まあいっか。うろ覚えなんでね。
stash@{0}: feature/XXXXXX_yyyymmdd

これでさっきのstashがしっかり保存されている（退避されている）ことが確認できたね。
ついにブランチがクリーンな状態に...　めでたい。
もう思う存分新規ブランチを切りまくってください。バンバン移動してもらって構いません。

よし、退避した変更を元に戻しますか

// stash@{0}の作業を元に戻すよ

$git stash apply stash@{0}

これでなんと、退避した変更は元通り。
微妙にめんどくさいけど、何回かやれば大丈夫すぐなれる。
あ、一点だけ注意。元に戻すときは、ちゃんと変更を元に戻したいブランチへ再移動してからにしてね。
これが最初できてなくて、若干混乱したことが何回かあるんで～

退避履歴溜まってきたし、削除してえ

$git stash drop stash{0}

dropしちゃえば削除できるよ。
削除前と後にはlistでしっかり削除確認してね。
あと、間違えてstashを削除してしまっても元に戻す方法はあるらしい...
それについてはまたどこかのタイミングで！

最後に復習しよっか　これで忘れない

• saveして
• list確認して、他ブランチで作業開始
• 作業が終わったら、ブランチを移動してapplyしてOK
• stashが溜まってきてうぜえってなったらdrop

おわり。
つかれた。

Node.jsのプロジェクトではnpm versionコマンドでバージョンをインクリメントできます。package.json, package-lock.jsonの書き換えと、Gitタグの追加が自動化されます。よく使われるmajor, minor, patchの他に、pre*というプレリリース用のオプションが実装されています。

以下の動作確認はnpm v6.14.5で行いました。

次期バージョンのアルファ版作成

# 1.2.3 => 2.0.0-alpha.0
npm version premajor --preid alpha

premajorを指定すると、次期メジャーバージョンのプレリリース版となります。このとき--preidオプションを指定すると任意の接頭辞（この場合はalpha）が付加されます。接頭辞を指定しなかった場合は2.0.0-0となりました。

アルファ版の中でのインクリメント

# 2.0.0-alpha.0 => 2.0.0-alpha.1
npm version prerelease

プレリリース部分の番号をインクリメントするには、prereleaseを指定します。この場合は--preid alphaを指定してもインクリメントされます。ただ--preidなしの方がbeta.0 => beta.1やrc.0 => rc.1のときでも同様に動作するので、ミスが起こりにくそうです。

アルファ版からRC版に格上げする

# 2.0.0-alpha.1 => 2.0.0-rc.0
npm version prerelease --preid rc

2.0.0のプレリリースであることには変わらないのでprereleaseを指定し、--preidオプションでアルファからRCに変更します。自動的にrc.0がセットされました。Semverではプレリリース版の接頭辞はアルファベット順に解釈されます。（2.0.0-alpha.1 < 2.0.0-rc.0 < 2.0.0）

正式版のリリース

# 2.0.0-rc.0 => 2.0.0
npm version major

上記のコマンドで動きましたが、バージョン指定はminorでもpatchでも同じ結果でした。そもそもバージョン番号は上がってないのでどれもしっくり来ません。明示的にnpm version 2.0.0を実行してもいい気がします。

Node.jsのプロジェクトではnpm versionコマンドでバージョンをインクリメントできます。package.json, package-lock.jsonの書き換えと、Gitタグの追加が自動化されます。よく使われるmajor, minor, patchの他に、pre*というプレリリース用のオプションが実装されています。

以下の動作確認はnpm v6.14.5で行いました。

次期バージョンのアルファ版作成

# 1.2.3 => 2.0.0-alpha.0
npm version premajor --preid alpha

premajorを指定すると、次期メジャーバージョンのプレリリース版となります。このとき--preidオプションを指定すると任意の接頭辞（この場合はalpha）が付加されます。接頭辞を指定しなかった場合は2.0.0-0となりました。

アルファ版の中でのインクリメント

# 2.0.0-alpha.0 => 2.0.0-alpha.1
npm version prerelease

プレリリース部分の番号を上げるには、prereleaseを指定します。この場合は--preid alphaを指定してもインクリメントされます。ただ--preidなしの方がbeta.0 => beta.1やrc.0 => rc.1のときでも同様に動作するので、ミスが起こりにくそうです。

アルファ版からRC版に格上げする

# 2.0.0-alpha.1 => 2.0.0-rc.0
npm version prerelease --preid rc

2.0.0のプレリリースであることには変わらないのでprereleaseを指定し、--preidオプションでアルファからRCに変更します。自動的にrc.0がセットされました。Semverではプレリリース版の接頭辞はアルファベット順に解釈されます。（2.0.0-alpha.1 < 2.0.0-rc.0 < 2.0.0）

正式版のリリース

# 2.0.0-rc.0 => 2.0.0
npm version major

上記のコマンドで動きましたが、引数はminorでもpatchでも同じ結果でした。そもそもバージョン番号は上がってないのでどれもしっくり来ません。明示的にnpm version 2.0.0を実行してもいい気がします。

掲示板を作成中、掲示板の基本機能のみ作ってherokuでデプロイした。
ユーザーログインという新規機能安全にデプロイする為に、新機能開発の前にあらかじめgitでmasterではないブランチを作って、テストを行ってからmasterブランチにmergeを行いたい。

ブランチ作成&そのブランチに切り替え

$ git checkout -b create-users-table-model

Switched to a new branch 'create-users-table-model'

存在するブランチの確認コマンド

$ git branch

* create-users-table-model
  master

ブランチを切り替える

$ git checkout master

Switched to branch 'master'

git checkout create-users-table-model

Switched to branch 'create-users-table-model'

新しいDBテーブルの作成

$ rails g migration create_users

〜省略〜
warning: The called method `initialize' is defined here
      invoke  active_record
      create    db/migrate/20200727081835_create_users.rb

完成。

ここから開発を行っていく。

掲示板を作成中、掲示板の基本機能のみ作ってherokuでデプロイした。
ユーザーログインという新規機能安全にデプロイする為に、新機能開発の前にあらかじめgitでmasterではないブランチを作って、テストを行ってからmasterブランチにmergeを行いたい。

ブランチ作成&そのブランチに切り替え

$ git checkout -b create-users-table-model

Switched to a new branch 'create-users-table-model'

存在するブランチの確認コマンド

$ git branch

* create-users-table-model
  master

ブランチを切り替える

$ git checkout master

Switched to branch 'master'

git checkout create-users-table-model

Switched to branch 'create-users-table-model'

新しいDBテーブルの作成

$ rails g migration create_users

〜省略〜
warning: The called method `initialize' is defined here
      invoke  active_record
      create    db/migrate/20200727081835_create_users.rb

完成。

ここから開発を行っていく。

DBに必要カラムを追記して作成

db/migrate/'date'_create_users.rb

class CreateUsers < ActiveRecord::Migration[5.1]
  def change
    create_table :users do |t|
      t.string :username
      t.string :email
      t.timestamps #created_atなどが自動で追加される
      #passwordカラムはあとから追加する
    end
  end
end

userモデル作成

modelsフォルダの下にuser.rbを追加

models/user.rb

class User < ApplicationRecord

end

保存。$rails cでuserが作成できるか確認。

発生したマージコンフリクト

branchをmasterにチェックアウトしてブランチでの変更をmergeしようとした時にコンフリクトが発生。
初めてのことだったので記録しておくことにしました。
ブランチ作業を終えてmasterブランチにマージしようとしたところ、

$ git merge finalpage
・
・
CONFLICT (content): Merge conflict in config/routes.rb
・
・
Automatic merge failed; fix conflicts and then commit the result.

と、怒られてしまいました。googleで調べてみると、コードの内容に競合が発生した時に起こるとのことらしいですね。git status で確認すると、

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   routes.rb

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

と、なりました。すなわち別々のブランチで修正されていてどっちかにしないとおかしいよ、ってことですね。私の場合、masterブランチの内容とfinalpageブランチ両方で内容の変更が発生しており、双方が両立しないためコンフリクトが発生したのでは、と考えています。

vscodeでコードを確認すると、

routes.rb

  get 'sessions/new'
<<<<<<< HEAD

  resources :users do
    member do
      get '/password_reset', to: 'password_resets#new'
      post '/password_reset', to: 'password_resets#create'
    end
  end
=======
  resources :users
>>>>>>> finalpage

となっていました。
<<< HEAD === >>>　finalpage
で囲まれている内容をlocalで修正しなければならないということなので、

<<<　HEAD ===　に囲まれた内容にしたいため、
=== >>> finalpage で囲まれている内容は手動で削除し、
git add routes.rbを実行して、git statusでコミット内容を確認すると、

On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

        modified:   routes.rb

に変わりました。コンフリクトは直せているからcommitしてマージを完了してね、ってことらしいので、あとはコミットしてマージも完了し、解決できました。

参考文献

https://yu8mada.com/2018/06/13/how-to-resolve-a-merge-conflict-in-git/
こちらの執筆者様が非常に分かりやすく解説されていてとても助かりました！

git-flow を初めて利用する際には git flow init で初期設定を行う必要があります。
チーム開発で利用するための CI 用のシェルスクリプトを作成していた際、この初期設定が完了しているか確認するスクリプトを書いたのでメモしておきます。

そもそも Git Flow って何？という方は以下の記事が参考になるかと思います。

• Git-flowって何？ - Qiita

スクリプト

#!/bin/bash

function warn() { echo "$@" >&2; }

function die() { warn "$@"; exit 1; }

function checkIfGitFlowBranchExists() {
  local branch_config
  local existed_in_local

  branch_config=${1}
  existed_in_local=$(git config --get ${branch_config})

  if [[ -z ${existed_in_local} ]]; then
    die "${branch_config} が存在しません。 Git Flow の初期化を行ってください。"
  fi

  if ! git branch | egrep "\s+${existed_in_local}" > /dev/null; then
    die "${branch_config} に指定したブランチが存在しません。"
  fi
}

function checkIfGitFlowInitialized() {
  # cf. https://stackoverflow.com/questions/28464229/programmatically-determine-if-git-flow-is-initialized
  local master_branch_config
  local develop_branch_config

  master_branch_config="gitflow.branch.master"
  develop_branch_config="gitflow.branch.develop"

  # 1. gitflow.branch.master が設定されており、設定したブランチが存在すること
  checkIfGitFlowBranchExists ${master_branch_config}

  # 2. gitflow.branch.develop が設定されており、設定したブランチが存在すること
  checkIfGitFlowBranchExists ${develop_branch_config}

  # 3. gitflow.branch.master と gitflow.branch.develop に指定したブランチが別のブランチであること
  if [[ $(git config --get ${master_branch_config}) == $(git config --get ${develop_branch_config}) ]]; then
    die "master ブランチと develop ブランチを分けてください。"
  fi

  # 4. release/hotfix ブランチが設定されていること
  if [[ -z $(git config --get "gitflow.prefix.release") || -z $(git config --get "gitflow.prefix.hotfix") ]]; then
    die "release ブランチまたは hotfix ブランチが設定されていません。"
  fi
}

checkIfGitFlowInitialized # 初期設定チェック

git flow init が実行済みかどうかを確認する手順については Stack Overflow の関連 Q&A を参考にしています。
以下に引用した回答の内容をスクリプトとして落とし込んでいます。

Answered here. Basically:
1. Check config for gitflow.branch.master and if the branch does exist in the repo
2. Check config for gitflow.branch.develop and if the branch does exist in the repo
3. Master branch can not be the same as develop branch.
4. Make sure all the prefixes are configured.

1 と 2 では .git/config の以下の設定およびそのブランチが存在することを確認し、加えて 3 で2つのブランチが別々のものであることを確認しています。

[gitflow "branch"]
        master = master
        develop = develop

4 は以下の prefix 設定があるかどうかの確認です。

[gitflow "prefix"]
        feature = feature/
        release = release/
        hotfix = hotfix/
        support = support/
        versiontag =

上記のスクリプトでは release と hotfix しか見ていませんが、必要に応じて feature ブランチなども確認するようにスクリプトを修正してください。

ちなみに

git-flow をデフォルト設定で運用することをチーム内で合意できるのであれば、 git flow init -df で強制的に初期設定を行ってしまった方が早いかもしれません。

方法

git branch --merged
によって、マージ済みのブランチを一覧表示します。

git branch -d ${branch_name}
によって、指定した名前のブランチを削除します。

これを合体させた

git branch -d $(git branch --merged)

これなら、簡単に全てのマージ済みブランチをローカルから削除することができます。

参考

Gitでマージ済みブランチを一括削除

※develop と master は消さないようにしています。

とあるように、こちらでは、今紹介したコマンドでは考慮していないことを考慮されています。

なので、今紹介したコマンドは、 develop で実施しないと悲しいことになる可能性があります。
（リモートには残ってるからどうとにもなる）

サーバ内で作業していて、時々発生する「とにかくプルさせてくれ」という場合の対応。
毎回わからなくなるので、ほぼ自分用のメモになります。

# git fetch origin
# git reset --hard origin/master