個人的にTortoiseGitはWindows環境では最高のGitフロントエンドだと思ってます。

偶にTortoiseGitの設定を手動でする現場があるのでメモ

WinMerge

みんな大好きWinMerge。Gitのマージがクソとかか言ってる人はこいつをマージツールに使うのやめましょう！個人的にはVSCodeがおすすめ！

Diff

WinMergeU.exe /e /u /wl

Merge

恐らくいつもの構成。%baseは分岐前、%theirsはリモート、%mineはローカルに%theirsをWinMergeが自動マージしたもの。%mergedなんてなかったんや?

WinMergeU.exe /e /u /wl /wm %base %theirs %mine

おまけ

一応マージファイルだけも見れるっぽいけど試したことないのでどうなるのかは知らないやつ！

WinMergeU.exe %merged

コマンドラインオプション

何かいっぱいあるのでカスタマイズしたい人は公式のヘルプを見よう！

VSCode

個人的に一番使いやすいので大好きなやつ。但しブランチ切り替える時にVSCodeがロックしてるファイルのチェックアウトにしくじることが…?

Merge

%mergedファイルを直に見るだけ

Code.exe %merged

Githubの基本的な使い方が理解できたのでまとめていこうと思います。

リポジトリとは

リポジトリとは「貯蔵庫」という意味で、過去のもの含め、一連のファイルが保存されている場所のことを言います。
よく聞くワードとしては「リモートリポジトリ」と「ローカルリポジトリ」という言葉ですが、これはどこの貯蔵庫を指しているかという話です。
リモートリポジトリとはネットワーク上にあるリポジトリで、ローカルリポジトリが自分のPCにあるリポジトリを指します。
複数人で作業するときは、共通の「リモートリポジトリ」が1つあり、ローカルリポジトリが人数分あるイメージになります。

フォークとは

フォークとは「分岐」という意味があります。
誰かのリポジトリを「分岐」して自分のリモートリポジトリに追加することをフォークと呼びます。
通常、誰かのリポジトリをそのまま操作することはなく、リモートリポジトリにフォークして、操作していきます。

クローンとは

クローンとは、自分のローカルリポジトリにリモートリポジトリのデータをコピーしてくることを言います。
リモートリポジトリとローカルリポジトリは一緒に動くことが求められる（貢献することが求められる）ので、フォークではなく「クローン」という言い方になります。
フォークしてきた誰かのリポジトリをクローンすることで、ローカルリポジトリでファイルを操作することが可能になります。

コミットとは

コミットとは、開発の中で新しいバージョンを作成することをいいます。
開発では連続して新しいコードを書いていくわけですが、その中のきりが良いところで新しいバージョンとしてコミットしておくと、
新しいバージョンができ、例えばそこに戻ってコードを書いたり差分を比べたりすることができるようになります。
コミットは保存しただけでは行われず、一度「ステージングエリア」に上げた後、コミットメッセージと一緒にコミットすることで行うことができます。

ブランチとは

ブランチとは、作っているメインの開発から「枝分かれ」を作って、コミットを作ることをいいます。
デバッグや新規機能の開発など、メインのブランチ（masterブランチ）から離れたところで作業する必要がある場合にブランチを作成します。

マージとは

マージとは、作ったブランチを他のブランチに統合することを言います。
開発として先に勧めていくブランチの場合は、マージしていくことになります。

プッシュとは

プッシュとは、ローカルで作成したデータをリモートリポジトリにだしていく事を言います。
プッシュすることで、オンライン上に自分の変更をアップロードすることができます。
しかし、それを勝手にしていると、みんなが書いた好き勝手なコードがリモートリポジトリに並ぶことになります。
それを防ぐために、プルリクエストがあります。

プルとは

プルとは、リモートリポジトリの変更をローカルに反映させることを言います。
ローカルの開発環境は、リモートと同じでなければなりません（クローン）。
そのため、プッシュする際、もし最新版がリモートリポジトリに上がっていれば、一度プルしてから、プッシュすることとなります。

プルリクエストとは

プルリクエストとは、プッシュする前に第三者の承認を挟むことを言います。
「プル」してもらうためのリクエストなので、プルリクエストです。

また一つ学びました。

文言修正などのたびにgitでマージしてデプロイするのがきついのでスクリプトで簡単にする話になります。

いままで

ステージングブランチにfeatureブランチをマージしてデプロイする流れで説明します。
大抵は下記の流れになるかと思います

git checkout staging
git pull
git merge featureブランチ
git push
デプロイスクリプト実行など（CIが自動でやる場合は省略）

たかだか文言修正のためにコマンド5回実行は面倒ですよね。

改善後

下記スクリプトをコピペかスクリプトファイルにして１発実行できます。
適用したいfeatureブランチにいる状態で実行して下さい。

current_branch=`git symbolic-ref --short HEAD`
if [ ! $current_branch = "staging" ] && [ ! $current_branch = "master" ]; then
  true
else
  echo 'error. staging, master branch'
  false
fi && git checkout staging &&
git pull &&
git merge --no-edit $current_branch &&
git push &&
bundle exec cap staging deploy && # （ここは任意のデプロイスクリプトに置き換えてください）
# featureブランチに戻る場合
git checkout $current_branch

間違ってmasterやstagingブランチにいる状態でマージしないように最初にチェックしています（一度やらかしたので。。改善点です）

シェルスクリプトmemo

&&で前回実行のコマンドの終了ステータス$?が成功(0)の場合のみ続けて実行されるのを利用し途中失敗しても安全にしたつもりです。
ちなみに途中でコメントはさんでも&&が正しく機能しました。下記のechoは実行されません。

false && 
# コメントテスト
echo 'test'

trueコマンドとfalseコマンドは地味に使えますね。
if分の中でメイン処理書きたくなかったのでこの形にしました。
fiのあとに&&で実行判断するのに終了ステータス書き換えたいなーと悩んでたらそういえばあったなと。

環境

Mac Mojave 標準bash

つぶやき

各位秘蔵のマージ＆デプロイスクリプトあると思うのですが、ググってもうまく見つかなかったので書いてみました。
（シェル芸人の人たちにとっては書くほどでもないのかもしれない。。）

（IT業界における）新型コロナウィルス対策（案）個人編
https://qiita.com/kaizen_nagoya/items/f6996fe6d49ee6095d61

に対応した組織編です。

個人による新型コロナウィルス対策の周知

医療関係者を含め、自分を守ることが最大の課題。
IT業界であっても、医療関係の業務もあれば、自衛隊・警察・消防の仕事もある。
ありとあらゆる情報を扱っている。感染症に関する情報も。

1 手洗い前の素手で直接、口、鼻、目を触らない。
2 手洗い
3 咳・くしゃみ時推奨習慣
4 健康管理（免疫力・抵抗力の保持）
を周知

1 手洗い前の素手で直接、口、鼻、目を触らない。

感染症の伝達は、菌が手を介して、口、鼻、耳から体内に入る可能性があるから。

マスクをする理由の一つでもある。

手洗いが必要な理由の一つでもある。

　2 手洗い

出勤時、昼食前、昼食後、退勤時の４度は最低限。
用便の際に前後で手洗いを推奨するかどうか、組織で判断。

　3 咳・くしゃみ時推奨習慣

マスクをする理由の一つでもある。

4 健康管理（免疫力・抵抗力の保持）

免疫力、抵抗力が強ければ、感染しても重症化しないかもしれない。

手洗い場の確保

空間

建築系の法規で、何人いる場合に、手洗い場の大きさ、種類などについて推奨がある。

時間

朝の出勤時の手洗いを励行しようとしても、人数分手洗い場が確保できない場合は、
出勤時間をばらけさせるとよいかもしれない。昼休みの始まり、終わりにも手洗いを励行する。

手洗い時間は、事業の継続性にとっては業務時間と見做すのが妥当かもしれない。

清掃

共用の机などは、水拭きだけでなく、アルコール消毒なども励行するとよい。

旅館などの生活衛生関係営業におけるSARS感染防止対策のための自主管理マニュアル
http://www.seiei.or.jp/db-pdf/sars_01.pdf

• トイレの流水レバー、便座、フタは、台所用合成 洗剤の希釈液に浸した雑巾で二度拭きする。
• 便器の内側は、台所用合成洗剤の希釈液を用 いて、トイレ清掃用のブラシ(スポンジブラシなど) で周囲に飛び散らないように清掃し、フタをして5 分以上経過してからフタをしたままフラッシュする。 なお、使用したブラシは台所用合成洗剤の希釈液又はやや濃いめの希釈液の中に5分以上漬けておく。
• 体液や汚物によって汚れたモノの消毒 体液や汚物によって汚れた部分は、台所用合成洗 剤の希釈液、あるいはこれに十分浸したティッシュペー パーなどで汚染されたところを覆い、5分以上経過し てから、から拭きする。
• 利用客が触れた可能性のあるモノの消毒 ドアノブ、エレベーターの押しボタン、エスカレータ ーや階段の手摺りなどは、台所用合成洗剤の希釈液 に浸した雑巾で二度拭きする。

作業上の留意

- 作業開始前
清掃従業員等は作業前に必要に応じてサージカルマスクなどの感染防御可能なマスク(以下 「感染防御マスク」という。)やゴム手袋、ゴーグル、使い捨てガウン、エプロン、汚染除去可能な履物で個人防御をすること。
- 作業終了後
○ 清掃・消毒終了後は、石鹸による手指の手洗いや速乾性皮膚消毒剤(エタノール等)を用いた手指の消毒を行うとともに、うがいを励行すること。
○ 使用後の感染防御マスク等は、回収されたゴミ等と一緒にビニール袋で密閉し焼却等適正な方法で廃棄すること。

健康管理

通勤時間等拘束時間の削減のため在宅勤務を可能にする。

混雑した通勤時間を避けるため、フレックスタイムを可能にする。

食事時間を近隣とずらして、混雑した食事を避ける。

遠隔業務

github/gitlab/bitbucket

git系のサービスで、private接続可能な範囲設定をどのようにするかは、ネットワーク管理者とご相談ください。

個々の企業での、ネットワーク接続方法は、千差万別で、どうしたらいいか、一般論では妙案がありません。

cloud

amazon, google, microsoftなどのcloud利用について、組織外かrの接続については、ネットワーク管理者と各接続サービス会社とご協議ください。

Office 365等

Office 365, Teams など、ID, Password管理している場合に、管理方法

docker等

cloudサービスとの連携など、ネットワーク管理者と各接続サービス会社とご協議ください。

テレビ会議

skype

https://www.skype.com/ja/features/calling-and-instant-messaging/#calls

使用するデバイスに関係なく最大 50 名 (自分に加えて 49 名) が参加できる 電話会議またはビデオ会議を開催できます。

teams

Microsoft Teams
Office 365 でチームワークを実現するハブ
https://products.office.com/ja-jp/microsoft-teams/group-chat-software

webEX

https://www.cisco.com/c/m/ja_jp/solutions/webex.html

zoom

https://zoom.us/jp-jp/meetings.html

行事の遠隔開催

あらかじめ遠隔開催を想定していた事業であれば、
講師の方と綿密な著作権上の取り決めをしておくことができる。

集合開催を遠隔開催に変更する場合には、
講師の方と著作権を含めて、交渉事項が多岐に渡る。

　講師の登壇条件区分（案）
講師の所属組織、講師個人の判断を尊重し、下記の区分に回答をもらう。

直接登壇またはオンライン登壇の別。（直接・オンライン（動画・音声・文字））
・オンライン登壇の場合の動画の記録の可否。（可・否）
・動画でのインタネットへの配信の可否。（可・否）
・・動画の再上映（インタネットを覗く）の可否。可の場合は再上映回数。（可（　回）・否）
動画の再上映可の場合でも、再上映日程、場所については事前にご相談いたします。

行事開催時の注意事項（新型コロナウイルス・インフルエンザ等流行時を含む）
https://qiita.com/kaizen_nagoya/items/92fe0b8076111a3c1bc4

文書履歴(document history)

ver. 0.01 初稿 20200220 午後４時
ver. 0.02 行事追記 20200220 午後５時

事象

GitHubにリポジトリは作成されているのに、git pull origin masterしたら以下のようになる。

$ git pull origin master
fatal: Couldn't find remote ref master

原因

まだGitHubのリポジトリ上に一つもファイルを作成していないため、masterブランチが作成されていなかった。

解決

一度pushした後なら、正常にpullできるようになった。

$ git push origin master
Counting objects: 8, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 3.02 KiB | 1.51 MiB/s, done.
Total 8 (delta 0), reused 0 (delta 0)
To https://github.com/r-wakatsuki/hoge.git
 * [new branch]      master -> master
$ git pull origin master
From https://github.com/r-wakatsuki/hoge
 * branch            master     -> FETCH_HEAD
Already up-to-date.

以上

今回新たにアプリケーションを作ることとなった為、専用のフォルダを新規作成しましたが、何故かソース管理に大量の未ステージングの変更が入っていました。
少し見にくいかもしれませんが、新規で作ったばかりでまだGitHubのリポジトリにも連携していないにも関わらず、以下のキャプチャのように別のフォルダの変更が管理されていました。

原因と対処

原因はかなり単純なもので、作成したフォルダの一つ上のディレクトリに.gitフォルダ（隠しフォルダ）が作成されていたことが原因でした。
.gitフォルダが格納されている所よりも下の全ての階層の変更が管理出来ている状態となっていたようです。
このフォルダを削除し、作ったフォルダのソース管理を更新すると、「ソース管理プロパイダが登録されていません。」と初期表示が無事表れました。

.gitフォルダが作られてしまった理由

おそらくですが、以前別のリポジトリを作った際に、誤ってフォルダ全体を格納している所でgit initコマンドを打ってしまったからではないかと考えています。
調べた限り、他の原因が思い当たりませんでしたが、別の理由が判明次第、追記していきたいと思います。

参考文献

・from44 VSCode のソース管理で変更が5000と表示されたときの対処法
https://from44.net/vscode-git-5k/