Git submodule 参照先（コミットID）を更新する手順。

cd <submoduleディレクトリ>
git checkout <コミットID>
cd <リポジトリディレクトリ> ※ submoduleの親ディレクトリ
git add .
git commit -m "<コミットメッセージ>" 

はじめまして！
３３歳のプログラミング未経験者である私が、地元の愛知県に転職活動をしている記録を残していきたいと思います。学んでいる言語はもちろん、転職活動をしていて感じたことを書きたいなと思います。

アラサーとなった今、人口が減って経済が縮小していく日本で、どのようなキャリアを造っていくのか悩むことが多くなってきました。そして周りにも同じ悩みをもつ同世代の友人は多いです。
自分の記録が、キャリア形成について悩んでいる方々に少しでもお役に立てばいいなと思います。

自己紹介

私は、愛知県生まれ、仕事の関係で静岡県に住み一般企業(安定的企業)で事務職に就いています。
専門学校卒で特段目立ったスキルもなく、凡人サラリーマンです。

なぜ転職をしようと考えたのか

私の就いている会社は比較的安定的な企業で、周りの人にも「その会社なら、一生安泰だわ」と言われるような会社です。

ただ内部で仕事をしていると悩むことも多いのです。

例えば
基本的に仕事はルーティーン業務。過去の記録をコピペするような業務です。
言われたことをミスなく黙ってやっていればいいのです。
日々、これは自分がやらなくてもいいんじゃないかな？？と感じたり最近ではRPAという自動化システムが導入され始めて、さらに自身の存在価値が疑われるような状況になってきました。

なぜエンジニアに転職しようと考えたのか？

基本的に以下の３点です。

・手に職を付けたかったから
・ITがこれからも伸びていく産業だと思うから
・人々の生活を便利にして豊かにすることが出来ると考えたから

今回は初投稿なのでここまでとして、次回以降、なぜエンジニアになりたいかさらに掘り下げていきたいと思います！
次回は「凡人サラリーマン転職フェアに行く」をテーマに投稿したいと思います。
よかったら見てください

３３歳のプログラミング未経験者である私が、地元の愛知県に転職活動をしている記録を残していきたいと思います。学んでいる言語はもちろん、転職活動をしていて感じたことを書きたいなと思います。

２０代から現在にかけて、人口が減って経済が縮小していく日本で、どのようなキャリアを造っていくのか悩むことはとても多いです。そして周りにも同じ悩みをもつ同世代の友人は多いです。
自分の記録が、キャリア形成について、少しでもお役に立てばいいなと思います。

自己紹介

私は、愛知県生まれ、仕事の関係で静岡県に住み一般企業(安定的企業)で事務職に就いています。
専門学校卒で特段目立ったスキルもなく、凡人サラリーマンです。

なぜ転職をしようと考えたのか

私の就いている会社は比較的安定的な企業で、周りの人にも「その会社なら、一生安泰だわ」と言われるような会社です。

ただ内部で仕事をしていると悩むことも多いのです。

例えば
基本的に仕事はルーティーン業務。過去の記録をコピペするような業務です。
言われたことをミスなく黙ってやっていればいいのです。
日々、これは自分がやらなくてもいいんじゃないかな？？と感じたり最近ではRPAという自動化システムが導入され始めて、さらに自身の存在価値が疑われるような状況になってきました。

なぜエンジニアに転職しようと考えたのか？

基本的に以下の３点です。

・手に職を付けたかったから
・ITがこれからも伸びていく産業だと思うから
・人々の生活を便利にして豊かにすることが出来ると考えたから

次回は「凡人サラリーマン転職フェアに行く」をテーマに投稿したいと思います。
よかったら見てください

はじめに

個人で細々と Atom のパッケージを作って公開していました。
(現時点では、Visual Studio Codeに移行しようと思っています。)
テストデータや画像ファイルなど master ブランチには含めたくないものをどうやって管理するか悩んでいました。
merge ドライバーを使って特定のファイルを除外する方法は、設定が悪いのかもしれませんが機能しませんでした。
(衝突が起きないために merge ドライバーが呼ばれないのだと思いますが)
そこでそれ以外の方法を模索してみました。

環境

Windows 10 Pro 64bit
git version 2.27.0.windows.1

要件

管理しなければいけないデータは、以下のようなものです。

• npm(Atom)で管理できるパッケージ
  • メインコンテンツ
• 自作の共通ライブラリ
  • 別のパッケージと共通で使う自作ライブラリ(npm モジュール)
• パッケージのためのバイナリデータ
  • jpg などの画像データ
• テストのためのデータ
  • 開発中のアイデア等を書き込んでおくメモなど

このうち、テストのためのデータや画像データは、リポジトリで管理しますが公開するパッケージには含めないことにします。
バイナリデータは、常に最新の物のみ管理することにします。
履歴は要りません。
テストデータおよびメモは、履歴を管理する必要はありません。
ですが、単純にするためにテキストデータならば履歴も管理する事にします。

必要なファイルの概要は、以下のようになります。

package
  main.js
  readme.md
  ...

library
  main.js
  ...

image
  image.jpg
  ...

testData
  test1.txt
  test2.txt
  ...

todo.txt

リポジトリの構成

要件を満たすためのリポジトリ構成は、以下のようにしました。
なお、個人で開発していますので衝突が起こることは考えていません。
また、最悪リモートリポジトリを作り直すことも出来るものとしています。

• 公開用のリモートリポジトリ
  
  • リリースのための master ブランチ
  • 開発のための develop ブランチ
  • バイナリデータのための binary(image)ブランチ
  • テストデータのための testData ブランチ
• 作業用のローカルリポジトリ
  
  • master ブランチ
  • 開発のための develop ブランチ
  • バイナリデータのための binary(image)ブランチ
  • テストデータのための testData ブランチ

運用方針

• リモートリポジトリは、GitHub もしくは GitBucket を使う。

単純ですが、準備も必要なく無料で使えるからです。

• 複数のパッケージで使う自作ライブラリは、それ単体で npm パッケージとして公開する。

サブモジュールで実現しようとしましたが、Atom のパッケージマネージャがバージョンなどをうまく解決できない等の不都合がありました。
余計なことをしないで既存の便利な仕組みを使うことにします。

• バイナリデータとテストデータは独立(orphan)ブランチで管理する。

リリースするデータに含めずに Git で管理するためです。
また、バックアップの意味でリモートリポジトリに上げておきます。

• README に必要な画像データに関して、GitHub の Issue を使ったテクニックは使わない。

GitHub がサポートしているか不透明だからです。

• 場合によっては、バイナリデータは GoogleDrive などのクラウドストレージを使う。

容量などの問題で必要に応じて選択します。
もっとも、ダウンロードの仕組みの煩雑化や、一元管理できなくなるなど避けたいところです。

• バイナリデータの管理に、Git LFS を使わない。

不特定多数の人にダウンロードされる都合上、ダウンロード制限がある GitHub では使えません。
また、容量制限に関してもバイナリファイルを更新するごとに容量を圧迫します。
いちいち容量を減らすためにリポジトリから古いデータを削除するぐらいならば、LFS を使わなくても運用で何とかなります。
もともと、バイナリデータは、最新のものしか管理するつもりがないので古いデータを削除してから新しいファイルをプッシュすることにします。
これは、面倒なので改善したい点です。

• 改行コードは全て LF にする
  Windows で開発を行っていますが CRLF によるメリットは何もないので LF に統一します。

• コミットは機能単位で細かく分ける。もしくは、リリース毎に 1 つ程度にまとめてしまう。

• merge ドライバーによる除外は、使用しない

./.git/config に以下のように追記し、

./.git/config

[merge "ours"]
  driver = true

.gitattributes に

.gitattributes

.gitignore merge=ours

とする方法は、残念ながらうまく行きせんでした。
衝突が起きた時は、うまく行ったりもするのですが、基本的に自分一人で作っているので衝突が起きずにうまく行かないことの方が多いです。
そのためこの方法は諦めました。

運用に即して使うコマンドあれこれ

リポジトリの作成

master と develop ブランチの.gitignore には以下を追加しておく。

.gitignore

todo.txt
testData
image

image と testData ブランチは orphan ブランチとして作成する。

make.ps1

git init
echo "main" > main.js
echo "readme" > readme.md
git add main.js
git add readme.md
echo "todo.txt" > .gitignore
echo "image" >> .gitignore
echo "testData" >> .gitignore
git add main.js
git add readme.js
git add .gitignore
git commit -m "frist commit"
git remote add origin <URL>
git push -u origin master

git switch -c develop
echo "script" > script.js
git add script.js
git commit -m "first develop"
git push -u origin develop

git switch --orphan image
git rm -rf .
echo "todo.txt" > .gitignore
echo "testData" >> .gitignore
git add .gitignore
mkdir image
echo "image" > image/image.jpg
git add image
git commit -m "first on image"
git push -u origin image

git switch --orphan testData
git rm -rf .
echo "image" >> .gitignore
git add .gitignore
mkdir testData
echo "01" > testData/01.txt
echo "02" > testData/02.txt
git add testData
echo "todo" > todo.txt
git add todo.txt
git commit -m "first on testData"
git push -u origin testData

git switch master

powershell で実行すると改行コードが CRLF になってしまいますが、実際には LF でのみ作成します。

画像データのリンクについて

README などから画像データにアクセルする場合のリンクの指定方法は以下のようになります。

1. GitHub のリポジトリにあるファイルの場合、以下のようにすれば参照できる。 https://raw.githubusercontent.com/UserName/RepositoryName/BranchName/FileName
2. GoogleDrive に保存した場合、以下のようにすれば参照できる。
   1. 共有リンクを取得する https://drive.google.com/open?id=ID
   2. そして以下の形式に変更して記述する http://drive.google.com/uc?export=view&id=ID
3. DropBox に保存した場合、以下のようにすれば参照できる。
   1. 共有リンクを取得する https://www.dropbox.com/s/FileName?dl=0
   2. そして以下の形式に変更して記述する https://www.dropbox.com/s/FileName?raw=1

バイナリファイルを消すときに使うコマンド

履歴からPATH-TO-DATAで示されるファイルを全て削除する。
全てのブランチから削除したいならば最後に--allを付ける。
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch PATH-TO-DATA' --prune-empty --tag-name-filter cat
フォルダの場合は、以下になる。
git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch PATH-TO-DATA' --prune-empty --tag-name-filter cat

削除結果をリモートに反映させる。
こちらも全てのブランチから削除したならば最後に--allを付ける。
git push origin --force
タグがある場合は、以下も行う。
git push origin --force --tags

refs/original フォルダに保存されているオブジェクトを削除する。
git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin

reflog を削除する。
git reflog expire --expire=now --all
ファイルを消した履歴とそれにアクセス出来そうな履歴だけを削除したいならば以下を使って個別に消す。
もっとも十分な知識がないと整合性が取れなくなる恐れがある。
git reflog delete refs

到達不能オブジェクトの削除と最適化
git gc --prune=now
もしくは、
git gc --prune=now --agressive

testData ブランチのファイルへのアクセス

ファイルを取ってくる場合は、以下のように行う。

git restore --source=testData testData
git restore --staged testData

テストデータを更新したい場合は、testData ブランチへ切り替えてから行う。

最後に

まだまだ決して使いやすいものになっていません。
色々と改善していきたいものです。
そもそも、orphan ブランチを別リポジトリにしてしまうのも 1 つの方法のようですが。

Git が油汚れでギットギットになってからでは遅いんです。(`・ω・´)

GitHubのリポジトリ名を変更後に、pushしたら下記のようなメッセージが出ました。

Terminal

$ git push origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: This repository moved. Please use the new location:
remote:   https://github.com/tetsu-upstr/JSblog.git
To https://github.com/tetsu-upstr/blog.git
   7468063..962d5cd  master -> master

リポジトリが動いたから、新しい場所（URL）を設定してねって書いてあります。

Terminal

This repository moved. Please use the new location:

解決方法

現在のURL設定を確認します。

Terminal

git remote -v

下記のように表示されました。

Terminal

origin  https://github.com/tetsu-upstr/blog.git (fetch)
origin  https://github.com/tetsu-upstr/blog.git (push)

正しいURLを指定します。

Terminal

$ git remote set-url origin https://github.com/tetsu-upstr/JSblog.git

再度確認してみると、変更されているのがわかります。

Terminal

$ git remote -v
origin  https://github.com/tetsu-upstr/JSblog.git (fetch)
origin  https://github.com/tetsu-upstr/JSblog.git (push)

Gitって難しいよね

こんにちは @ykhirao です！！フリーランスエンジニア初めて2週間立ちましたが、案件に入って初めてやったことは開発ではなくGit/GitHubを導入でした。いまWinSCP/TeraTermからGitベースのデプロイ環境を構築しようと思って、改めてGitに関して調べ直していました。

その知見を書いていく。

基本的にはここ https://git-scm.com/book/ja/v2/Gitサーバー-プロトコル の4章の内容を中心に書いていこうかと思います。

Git標準でついているGitWebを立ち上げてみたり

GitHubとか使うんではなくてbareレポジトリというものをGCPのVPSに置いてみたり

そんな感じのQiitaです。暇があったらGitサーバーってなんじゃらほいって自分でも調べてみてください。私にはよくわからなかったです。たぶんGitのbareレポジトリ(つまり.git/ディレクトリ)をホストしているだけのサーバーのこと…

最初Gitサーバーって何言ってるのかと思った

Gitサーバーって何？パルプンテ状態でした。

Git on the Server

って書かれているので、サーバーにGit入れる話で、誤訳なのかなって思ったけど

https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key

で

Many Git servers ... 

って書かれているので、誤訳じゃなくて普通に使われている言葉っぽいなあと思い、一旦言葉じりについては納得した。

yk@yk ~ % git --version
git version 2.25.0

Gitって川の流れに例えるとわかりやすいよね（異論は受け付ける）

Gitのプロトコルには主に

1. Local プロトコル
2. HTTP/S プロトコル
3. SSH プロトコル

があるみたい。この中のLocalプロトコルは使ったことなかったのでとても新鮮味を感じた。

適当なレポジトリをダウンロードしてくる

とりあえず https://github.com/explore から自分にあったいい感じの軽そうなレポジトリを取ってくる。

https://github.com/denoland が 出てきたので一番コミット数少なそうな https://github.com/denoland/ninja_gn_binaries を選んで見る。

# GitHubから適当なレポジトリをクローンしてくる
$ git clone https://github.com/denoland/ninja_gn_binaries

Cloning into 'ninja_gn_binaries'...
(ry)


# プロジェクト名.git というフォルダ名をつけて bareレポジトリというのを作成する
$ git clone --bare ninja_gn_binaries ninja_gn_binaries.git

# bareレポジトリに移動
$ cd ninja_gn_binaries.git

# git操作に反応するhooksをサンプルを使用できる形に
$ mv hooks/post-update.sample hooks/post-update

# 全ユーザーに実行権限付与
$ chmod a+x hooks/post-update

いい感じにローカルプロトコルの準備ができました。
今回は普通の場所 /Users/yk/workspace/ninja_gn_binaries.git に作りましたが、同じネットワーク内の共有ファイルシステム内においたりすると、ネットワーク内からpull/pushなどのアクセスができるっぽいです。

$ pwd
/Users/yk/workspace/ninja_gn_binaries

# remoteの設定をしよう
$ git remote add local /Users/yk/workspace/ninja_gn_binaries.git

# この場合
# git push local master
# みたいにアクセスできるようになる

vim .git/config

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = https://github.com/denoland/ninja_gn_binaries
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[remote "local"]
        url = /Users/yk/workspace/ninja_gn_binaries.git
        fetch = +refs/heads/*:refs/remotes/local/*

いい感じに設定できてますね。 origin は https://github.com/denoland/ninja_gn_binaries に設定されているので git push origin master は他人のレポジトリなので権限的にエラーがでると思います。 git push local master なら自分のPC内なのでいい感じにpushできるはず。

$ pwd
/Users/yk/workspace/ninja_gn_binaries

$ touch README.md
$ git add .
$ git commit -m "Create readme"
[master db503c6] Create readme
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

$ git log
commit db503c617db3b9f8ce88c8c1f6afc9a71d4675f8 (HEAD -> master, local/master)
Author: Yuki <yuki.dees39th@gmail.com>
Date:   Thu Jul 9 00:31:45 2020 +0900

    Create readme

commit 50abf78bdabe66518865e3b9fdfaaade87bcfded (tag: 20200506, origin/master, origin/HEAD)
Author: Bert Belder <bertbelder@gmail.com>
Date:   Wed May 6 01:41:43 2020 +0200

    Update gn to git revision 5ed3c9cc

いい感じに local/master にpushできました！
このremoteのブランチを別のファイルにcloneしてきましょう！

$ pwd
/Users/yk/workspace

$ git clone /Users/yk/workspace/ninja_gn_binaries.git second-clone-sample
Cloning into 'second-clone-sample'...
done.

$ ll | grep second-clone-sample
drwxr-xr-x   7 yk  staff   224  7  9 00:37 second-clone-sample

$ cd second-clone-sample

$ git log
commit db503c617db3b9f8ce88c8c1f6afc9a71d4675f8 (HEAD -> master, origin/master, origin/HEAD)
Author: Yuki <yuki.dees39th@gmail.com>
Date:   Thu Jul 9 00:31:45 2020 +0900

    Create readme

commit 50abf78bdabe66518865e3b9fdfaaade87bcfded (tag: 20200506)
Author: Bert Belder <bertbelder@gmail.com>
Date:   Wed May 6 01:41:43 2020 +0200

    Update gn to git revision 5ed3c9cc

別のフォルダにcloneしてくることができました。

1. Local プロトコル

の話が終わったのですが、

1. HTTP/S プロトコル
2. SSH プロトコル

は簡単で

# HTTP/S プロトコル
git clone https://github.com/denoland/ninja_gn_binaries.git
# 仮にプライベートレポジトリの場合、この段階でID/Passwordが聞かれる


# SSH プロトコル
git@github.com:denoland/ninja_gn_binaries.git
# 公開鍵を登録していると使えて
# プライベートレポジトリでもID/Passの入力なしで使える

いつも見ているあれです！GitHubのここ

bareレポジトリの本質的なものは、 git init したときに作られる .git フォルダだけを管理しているレポジトリみたいです。[https://git-scm.com/book/ja/v2/Gitサーバー-サーバー用の-Git-の取得]

$ mkdir sample

$ cd sample

$ ls

$ ll
total 0
drwxr-xr-x   2 yk  staff   64  7  9 00:49 .
drwxr-xr-x  10 yk  staff  320  7  9 00:49 ..

$ git init
Initialized empty Git repository in /Users/yk/workspace/sample/.git/

$ ll
total 0
drwxr-xr-x   3 yk  staff   96  7  9 00:49 .
drwxr-xr-x  10 yk  staff  320  7  9 00:49 ..
drwxr-xr-x   9 yk  staff  288  7  9 00:49 .git

このlocalプロトコルを作成したときの bare というファイルの実態を持たないものがいわゆる世間で言われる Gitサーバー で、世の中にGitサーバーを構築してGit管理したいって思っている人たちの選択肢は次の3つくらいだと思っている。

1. GitHub/GitLab/その他ホスティングサービスを使う
2. 同じサーバー上の別の階層にbareレポジトリを置く
3. 別のサーバー上にbareレポジトリを置く

特に「社内でセキュリティが…」って理由がない限りは「マイクロソフトが買収した設計図サイトです！」と上司を説得してGitHubをbareレポジトリの代わりにする方向が一番きれいかなと思いました。イシュートラッカーとかカンバンとかプルリクエストとか使えるし、便利かなと

ついに始まるサーバにGit入れてみるサーバー構築編

ここみてGCPの無料VPSをたちあげた
https://22musyoku.tokyo/gce-always-free/

公開鍵を登録したら、こんな感じでSSHできる。

yk@yk sample % ssh 3X.1XX.XX.45

(yes)

Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-1019-gcp x86_64)

(ryaku)

yk@lwaysfree-micro:~$

GCP-Ubuntu20.04だとgitが入ってなかったので適当にいれる。

$ git
-bash: git: command not found
$ sudo apt update
$ sudo apt upgrade
$ git --version
git version 2.25.1

projectのbareレポを作る

$ sudo mkdir /opt/git
$ sudo mkdir /opt/git/project.git
$ cd /opt/git/project.git
$ sudo git init --bare
Initialized empty Git repository in /opt/git/project.git/

ローカルPCでいろいろごりごり

$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)
$ touch README.md
$ git add .
$ git commit -m "INIT"
[master (root-commit) 909289c] INIT
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md
$

# リモートの設定する
# ykとIPアドレスの部分は適宜変えて
$ git remote add origin yk@34.105.XX.XX:/opt/git/project.git
$ git push origin master

% git push origin master

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 213 bytes | 213.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
error: remote unpack failed: unable to create temporary object directory
To 34.105.93.45:/opt/git/project.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'yk@34.105.93.45:/opt/git/project.git'

書き込みのエラーが出たので一旦ユーザー所有者にする

yk@lwaysfree-micro:/opt/git$ sudo chown yk project.git/ -R
yk@lwaysfree-micro:/opt/git$ ll
total 12
drwxr-xr-x 3 root root 4096 Jul  8 16:11 ./
drwxr-xr-x 3 root root 4096 Jul  8 16:10 ../
drwxr-xr-x 7 yk   root 4096 Jul  8 16:34 project.git/

OKそう。push成功！

% git push origin master

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 213 bytes | 213.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To 34.105.93.45:/opt/git/project.git
 * [new branch]      master -> master

localにクローンしてくることもできます！いい感じですね。
これが噂のGit用だけのGitサーバーか…

$ git clone yk@34.105.XX.XX:/opt/git/project.git sample-clone
Cloning into 'sample-clone'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

$ cd sample-clone

y$ git log
commit 909289c7a8057ec6fcb207da70684e9daa81e39e (HEAD -> master, origin/master, origin/HEAD)
Author: Yuki <yuki.dees39th@gmail.com>
Date:   Thu Jul 9 01:22:46 2020 +0900

4.10 Gitサーバー - まとめ に書かれていますが

自前でサーバーを構築すれば、多くのことを制御できるようになり、ファイアウォールの内側でもサーバーを実行することができます。 しかし、サーバーを構築して運用するにはそれなりの手間がかかります。ホスティングサービスを使えば、サーバーの準備や保守は簡単になります。 しかし、他人のサーバー上に自分のコードを置き続けなければなりません。組織によってはそんなことを許可していないかもしれません。

可能ならGitHubとか使いましょう〜

GitWeb立ち上げてみる

4.7 Gitサーバー - GitWeb

簡単にGitのなにそれをWebで見えるいい感じのサーバーが立ち上げられます。(macだとrubyが入っているので)

yk@yk workspace % mkdir sample
yk@yk workspace % cd sample 
yk@yk sample % git init 
Initialized empty Git repository in /Users/yk/workspace/sample/.git/
yk@yk sample % touch README.md
yk@yk sample % git add README.md 
yk@yk sample % git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   README.md

yk@yk sample % git commit -m "INIT"
[master (root-commit) 290565d] INIT
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md
yk@yk sample % git instaweb --httpd=webrick --stop
yk@yk sample % git instaweb --httpd=webrick       
yk@yk sample % 

# http://127.0.0.1:1234/ が立ち上がります！！！！！

# 必要なくなったら落とす
yk@yk sample % git instaweb --httpd=webrick --stop

これでSource Treeとか必要ないですね！！！！！（極論）

正直TIGとかのほうが好きだと思ってしまったのはここだけの話。

4.8 Gitサーバー - GitLab でGitWeb使うくらいならGitLab使おうぜ…OSSだし。みたいな雰囲気が醸し出されています。

結論Gitサーバーって何?

調べてもよくわからなかった。

Gitだけのために用意している、踏み台サーバー的な存在のことを Gitサーバー って呼んでいるのかと思った。
bareレポジトリをホストするだけならわざわざサーバーを建てずに、プロジェクトと同じサーバーの別の階層におけばいいのでは、と思いました。（感想）

.

内容

git-secretsリポジトリ内の
git-secrets
git-secrets.1
の2つのファイルを
C:\Program Files\Git\ユーザ名\bin
へコピーすることでインストールできる。

補足

公式のやり方でインストールしてもgit secretsなんてないよと言われて使えない。

$ ./install.ps1
$ git secrets
git: 'secrets' is not a git command. See 'git --help'

かなしい。