こんにちは、バカンのソフトウェアエンジニアの垣野内です。
この記事はバカン Advent Calendar 2019の2日目の投稿です。
プログラミング初心者向けの記事を1つお届けしようと思います。

なぜ git の記事か

自分自身、初心者だった時に git がなかなか理解できなかった記憶があり、このような解説があればもう少し習得が簡単だったかもしれないなーと思ったからです。
なので、git に入門したい・git に入門しようと思ったけど挫折したことがあるという方が想定読者です。
この記事を読んで git の基本的なことを理解できれば、適宜ググることができるかと思います。

類書にない点/工夫した点は、以下の3点です：

1. コマンドラインで git のコマンドを懇切丁寧に解説にした
2. git のコマンドの話と git の概念的な話を明確に分離しつつ、それらの対応を意識的に書いた
3. git の入門のゴールを2段階に分けた(個人で使うシーンとチームで使うシーン)

コマンドラインでの学習をおすすめするのは、git の操作に集中できるからです。
(はじめからGUIツールでやってしまうと、何がgit の操作で何がそのツールの便利機能なのかという区別がつきにくいのではないかと思います)¹

”黒い画面”を怖がらず、ぜひ見よう見まねで try してみていただければと思います！

それでは本題です！
まわりくどい説明が嫌いな方は git における4つの場所と5つのアクション に飛んでください！

そもそもなぜバージョン管理をするのか

そもそもなぜバージョン管理をするのかというモチベーションを考えながら、ファイル名に日付やバージョン( 画面仕様書_20191201.xlsx や 来期売上目標_v1.0.1.ppt など)を書いたり、変更履歴のシートを作ったりするスタイルのバージョン管理(以下本稿では「手動スタイル」と呼ぶことにします)だとどのような問題点が起こってくるのかを見ていきます。

(もちろん、手動スタイルで事足りればそれでよいのです)

• 変更履歴を調べたい
  一人で作業している時でも過去に自分の変更を調べたくなる時はあるでしょうし、チームで同じファイルを触っている時は、いつの間にかファイルが変わっていて、誰がどのような意図で変更したのかを調べたくなる時もあるでしょう。開発の文脈ではバグ調査に便利ですね。 これを手動スタイルでやろうと思うと、日付だけでは情報が足りませんし、かなり骨の折れる作業になることが予想されるでしょう。
• 過去のバージョンに戻りたい
  変更を加えてみたものの、やっぱり過去のやつに戻したくなる時があるかと思います。直前の状態に戻せばいいだけであれば手動スタイルでも全く問題ないですが、さらにさかのぼりつつ特定の変更は消したくない場合などを考えると、少し面倒になってきそうですね。
• ファイル同士の整合性を保ちたい
  あるフォルダ² の中にファイルAとファイルBがあって、これらのファイルに関係性がある場合を想像してみてください。例えば、仕様書の概要をファイルAとして書き、詳細はファイルBに譲る時などです。この時、ファイルAとファイルBのバージョンには一定の制約が出てくるはずです。ファイルAがバージョンXの時はファイルBはバージョンYでないと困る; つまり、どちらかが古いと困るわけですね。 git ではこのような状況を解決するために、フォルダごとバージョンを管理します。
• 共同作業をしたい
  あるファイルのとあるバージョン(例えば example_v1.0.1.txt だとしましょう)対して、AさんとBさんが同時にかつ別の変更を加えたい時がしばしばあります。同時編集を許可することによって解決するのがよくあるやり方ですが、互いの作業を気にしながらやることになりますね。 git ではこの動機に対して(軽量な)ブランチという考え方で対処します。ブランチとは「枝分かれする」という気持ちで、第二回で詳しくみていきますが、喩えるならパラレルワールドを作るようなイメージです。
  (とはいえ互いの作業を全く気にしなくてよくなるわけではありませんが)

git における4つの場所と5つのアクション³

ここでは 概念的な話とともに git の用語を解説します。一読してわからなくても、コマンド練習その1のところで意味がわかるかもしれません。往復しながら読んでみてください！

git ではバージョン管理したいフォルダをまるごと監視対象にします。この時、フォルダの中は以下の図のように3つの場所にわかれます。

• リポジトリ
  バージョン管理をしている実体です。データベースと思ってもよいでしょう。
• ステージングエリア
  保存する単位を作るところです
• 作業ディレクトリ(ワーキングディレクトリとも)
  バージョン管理対象のファイル/フォルダです。基本的にここしか直接触りません。 (ステージングエリアやリポジトリに対してはコマンドを通して指示するのみ)

作業ディレクトリでなにか変更をしたら、その変更をステージングエリアに一度うつします。これを「ステージングエリアに add する」などと言ったりします。
次に、ステージングエリアにあるものをリポジトリにうつすことで、その変更が記録されます。これを「コミットする」と言い、この時にリポジトリにできた変更の単位を「コミット」と言います。
「変更して、add して、commit する」 という流れです。
(次節でコマンドの練習をするとこの流れがよりイメージができるかと思います)

このステージングエリアがあることにより、ファイル同士の整合性を取ったままバージョン管理をすることができます。
例えば、ファイルAの変更とファイルBの変更を一つの変更の単位としてコミットすることができるというわけです。

さて、今の説明は個人のPCでの作業の流れでした。この変更を他の人と共有するにはどうすればいいでしょうか？
git では、以下の図のようにリモートリポジトリというものを作ります。対して、個人個人のPCの中にあるリポジトリはローカルリポジトリとよばれます。(つまり、上の図のリポジトリは正確に言えばローカルリポジトリです)
ローカルリポジトリの変更をリモートリポジトリに反映することを「pushする」と言い、逆に、リモートリポジトリの最新の状態をローカルリポジトリに反映させることを「fetchする」と言います。
(fetch とは「引っ張ってくる」という気持ちです)
なのでリモートリポジトリまで含めると、「変更して、add して、commit して、pushする(リモートが変更されてたら適宜fetchする)」 という流れになります。

また、ローカルリポジトリがまだない時は、リモートリポジトリをまるっと持ってきます。
これを「clone する」と言います。
一度 clone したら先ほどの説明のとおり、「変更して、add して、commit して、pushする(リモートが変更されてたら適宜fetchする)」 という流れです。

非常におおざっぱですが、以上が git の考え方と基本的な用語の説明です。
(繰り返しますが次節でコマンドの練習をするとよりしっくりくるはずです)
もう一度用語を列挙しておきます：

• リモートリポジトリ
• ローカルリポジトリ
• ステージングエリア
• 作業ディレクトリ/ワーキングディレクトリ
• clone
• add
• commit(名詞と動詞)
• push
• fetch

コマンド練習その1

概念的なところがなんとなく理解できたところでコマンドの練習にうつっていきたいと思います！
git をインストールした後、以下読み進めてください。

まずは適当なフォルダを作りましょう。ここでは gittest というフォルダを作りました。

次にMac ならターミナルを、Windows であればコマンドプロンプトあるいはGit Bash を開いてください。⁴ そして、今作った gittest というフォルダに移動してください。(Mac / Windows ともに cd で移動できます)

最初に git init というコマンドを叩いてみましょう。
このコマンドを実行すると、そのフォルダが git の監視対象となります。
実はこの時隠しフォルダとして .git フォルダが生成されており、この中に上述したリポジトリとステージングエリアがあります。逆に言うと、この隠しフォルダを消してしまえば再びただのフォルダになります。

次に、git status というコマンドを叩いてみましょう。git として現在どういう状態にあるのかを表示してくれるコマンドです。情報を教えてくれるだけで何も破壊しないので、困ったらこのコマンドを叩いてみるとよいでしょう。
ここではまだ何もコミットをしていないにで、「No commits yet」と言われるだけかと思います。

それでは、なにかファイルを加えてみましょう。ここでは test1.txt というファイルに「git first test」と書いて保存してみました。

もう一度 git status を叩いてみましょう。
今度は、「No commits yet」に加えて、「Untracked files:test1.txt」と言われたかと思います。そしてカッコ書きで、「use "git add ..." to include in what will be committed」と書いてあるかと思います。「コミットするものに入れたかったら git add <ファイル名>とコマンドを打ってね」と言っています。

では git に言われたように git add <ファイル名> を叩いて、また git status をしてみましょう！
今度は、「Changes to be comitted: 」と表示されたかと思います。これが今ステージングエリアにあるものの一覧です。
git addによって、作業ディレクトリから、ステージングエリアにうつったということです。

それではいよいよコミットです！ git commit -m ”コミットメッセージ” と打ってみましょう！コミットメッセージは、変更の意図を記録しておくものです。(-m をつけることでコミットメッセージをつけられます)
後から調査した時に、なぜこの変更を入れたのかをわかるようにしておくと便利です。ここではテストのためあまり真面目にやらず、git commit -m "first commit" としておきます。

以下のような表示がされていれば初のコミット成功です！おめでとうございます
これであなたもgitに入門できました！
このコマンドで、ステージングエリアにあったものがローカルリポジトリにコミットされ、コミットとして記録されました！

ここでもう一度 git status をしてみましょう。「nothing to commit」つまり、「コミットするものはないですよ」となっているはずです。

コミットしたものを確認するにはどうすればいいでしょうか？そのためのコマンドが git log です。たたいてみましょう！
変更者(Author)、日付(Date)、変更理由(コミットコメント)が表示されましたね。

「変更して、add して、commit する」 という流れを掴んでいただけたでしょうか？
読者の練習としますが、先程のtest1.txtの中身を変更して、もう一度同じことをしてみてください。git log で以下のようにコミットが2つになっていれば成功です！

---

この節のおさらいです。以下のコマンドを身につけ、git の基本的な流れである 「変更して、add して、commit する」 を理解していただけたかと思います。
- git init (git リポジトリを作成します)
- git status (git としての状態を確認できます)
- git add <ファイル名> (修正をステージングエリアにあげます)
- git commit -m ”コミットメッセージ” (ステージングエリアにあるものをリポジトリにコミットします)
- git log (コミットの履歴を確認できます)

GitHub について

コマンド練習その1 ではローカルリポジトリのみの作業でした。
ところで、リモートリポジトリはどこにおくとよいのでしょうか？
実はこれはどこでもよいのです。どこか別のPCでもよいですし、サーバをレンタルしてそこに作っても構いません。
そこで便利なのが GitHub です。 GitHub は git リポジトリの”置き場所”を提供してくれるとともに、開発の文脈で言えばコードレビューなどが非常に便利なため、これをリモートリポジトリとして使うケースが多いです。
gitリポジトリの”置き場所”を提供するサービスのことを「gitのホスティングサービス」などと言ったりしますが、GitHub 以外にも、Bitbucket や GItLab などが有名です。チームによって何を使うか変わってくるでしょう。

GitHub も少し練習をしてみましょう！

まず、GitHub 上で git リポジトリを作ってみます。GitHub のアカウントを作ったら、右上の「New repository」というところをクリックし、Repository name に適当な名前(ここでは github_test としました)を入力し、「Initialize this repository with a README」にチェックを入れ(入れなくてもいいんですが、通常作るので)、「Create repository」ボタンをクリックします。
(GUIで簡単にできますが、リモートリポジトリで git init しているということです)

すると、作ったリポジトリの画面に移ると思うので、「Clone or download」のボタンをクリックし、URLの右のコピーボタンをクリックしてください。(ここでは SSH ではなく HTTPS を使うので初心者の方は注意してください)

再びターミナルに戻ります。さっきのディレクトリとは別のところに行き、git clone <さっきコピーしたもの>とコマンドを打ちます。

すると、github_test というフォルダができるので、そこに移動します。git status と git logを叩いてみましょう。
コマンド練習その1の時と違い、git log で origin というものが出てくるようになりましたね。
これは、リモートリポジトリのことです。⁵

ではコマンド練習その1の時と同じように、「変更して、add して、commit する」 をやってみましょう！以下のような log が作れたらOKです！

そして今度は push してみます。git push origin master と叩いてみましょう！
以下のような表示が出ていれば成功です！
これで、ローカルリポジトリの変更がリモートリポジトリに反映されました！

先ほどの GitHub のリポジトリの画面に行ってみましょう！ローカルでの自分の修正が反映されているでしょうか？

最後に、もう一度 git log を見てみましょう。git push したので、リモートの状態がローカルの状態と一致していることはずです。

---

この節のおさらいです。GItHub を例に取って、リモートリポジトリを含めた git の流れ： 「変更して、add して、commit して、pushする」 を理解していただけたかと思います。

1人でバージョン管理をする場合は、ここまでだけでも十分と言ってよいでしょう。

おわりに

git の使い方がなんとなくわかっていただけたでしょうか？
次回(アドベントカレンダーでやるかは未定ですが)はチームで使うシーンを想定しつつ、ブランチの話をしたいと思います。

それではよいお年を！！
明日はIoTの会社らしい記事です！お楽しみに！

参考文献

• 入門Git 絶版となってしまったようですが、個人的にはとても好きな本です。合う/合わないがとてもはっきりわかれる本だと思います。
• Git の仕組み (1) この記事を読んで Git って面白いなと思ったのでした。ものごとの仕組みに興味のある方は、コマンドに慣れてきたころに読んでみると面白く読めると思います。
• サルでもわかるGit入門
• https://twitter.com/098ra0209/status/1163424568544907265 最近 twitter で見つけたものです。ポップな絵とともに用語の整理ができてよいですね。

参考リンク

• 株式会社バカン（Vacan, Inc.）
• バカン (Vacan) Advent Calendar 2019

---

1. プログラミングにしても、最初はIDEを使わずに軽量なエディタとターミナルで入門するとよいのではないかと思ってる派です。 ↩

2. 初学者の方になじみやすいよう、本稿では(ディレクトリではなく)なるべくフォルダという言い方を選んでいます。 ↩

3. この表現は、『スッキリわかる Java入門 実践編』におけるSVNの説明;「2つの場所と3つのアクション」というものを拝借し、git 版にしたものです。いい説明だなと思いました。 ↩

4. 筆者は git bash 推しです。windows のコマンドを思い出すのが面倒くさいからですw ↩

5. 正確に言うと、リモートリポジトリの1つに origin という名前がつけられています。 ↩

この記事は ギフティ Advent Calendar 2019 - Qiita 2日目の記事です。

背景

つい夢中になって開発していたら、変更箇所が多岐にわたってしまい、レビュワーを面食らわせた・・・こんな経験、誰もが一度はあるのではないでしょうか？プルリクの粒度については色々な意見があるかと思いますが、「巨大すぎるプルリクはレビューの精度を下げるのでよくない」という認識はそれなりに一般的なものだと思います。

とはいえ、「プルリクが大きくなりすぎないように常に 気をつけましょう 」という改善ほど意味のないものはありません。改善は常に具体的なアクションであるべきです。どうすれば同じ失敗を繰り返さずに済むでしょうか？

改善案 : 変更量を継続的に知ろう

先に結論を書くと、ローカルで git commit するたびに、作業ブランチとマージ先ブランチの差分量を表示するようにしてみました。

===================================================================
develop ブランチとの差分 :

 lib/foo/bar.rb    | 15 +++++++++++++++
 lib/foo/baz.rb    | 11 +++++++++++
 lib/foo/corge.rb  | 28 ++++++++++++++++++++++++++++
 lib/foo/foo.rb    |  6 ++++++
 lib/foo/fred.rb   | 11 +++++++++++
 lib/foo/garply.rb |  1 +
 lib/foo/grault.rb |  4 ++++
 lib/foo/plugh.rb  | 10 ++++++++++
 lib/foo/quux.rb   |  2 ++
 lib/foo/qux.rb    |  7 +++++++
 lib/foo/thud.rb   | 11 +++++++++++
 lib/foo/waldo.rb  |  6 ++++++
 lib/foo/xyzzy.rb  |  4 ++++
 13 files changed, 116 insertions(+)

ファイル変更数が 10 を超えました。そろそろプルリク出しませんか？
===================================================================

このアクションを思いついたときに考えていたのは、今の作業ブランチの変更量を知る機会が少なすぎないか？ということです。例えば、今の作業による Files changed の数を、プルリク作成前に見る機会はどれくらいあるでしょうか？ CLI だと、コミットしたときに「そのコミット単体の変更量」は表示されますが、「そのブランチ全体の変更量」は表示されません。これがもし git commit のたびに表示されれば、スコープの肥大化にいち早く気づき、キリのいいところで作業を止めて、適切な粒度でプルリクを出せそうです。

実装方法は簡単で、手元のリポジトリの .git/hooks/ 配下に、 post-commit というファイル名で、以下のスクリプトを保存するだけです（手元の Mac で確認しました）。

#!/bin/sh

TARGET="develop"
GITDIFF=`git diff --color --stat-width=800 $TARGET HEAD`
THRESHOLD=10

echo "==================================================================="
echo "$TARGET ブランチとの差分 :"
echo ""
echo "$GITDIFF"
if [ $(echo "$GITDIFF" | grep -v "changed" | wc -l) -gt $THRESHOLD ]; then
    echo ""
    echo "ファイル変更数が ${THRESHOLD} を超えました。そろそろプルリク出しませんか？"
fi
echo "==================================================================="
echo ""

もちろん、ファイル変更数が規模の全てではないとは思いますが、目安としては今のところ十分活用できています。導入も廃止も簡単なので、よければぜひ活用してみてください。

ちなみに

GUI の Git アプリだと毎回表示されてたりするんでしょうか・・・。

この記事はtomowarkar ひとりAdvent Calendar 2019の2日目の記事です。

今日は最近ようやく手を出したエイリアスについて書いていきます。

どうでもいい話ですが、よくaliasをaliesとtypoしてしまうのを治したいです。

エイリアスとは

エイリアスとは、偽名、別名、通称などの意味を持つ英単語。ITの分野では、ファイルなどの実体を別の名前で参照するためのシンボルといった意味で使われることが多い。エイリアスとは - IT用語辞典 e-Words

ということでよく使うコマンドや、いつまでたっても覚えられないコマンドを、自分好みの別名をつけることができます。

今回は僕が定義しているエイリアスの一部を載せていきたいと思います。

エイリアスの設定場所

.bashrcというbashを起動したときに読み込まれるファイルにエイリアスを定義していきます。

ターミナル

vi ~/.bashrc

Git関連

まず最初にGit関連のショートカットを定義していきます。
この辺りはよく使うので一度エイリアスを定義して覚えてしまうと作業が捗ります。

# .bashrc
alias gco='git checokut'
alias gcb='git checokut -b'
alias glo='git log'
alias gad='git add'
alias gcm='git commit -m'

ショートカット

dt(デスクトップに移動)や..(一つ前のディレクトリに移動)は本当によく使います。

またVSCodeのコマンドとしてcodeコマンドがあり、code {path}という形で該当パスの新しいウィンドゥを開くことができます。
なのでよく使うワークスペースを登録しておくととても楽になります。

VSCodeのショートカットは以下記事が参考になりました。
https://qiita.com/naru0504/items/c2ed8869ffbf7682cf5c

# .bashrc
alias dt='cd ~/Desktop'
alias ..='cd ..'
alias vbr='vi ~/.bashrc'
alias sbr='source ~/.bashrc'
alias vbp='vi ~/.bash_profile'
alias sbp='source ~/.bash_profile'
alias vsc='open -a "Visual Studio Code"'
alias v='code .'
alias jn='jupyter notebook'

alias now='date +%Y%m%d%H%M'

BashのDateコマンドを用いた`nowは一時的なファイルを作る際に名前を考えなくていいので個人的に好きです

e.g.

ターミナル

$ now
201912040000 // このようにYYYYMMDDHHMM形式で出てくる

$ touch `now`.txt
$ ls
YYYYMMDDhhmm.txt

参考: Bash Date – Format Options and Examples

関数を作る

もう少し汎用性を上げるために、関数を定義していきます。
mkdir と cdを組み合わせた関数を作成します。
参考: シェルスクリプトで関数を利用する

# .bashrc

function mkcd(){
  mkdir $1 && cd $1
}

e.g.

ターミナル

$ mkcd qiita   // mkdir qiita && cd qiita と同意

変更を保存する

最後に定義したエイリアスを保存します。
~/.bash_profileに~/.bashrcを読み込ませるのがいいみたいで
~/.bash_profileにsource ~/.bashrcを追記し、さらにその変更をsource ~/.bash_profileで更新しています。

ターミナル

$ echo "source ~/.bashrc" >> ~/.bash_profile
$ source ~/.bash_profile

まとめ

• エイリアスを設定すると作業効率が上がる
• よく使うコマンドはエイリスでショートカットにしよう
• Bashで関数を使ってより汎用的な定義もできた

以上明日も頑張ります！！
tomowarkar ひとりAdvent Calendar Advent Calendar 2019

はじめに

初めまして。半年ほど前に未経験からRails中心の開発にアサインされた新卒社員のyagaodekawasuです。

さて、Gitでコード管理をしながらチーム開発していたある日、作業途中のブランチについて先輩社員から「現状把握したいから、取り敢えず今できてるとこまでpushして」と言われました。

その時のブランチはHEADがスナップショットのための中途半端なコミットだったので、最新の一つ前までのコミットをpushしたい（下図参照）と思ったのですが、「git push 途中まで」とかのワードでググっても求めているソリューションにたどり着くことができませんでした。

先輩達の助言を得てなんとか目的を達成することができたものの、また同じようなことがあった時のことを考えて、忘れないうちにインターネッツに書き留めておこうと思います。

A--B--C--D
      ↑  ↑このコミットは作業途中でゴチャゴチャしてるから
      └ A~Cをpushしたい

ゴール

ここでは便宜上"sample"という名前の適当なリポジトリを作成し、空のファイルを１つ作成しただけのコミットを4つ用意して説明することとします。初期状態では、リモートブランチには最初のコミットだけがpushされています。
ここから"Make piyo"までのコミットをpushすることが今回のゴールです。

$ git tree
*       yagaodekawasu      64a1dce  (HEAD -> master) Make hogehoge
*       yagaodekawasu      06b4153  Make piyo
*       yagaodekawasu      63c971c  Make fuga
*       yagaodekawasu      b49190e  (origin/master) Make hoge

なお、ここで叩いているgit treeは以下の記事で紹介されている拡張されたgit logコマンドのエイリアスです。非常に便利ですのでまだ導入されていない方はこの機会にどうぞ。

git log を見やすくする

解法1. stashを使う△

最初に試した方法です。
コミットしていない変更点は、ステージング（add）しているかどうかに関わらずgit stash saveによってスタックに退避させることができます。
pushが完了したら、git stash pop stash@{n}で元に戻します。

// 最新のコミットを取り消してステージング状態に戻す
$ git reset --soft HEAD~

// 戻ってることを確認
$ git status
ブランチ master
コミット予定の変更点:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hogehoge

// 未コミットの変更を退避
$ git stash save
Saved working directory and index state WIP on master: 06b4153 Make piyo

// stashの中身を確認
$ git stash list
stash@{0}: WIP on master: 06b4153 Make piyo

// pushする
$ git push origin HEAD
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 407 bytes | 407.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To github.com:yagaodekawasu/sample.git
   b49190e..06b4153  HEAD -> master

// 確認
$ git log
commit 06b415305173622c08ea88823dadcf5c378595b6 (HEAD -> master, origin/master)
Author: yagaodekawasu
Date:   Mon Dec 2 10:15:46 2019 +0900

    Make piyo

commit 63c971c71b7400262108a6548ee5148d9569828d
Author: yagaodekawasu
Date:   Mon Dec 2 10:15:24 2019 +0900

    Make fuga

commit b49190ec49ce28ea8762a1b234224cd9705d3c36
Author: yagaodekawasu
Date:   Mon Dec 2 10:13:34 2019 +0900

    Make hoge

// 退避させた変更を元に戻す
$ git stash pop stash@{0}
ブランチ master
コミット予定の変更点:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hogehoge

Dropped stash@{0} (ecf2c08c7c1df809407255b775f39d700feafe39)

上手くいきましたね。
ただ工数が多いのと、2つ以上前までのコミットをpushしたい場合に対応できない（多分不可能ではないがとても面倒）のが難点です。stashした変更を再度pushし直さないといけないのもイケてません。
まぁstashの練習にはなるかな、という感じですね。

解法2. 1行で済ませる◎

お待たせしました。こっちが本題です。
解法１を社内Slackに載せて「できたぜ！！ﾄﾞﾔｧ...」していたら、先輩が（っ'-')╮=͟͟͞͞　ｽｯとこんなコマンドを投げて寄越しました。

git push origin HEAD~:<remote-branch>

思わず「そマ！？」と返信してしまいました。不敬罪で減給されなくてよかったです。
取り敢えず、先ほどの状態から半信半疑でコマンドを叩いてみます。

$ git tree
*       yagaodekawasu      3965f49  (HEAD -> master) Make hogehoge
*       yagaodekawasu      06b4153  Make piyo
*       yagaodekawasu      63c971c  Make fuga
*       yagaodekawasu      b49190e  (origin/master) Make hoge

$ git push origin HEAD~:master
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 407 bytes | 407.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To github.com:yagaodekawasu/sample.git
   b49190e..06b4153  HEAD~ -> master

$ git log
commit 3965f49e9d1fe43ce0ecaa56c7a287a1dc4c6466 (HEAD -> master)
Author: yagaodekawasu
Date:   Mon Dec 2 11:31:20 2019 +0900

    Make hogehoge

commit 06b415305173622c08ea88823dadcf5c378595b6 (origin/master)
Author: yagaodekawasu
Date:   Mon Dec 2 10:15:46 2019 +0900

    Make piyo

commit 63c971c71b7400262108a6548ee5148d9569828d
Author: yagaodekawasu
Date:   Mon Dec 2 10:15:24 2019 +0900

    Make fuga

commit b49190ec49ce28ea8762a1b234224cd9705d3c36
Author: yagaodekawasu
Date:   Mon Dec 2 10:13:34 2019 +0900

    Make hoge

ははぁ〜、上手くいってますねぇ。。。あの血の滲むような努力は何だったのか。。。
この方法なら、HEAD~をHEAD~2にすれば最新の2つ前のコミットまでをpushできるような拡張性が担保されます。

どういう仕組み？

上手く行ったのは良かったんですが、気になるのは「どうしてこういう書き方ができるのか？」。
私がGitを習得するために参考にしたサイトでは、git pushにこんな文法があるなんて書いてなかったような...
で、公式ドキュメントを参照しました（git push --helpでも見れます）。

Git - git-push Documentation

これを見ると、git pushの汎用的な文法規則は

git push [<options>] [<repository> [<refspec>…​]]

であることがわかります。オプションの他にはリポジトリと参照点を引数として渡せるということですね。
で、ここで問題となるのは<refspec>の部分ですが、この<refspec>は細分化すると

<refspec>…​ = +<src>:<dst>

と書けるようです（"+"はここではあまり重要ではなさそうなので割愛）。

<src>にはpushしたいブランチ・特定のコミットのハッシュ値またはそのエイリアス（"master~4"や"HEAD"など）が入ります。

<dst>はこのpushによってリモートのどのブランチが更新されるかを表します（コミットのハッシュ値・エイリアス不可）。

というわけで、先ほどの

git push origin HEAD~:master

というコマンドは、「"origin"という名前が付けられたリモートリポジトリの"master"というブランチが、ローカルの"HEAD~"までを参照する」という意味だったんですね。
ちなみにHEAD~は@~とも書けるし、pushするブランチがmasterの場合master~でも同じことです。

結論

やっぱマニュアルをちゃんと読もう。

余談1. git stashとは何か？

解法1でgit stash saveとかgit stash popとか叩いて、結果確認して「上手くできた。良かった。」とかしてましたが、やっぱりちゃんと理解して使わないといつか足下を掬われる気がするので調べてみました。
git stash saveした状態でログを確認すると、このような表示になります。

$ git tree
*       yagaodekawasu      0d576db  (refs/stash) WIP on master: 06b4153 Make piyo
|\  
| *     yagaodekawasu      dad1769  index on master: 06b4153 Make piyo
|/  
*       yagaodekawasu      06b4153  (HEAD -> master, origin/master) Make piyo
*       yagaodekawasu      63c971c  Make fuga
*       yagaodekawasu      b49190e  Make hoge

・・・どゆこと？　と思ってググった結果、この記事にたどり着きました。

サクッと使いこなすためのgit stash Tips & stashの仕組み#おまけ---stashの仕組み

雑にまとめると、git stash saveは

①HEADからブランチを切ってステージングされた差分（index）をまとめたコミットを作成
②同じくHEADから別のブランチを切ってステージングされていない（WIP：Work In Progress「作業中」）変更をまとめたコミットを作成
③両者をrefs/stashにマージ

ということをしているらしいです。賢い。
（①、②で切り出されたブランチ名が何であるかは、今回は調べきれませんでした。）

複数stashしている場合は、最初のstashを0番目として、stash@{n}でアクセスできるって感じですかね。

余談2. git resetについて

解放1でgit reset --soft HEAD^というコマンドを叩きましたが、ここは--softを付けなくても問題ありません。
オプションの有無でどのような違いが生じるかは、以下のエントリで詳しく説明されているので、気になる方は読んでみてください。とても参考になりました。

[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法

余談3. git pushについてもう少し

手元で解法１を検証してから解法２の検証に移る時、

git push -f origin b49190e:master

で初期状態に戻したりしました。
b49190eは最初のコミットのハッシュ値です。"~"や"^"の使い方に自信がない時はハッシュ値で直接指定した方が安全かもしれません。
ちなみに"~"と"^"については以下の記事がわかりやすかったです。

【やっとわかった！】gitのHEAD^とHEAD~の違い

別の使い方をすればブランチの削除もできてしまう（むしろそっちの使い方の方が有名？）ようなので、この記法一つ覚えておくとGitでできることがかなり広がるかもしれませんね。

余談4. "@"

"HEAD"のエイリアスとして"@"が導入されたのはGit 1.8.5（2013年11月29日リリース）からだそうです。
意外と検索してすぐにヒットしなかったので、覚書程度に。

Git 1.8.5 最新情報 | Atlassian Blogs

参考文献

Git ユーザマニュアル (バージョン 1.5.3 以降用)
【git stash】コミットはせずに変更を退避したいとき
git push の取り消し方法 | WWWクリエイターズ
Git の仕組み (1) - こせきの技術日記

ご清覧ありがとうございました！

はじめに

下記のような複数既にブランチが存在するGitHubレポジトリにおいて、ローカルにgit cloneしたとします。

例えば上記ブランチのfeature/initialSetupに切り替えたいとしてgit branchしてみると、developブランチしか見当たりません。

$ git branch
* develop

このような場合の対処法を記します。

コマンド

git branchに-aをつけて、remotes側（GitHub側）に隠れているブランチを確認します。

$ git branch -a
* develop
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/feature/initalSetup
  remotes/origin/feature/locale
  remotes/origin/feature/navigation
  remotes/origin/feature/setup-collection
  remotes/origin/feature/setup_navigation
  remotes/origin/feature/view
  remotes/origin/feature/view_passwordRecovery
  remotes/origin/firebase_auth
  remotes/origin/master

その後、切り替えたいブランチを指定します。
例:feature/initialSetupに切り替え

$ git checkout feature/initalSetup
Branch 'feature/initalSetup' set up to track remote branch 'feature/initalSetup' from 'origin'.
Switched to a new branch 'feature/initalSetup'
$ git branch
  develop
* feature/initalSetup

はじめに

ブランチを切ったときのmasterについて、他の作業者が他ブランチで作業更新→masterにマージした場合、自分の作業用ブランチに最新状態を反映させたいときがあります。
その際の一連のコマンドを記します。

コマンド

最新のmasterブランチの更新状況を組み込みたいブランチに変更します。
例:hogehogeブランチで作業している場合

git checkout hogehoge

ブランチ変更後、下記コマンドを入力

git pull origin master

現在のhogehogeブランチにmasterの最新コードが反映されます。
この際、コンフリクトすることがよくあるので下記コマンド内容のUnmerged paths:に書かれたファイルを確認して、解消していきます。
解消後はgit commit -am "fix conflict"といった感じで、commitをします。

git status

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

    both modified:   App.js

今までのユーザー情報は会社用のGitLabアカウントだった。

先日GitHubで個人アカウントとリンクしようとし、別のフォルダで

$ git config --global user.name
$ git config --global user.email

と設定してしまったので、GitLabに個人アカウントが侵食されてしまっていた。

個人用GitHubアカウントで使うフォルダには

$ git config --local user.name
$ git config --local user.email

のローカルで設定した。

特定の箇所からブランチを生成('origin/develop'はコミット番号でも可)

> git checkout -b feat/#1 origin/develop

コミットを取込み

> git cherry-pick $(コミットID)

コミットを取り消し

> git reset --hard $(取り消すコミットの一つ前のコミットID) 

確認

> git log --oneline

gitで複数のユーザーを使い分ける人用サブコマンド(git author)を作った

この記事はPonos Advent Calendar 2019 3日目の記事です。
昨日は @e73ryo さんの「MonKey - Productivity Commands」のコマンド操作でUnity開発を効率化するでした。

---

初めてgitのサブコマンドを作ったので紹介します。
ちなみにRust製です。
リポジトリ
日本語ドキュメント

作った理由

gitを使っているときに複数ユーザーを使っていると git config user.nameとかgit config user.emailとか叩いて現在のユーザー情報を確認することがあると思います。
また、別のユーザーに切り替えるのを忘れてコミット何度か行い、後でログを見て気づくこともあるでしょう(ありました)。

そんな人のために
- コマンド1つでuser.nameとuser.emailを取得
- コマンド1つでuser.nameとuser.emailを設定
- 過去のコミットのauthorとcommitterを書き換える
ができるgit authorを作りました。

インストール方法

Rustをインストールしておりcargoが使える環境なら
cargo install git-authorでインストールできます。

cargoが使えない環境なら今すぐRustを始めましょう
https://www.rust-lang.org/tools/install

git authorでできること

get

git author getで user.name <user.email>の形式で取得できます。
getは省略可能です。
--local,--globalの指定ができます。

set

git author set hoge hoge@gmail.comの形式で、現在のリポジトリのユーザーをセットできます。
こちらも--local,--globalの指定ができます。

replace

過去のコミットのauthorを書き換えるコマンドです。
git author replace hoge hoge@gmail.com fuga fuga@gmail.comでauthorまたはcommitterが
hoge <hoge@gmail.com>のコミットのauthorとcommitterをすべてfuga <fuga@gmail.com>に書き換えます。
後半のfuga <fuga@gmail.com>は省略可能で、省略した場合はgit author getで取得できるauthor(現在のauthor)に書き換えます。

注意事項

言うまでもないことですが、複数人で開発しているリポジトリでreplaceを使用するときは他の人の確認をとってください。

push済みコミットを書き換えた場合は書き換えた情報をpushする時にgit push --forceと--forceオプションを書いてやる必要があります。

おわりに

使っていただけると嬉しいです。
不具合・改善案報告なども待ってます。

---

明日は@nimitsuさんのGameLift RealTimeServerで遊んでみよう for Unity（AWS設定編）です

症状

git add -pなどして「partially staged」した状態からgit commit経由でlint-stagedをすると、エラーになった。

$ git commit
husky > pre-commit (node v11.13.0)
Stashing changes... [started]
Stashing changes... [completed]
Running tasks... [started]
Running tasks for *.js [started]
eslint --fix [started]
eslint --fix [completed]
git add [started]
git add [completed]
Running tasks for *.js [completed]
Running tasks... [completed]
Updating stash... [started]
Updating stash... [completed]
Restoring local changes... [started]
Restoring local changes... [failed]
→ Command failed with exit code 128 (Unknown system error -128): git checkout-index -a
Command failed with exit code 128 (Unknown system error -128): git checkout-index -af
husky > pre-commit hook failed (add --no-verify to bypass)

これが起こると、lintが異常終了していて以下の状態になる。

• add -pして分け分けしたdiffを持つファイルが全部add状態になる
• 一部のファイルがworkdirからなくなる (たまたま作業中のファイルに当たると悲惨)

解決策

lint-staged@9.5.0で晴れて修正されているそうなので、それにアップデートする。

npm install --save lint-staged@9.5.0

参考

• ver.8以降のlint-stagedは、partially stagedなdiffだけをlintで修正しその後addし直して、コミットできるようになった。その基本アリゴリズムはこちらの通り。本投稿の症状はlint-staged@9.2.3で確認したので、「partially stagedなdiffを扱えるようになっていたがバグがあった」時期の話。
• エラーメッセージ中のgit checkout-index -afで検索をかけるとバグを報告して修正に尽力してくれた方々の記録が見れる。
• エラーメッセージ中には--no-verifyしろと書いてあるが、それをやると当然lintが通らないので回避は可能だが解決策にはならない。

この記事は Git Advent Calendar 2019 3日目の記事です。
昨日は @100 さんによる 【VRChat】継続的なクロスプラットフォーム対応 でした。

Gitコマンドハンズオン

Git初学者向けにGitハンズオンを実施しましたので、その時に作ったハンズオン資料を公開します。

Gitコマンドに慣れることが目的のハンズオンの資料ですので、Gitとは何か？といった説明はしません。ご了承ください。

お使いのPCにGitはインストール済みという前提で進めます。

文章の手順通りに進めていけば、Gitコマンドの体験ができます！

GUIツールがあるのに、なぜGitコマンドを学習するのか？

マージ・リベース・コンフリクト・・・
こういった込み入った操作をGitコマンドだけでやるのは厳しいものがあります。

基本的には、SourceTreeのようなGUIツールを使った方が、安全だと思います。

しかし、ネットワーク設定ミス等で、SourceTreeでのクローン・プッシュ・フェッチができなくなるということが、たまにあります。

そんな時に、Gitコマンドが使えると便利ですよね！

WindowsならGit Bashを使おう

Web界隈ではLinuxサーバーが主流ですので、DOSコマンドよりもLinuxコマンドが使える環境の方が、何かと都合がよいと思います。

Git for Windows をインストールしていれば、 Git Bash というターミナルがインストールされており、そこでLinuxコマンドが使えます。
また、カレントブランチ名が常に表示されたりと、Gitコマンドを使う上で何かと便利です。

今回のハンズオンでは、Git Bashを使う前提で進めます。

クローン編

練習用のリモートリポジトリを用意しよう

まずは、練習用のリモートリポジトリを用意しましょう。

今回は私の方で、GitHubに以下のリポジトリを用意しましたので、これを利用してきます。

https://github.com/segurvita/git-handson.git

ご自分でリモートリポジトリをご用意できる方は、ご自身でご用意いただいたものでも問題ありません。

作業ディレクトリを作ろう！

まずはハンズオン用のフォルダーを作成しましょう！

ここでは、

• Windows: D:\Git\GitHandson
• Mac: ~/Git/GitHandson

とします。

フォルダーが作成できましたら、ターミナルのカレントディレクトリをそのフォルダーにしてください。

リポジトリをクローンしてみよう

まずは、GitHubからリポジトリをクローンしてみましょう。

以下のコマンドを実行します。

# リポジトリをクローンする
git clone https://github.com/segurvita/git-handson.git

GitHubの認証情報が聞かれますので、ご自身のGitHubアカウントの情報を入力してくだい。

クローンに成功すると、 git-handson というフォルダーが生成されますので、中に入ります。

# 移動
cd git-handson

今後は、この git-handson フォルダーを 作業ディレクトリ と呼ぶことにします。

1人ハンズオンの場合は複数リポジトリをご用意ください

本記事は複数人でハンズオンを実施することを想定しています。

もし、一人で本記事の内容を実践する場合は、作業ディレクトリを2つ以上用意し、それぞれローカルリポジトリを作成してやってみてください。

user.name と user.email を設定しよう

職場では本名で活動するけど、OSSではハンドル名義で活動したいということがあると思います。

そういう時は、ローカルリポジトリ毎に name と email を設定すればよいです。
以下のように、 git config コマンドを実行します。

# メールアドレスを設定する
git config user.email "メールアドレス"

# 〇〇を設定する
git config user.name "ユーザー名"

ローカルブランチを作ろう

次にローカルブランチを作りましょう

# ローカルブランチを作る
git branch feature/〇〇

# チェックアウトする
git checkout feature/〇〇

〇〇 の部分は、他のユーザーとかぶらないような、好きな文字列を入力してください！

コミット編

作業ディレクトリにファイルを作ろう

作業ディレクトリに index.html を作成しましょう。

個人的には nano が便利です。（vim等、使い慣れたテキストエディターが他にあるなら、それでファイルを編集してください）

# index.htmlを作成する
nano index.html

nanoが起動したら、以下の内容を書きます。

<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8">
    <title>タイトル</title>
</head>

<body>
    本文
</body>

</html>

control + X で保存します。

以下のコマンドで中身を確認しましょう。

# index.htmlの内容を表示する
cat index.html

中身がちゃんと表示されれば成功です。

ステータスを確認しよう

ステータスを確認してみましょう。

# Gitの状態を確認する
git status

On branch feature/〇〇
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        index.html

nothing added to commit but untracked files present (use "git add" to track)

ステージに追加されていないファイルがあるよ！ というメッセージが表示されました。

ステージとはなんでしょう？

ファイルをステージに追加しよう

ステージというのは、コミットの候補となるファイル変更データを保管する場所です。

ファイルをステージに追加してみましょう。

# ファイルを追加する
git add .

. は、すべてのファイル変更データという意味です。

ステージへの追加ができたら、もう一度、Gitの状態を確認しましょう。

# Gitの状態を確認する
git status

On branch feature/〇〇
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   index.html

ステージに新しいファイルがある というメッセージになりました。

この時点ではまだ、ステージにあるだけで、コミットはされていません。

コミットしよう

追加したファイルをコミットしてみましょう。

コミットというのは、ステージに挙がっているファイル変更データを、ローカルブランチに反映させることです。

# 追加したファイルをコミットする
git commit -m "Added index.html"

[feature/〇〇 0b98e7f] Added index.html
 1 file changed, 13 insertions(+)
 create mode 100644 index.html

コミットができたら、もう一度、Gitの状態を確認してみます。

# Gitの状態を確認する
git status

On branch feature/〇〇
nothing to commit, working tree clean

コミットされたため、ステージが綺麗になりました！

コミットログを確認しよう

本当にコミットできたのでしょうか？コミットログを確認してみましょう。

# コミットログを表示する
git log

commit 0b98e7f6ae4ac2b0aaa795ce2a0c9288c94ad767 (HEAD -> feature/〇〇)
Author: 〇〇
Date:   Sun Nov 17 00:52:17 2019 +0900

    Added index.html

commit 1834144182ea422cb89b5789ad8d8a9773a58ec7 (origin/master, origin/HEAD, master)
Author: 〇〇
Date:   Sun Nov 17 00:26:03 2019 +0900

    Initial commit

ちゃんとコミットされていました！

プッシュ編

ローカルブランチをpushしよう

次は、 git push でローカルブランチを、リモートリポジトリにプッシュしてみましょう。

# ブランチをpush
git push origin feature/〇〇

この際、以下のようにGitHubの認証情報を聞かれるかもしれません。その時は、ユーザー名とパスワードを間違えずに入力しましょう。

ここで間違えてしまうと、その間違った認証情報をOSが保存してしまって結構面倒なことになります。慎重に入力しましょう。

認証に成功すれば、ローカルブランチをリモートリポジトリにアップロードできます。

コマンド内の origin というのは、リモートリポジトリのブックマークです。ブックマークというのはエイリアスのようなものです。
「エイリアスってなーに？」
「つまり、リモートリポジトリに origin って名前を付けたんだよー」

git push を実行した結果、以下のようなログが表示されます。

Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 410 bytes | 410.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'feature/〇〇' on GitHub by visiting:
remote:      https://github.com/segurvita/git-handson/pull/new/feature/〇〇
remote:
To https://github.com/segurvita/git-handson.git
 * [new branch]      feature/〇〇 -> feature/〇〇

これで、リモートリポジトリにブランチが作成されました！

ブランチ一覧を確認しよう

ブランチの一覧を確認してみましょう。

# ブランチの一覧を表示する
git branch --all

  master
* feature/〇〇
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/feature/〇〇

master ブランチのほかに、自分が作成した feature/〇〇 のブランチが表示されました。

* がついているのはカレントブランチという意味です。

なにやら remotes とついているのがいくつかありますね。これは、リモートリポジトリのブランチのように見えますが、実は微妙に違います。

たった今、ハンズオンに参加したメンバー全員がpushしたにもかかわらず、 remotes には自分がpushしたブランチしか表示されていません。
（1人ハンズオンの場合は、複数のローカルリポジトリからプッシュしておいてください。）

実は、ここに表示されているのは、リモートリポジトリのブランチそのものではなく、そのキャッシュなんです。

このキャッシュのことを リモートブランチ と呼びます。

フェッチ編

fetchしてみよう

リモートブランチを更新するには、 fetch を実行します。

# リモートブランチを更新する
git fetch

再度、ブランチ一覧を確認します。

# ブランチの一覧を表示する
git branch --all

  master
* feature/〇〇
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/feature/〇〇
  remotes/origin/feature/□□

キャッシュが更新されて、他のメンバーがプッシュしたブランチも表示されましたね！

リモートブランチをcheckoutしよう

試しに、他のメンバーが作ったブランチ feature/□□ を、チェックアウトしてみましょう。

# リモートブランチをチェックアウトする
git checkout feature/□□

上記のコマンドを実行すると、以下のメッセージが表示されます。

Switched to a new branch 'feature/□□'
Branch 'feature/□□' set up to track remote branch 'feature/□□' from 'origin'.

どうやら、新しいローカルブランチが作られたようです。ブランチ一覧を確認してみましょう。

# ブランチの一覧を表示する
git branch --all

  master
  feature/〇〇
* feature/□□
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/feature/〇〇
  remotes/origin/feature/□□

ローカルブランチとして新たに feature/□□ が増えました。
* がついているので、今度はこちらがカレントブランチになったようですね。

削除編

ローカルブランチを削除しよう

せっかく作ったローカルブランチですが、次は、このローカルブランチを削除してみましょう。

# ローカルブランチを削除する
git branch --delete feature/〇〇

削除しようとすると、こんなエラーがでました！

error: The branch 'feature/〇〇' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/〇〇'.

これは、 feature/〇〇 がどこにもマージされていないので、「このローカルブランチを消すと、コミットした情報が消えてしまうよ！」という意味の警告です。

今回は消えても問題ないので、強制的に削除しましょう。メッセージに書いてある -D を使ってみます。

# ローカルブランチを強制的に削除する
git branch -D feature/〇〇

これで削除できたかどうか確認します。

# ブランチの一覧を表示する
git branch --all

  master
* feature/□□
  remotes/origin/HEAD -> origin/master
  remotes/origin/
  remotes/origin/feature/〇〇
  remotes/origin/feature/□□

削除できてますね！

ただ、まだリモートに feature/〇〇 が残っています。

リモートリポジトリのブランチを削除しよう

最後に、リモートリポジトリのブランチを削除してみましょう。

# リモートリポジトリのブランチを削除する
git push --delete origin feature/〇〇

削除なのになぜか push コマンドが登場しました。これは、 更新 や 削除 に限らず、リモートリポジトリの内容を書き換えるときは、 push を使うんだと覚えてください。

それでは、削除できたかどうか確認します。

git branch --all

  master
* feature/□□
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/feature/□□

リモートブランチが削除されていますね！

さいごに

以上でハンズオンは終了です。おつかれさまでした。

ブランチのマージやリベース等も、Gitコマンドで実施できますが、最初に述べた通り、込み入った操作はSourceTreeのようなGUIツールでやった方が安全だと思います。
それでも、気になった方は、是非Gitコマンドでもやってみてください！

本記事作成にあたり、以下のページを参考にしました。ありがとうございました。

• Gitのリモートブランチを削除するまとめ

git push している最中にネットワークエラーとサーバーの再起動が重なってリモートリポジトリが動かなくなってしまいました。
その際にローカルのリポジトリーが最新の状態でしたので、ローカルからリモートを復旧しました。

対処方法

• リモート側に新規のリポジトリを作成。

cd リポジトリのディレクトリー(/var/test/)
mkdir new_repo.git
cd new_repo.git
git init --bare --shared

• ローカルの設定に新しいリモートリポジトリパスを追加 new とする。

[remote "new"]
    url = ssh://user_name@servername:22/var/test/new_repo.git
    fetch = +refs/heads/*:refs/remotes/new/*

• 新しいリポジトリにローカルからpush

git push new master

• マスターリポジトリの置き換え

cd /var/test/
rm -rf origin_repo.git
mv new_repo.git origin_repo.git

• ローカルの設定に新しいリモートリポジトリパス new を削除する。