VScodeでファイルのコミット毎の変更差分を見る

version 1.43で追加された機能。
直近のアップデートではデフォルトでオフになっているので設定ファイルで有効にしてあげる必要があります。※insider editionではデフォルトでオンになっています。

機能説明

機能としては以下のようになります。

エクスプローラーのTIMELINEと言うヘッダーの中身が今回追加されたtimeline機能です。
内容はコミットメッセージとコミットユーザー、コミットした日になります。
timelineにあるコミットを選択するとコミット毎の差分が見れます。
画像はadd vue componentのコミットメッセージのコミットを選択しています。
左のプレビューがadd fragment templateのコミット時のregister_post.htmlファイルの内容で、右がadd vue componentのファイルです。

設定方法

1. cmd + shift + P
2. Preferences: Open Settings(JSON)

settings.json

"timeline.showView": true

感想

普段自分はgitをCLIでしか操作していないので手軽にエディタ上で確認できてすごい捗ってます。特に誰がコミットしたファイルなのか見れて、手軽に開発者同士で会話できるのがいいと思いました。あと、どれくらいコミット期間がなかったかも見れるので、そのファイルのメンテナンス具合とかも把握できて、特にキャッチアップ期間には有効なのではないかと思いました。

GIT

GITとはファイルの変更履歴を保存できる。いちいちバックアップを取る必要がなく、削除したファイルなどを確認できる

GITの導入方法
yum install git-core→インストール
↓
git config→名前や住所を設定できる！
git init→現在の場所に.gitというリポジトリを作る
リポジトリとはファイルの変更履歴を保存できる場所

git initでリポジトリを作る。作る場所は開発アプリのディレクトリ。ちなみリポジトリは.gitとして作られるが見えないようになっているため、ls -aで見つける！

gitというリポジトリにファイルの変更保存方法
git add ファイル→ファイルを選択
↓
git commit -m '変更内容'→今選択しているファイルに対してコメントをつけてリポジトリに保存

git commitだけだと詳細な変更内容をログメッセージに書かないといけない

よく使うコマンド
git status→自分がどのファイルを変更したか。どのファイルを選択して、どのファイルを選択していないか知る、変更だけしたものが赤、インデックスに反映したものが緑になる
また今自分がどのブランチにいるか、リモートリポジトリとどれだけ差分があるかを知る

git diff→変更内容が確認できる

git log→これまでにどんなcommitがあったかを確認できる -pをつけると差分もみれる

GITの約束事項

リポジトリの内容を直接変更する事は出来ない。ワークツリーとインデックスという場所的な概念がある。ワークツリーで編集をしてインデックスに反映させて、リポジトリにに保存をする

ワークツリー→インデックス→リポジトリ

・git add(ワークツリーからインデックスに反映)
・git commit(インデックスに書かれた内容をからリポジトリに保存)

・git diff→ワークツリーとインデックスの間の差分を確認する
・git diff --cached→インデックスとリポジトリの間の差分を確認する
・git diff HEAD→ワークツリーからリポジトリの間の差分を確認する

ワークツリーでの操作間違えを元に戻す
・git checkout HEAD→ファイルの編集や削除を元に戻す、またインデックスの反映を全てサラになる

コミットを取り消したいとき
・git revert 取り消したいコミット名

・git rm 削除ファイル名→削除したファイルを選択
↓
・git commitで削除記録を保存

・git rm 既存ファイル名→既存のファイルの変更履歴をGITから消す！そしてファイルも消える！？

ブランチとは

リポジトリから出ている枝。ブランチを複数作り、最終的に一つにする事が開発する上での基本。
ブランチの中にはリポジトリの内容が全て入っている。親ブランチの名前はmaster
↓
ではなぜブランチを複数つくってから統合するような開発方法なのか
それは一つのブランチで編集していてミスったときに変更しにくいから。ブランチを新しく作ってそっちを下書きとしてから編集して、うまくいってから統合した方が怖くない！

git branch ブランチ名→新しいブランチを作る
git checkout ブランチ名→現在のブランチから指定したブランチに移動

git merge ブランチ名→現在のブランチに指定したブランチを統合する
↓
git branch -d ブランチ名→統合されれば、されたブランチは不要になるのでこれで消す

注意
mergeとcommitを間違えやすい
commitは編集内容を履歴として保存しているだけ。一つのブランチ内で起きる事。
mergeはブランチとブランチの結合。開発の基本。ブランチとブランチの間で起こる事。mergeの方が大きな単位

リポジトリのバックアップを取る方法

git --bare init→リポジトリのバックアップ作成

git remote add バックアップの名前 バックアップの場所→バックアップリポジトリに名前をつける、基本originとする

二人以上で作業をする時

自分のリポジトリを相手に反映させたり、逆をしたりしないといけない！！

git clone 複製リポジトリ名→ リポジトリの複製コピー

git push 送信先リポ 送信元ブランチ名:送信先ブランチ名
→自分のリポジトリの今までの変更内容を送信先リポに反映。ブランチ名はどちらもmasterが基本

git pull リポジトリ名 ブランチ名→指定したリポのブランチを自分のブランチに反映させる

注意
二つのユーザーが互いに同じ場所を変更して、統合させる時conflictと出る

GIThubとは

GIThubでは自分のリモートリポジトリをオンライン上におけるサービス。そのため複数開発や人が使っているコードを見る事が出来る

手順
GIThubにローカルリポジトリの入ったディレクトリ名で、リモートリポジトリを作る
↓
その場所に対してorignという名前をつける
git remote add
↓
ターミナルでローカルリポジトリの入ったディレクトリからorignに対してpushする！

やらかし

デプロイを任されたが、マージされていないことに気づかずオフィス待機状態になった話

経歴

SESのSIer。
GitBashはほぼ触ったことがなく（今日までEclipse上でpushしていた）、
一年前まではVisualStudioのTFSを使っていた。

詳細

開発ブランチの総合テスト環境へのデプロイ依頼。ユーザも使っているらしい。

まず、クローンしていない場合はクローンを行う。

git clone -b kaihatu/sogo-branch http:000/workspace.git

開発、総合テスト環境をプルして最新状態にする

git pull

ブランチの切り替えは下記の通り
例）開発用ブランチ（kaihatu_branch）をチェックアウト

git checkout kaihatu_branch

総合テスト用のブランチにマージするため、
再度、総合テスト用のチェックアウトしておく

すぐにコミットは行わず、まずマージを行う。
※このコマンドが失敗の原因

git marge --no-commit origin kaihatu_branch

競合がないことを確認出来たら、プッシュする

git push

すると以下のようなメッセージが出た

Already upto date. (すでに最新です.)

アップデート（更新）したってことね、理解した（理解してない）。
ビルドなど、デプロイ作業を行う。

しばらく後

僕「おや、リーダーにメールがたくさん届いている。リーダーは大変だなぁ」
とか思っていたら、リーダが駆けつけてきて
リーダー「お前、デプロイできてないぞ」
僕「」

原因

コミットができてなかった。

反省

まず、マージしたら差分のあることを確認する

git log -m -1 --name-status

-mはログ上でマージを普通のコミットのように扱う
-1はひとつ前のコミット分だけ表示
--name-statusは変更したファイルを表示する

ログにマージされたファイルがあることを確認したら
コミット

git commit

思ったこと

TFSに比べてGitの操作って複雑だなと。チェックイン、チェックアウトですべて事足りた時代が懐かしい。
やらかしおじさんと化して暇になったので、DockerとJavascriptの勉強を始めた。