node_modulesなどはgitにcommit、pushする必要はない

node.jsの開発において、

npm install --save [library name]

でインストールしたバッケージは、package.jsonのdependenciesにて依存関係が定義されている。

{
  "name": "project-name",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "cheerio": "^1.0.0-rc.3",
    "puppeteer": "^1.19.0",
    "request": "^2.88.0",
    "request-promise": "^4.2.4"
  }
}

npm installを実行すれば、package.jsonの依存関係を参照して必要なライブラリがダウンロードされる。
したがって、ライブラリの実体が保存されているnode_modulesを含める必要がない。
プロジェクトの容量が無駄に大きくなってしまうので、.gitignoreファイルでcommit対象から外して管理するのがいい。

.gitignoreファイルの作成

.gitignoreの作成は、通常のファイル作成と同様に

touch .gitignore

で作られる。
ファイルは、ワーキングディレクトリ直下(プロジェクトの最上位のディレクトリ)に作成する。
.gitディレクトリに置くと読み込まれないので注意。

.gitignoreの記述方法

下記のように記述できる。

# ディレクトリを指定する場合
node_modules/

# ファイルのパターン一致でコンパイルなどで生成したファイルを指定する場合
*.com
*.class
*.dll
*.exe
*.o
*.so

ディレクトリの場合はディレクトリ/で指定でき、
ファイルの場合は正規表現で指定できる。

設定後、実際にcommitしてみて確認

.gitignoreを設定後、commitすると

$ git add *
The following paths are ignored by one of your .gitignore files:
node_modules

のように除外されたパスが表示される。
意図通り除外されているか確認出来る。

参考書籍

GitHub実践入門
弊社での新卒エンジニア向け課題図書になった。
必要なコマンドを随時調べるのも良いけど、最初に一通り理解して置くとスムーズにいく。

概要

皆さんVSCode使ってますか？TypeScriptやPythonなど複数の言語を使う場合に、一つのエディタで完結できる、VSCodeはとっても便利です。VSCodeには様々な拡張機能があるのですが、今回はGitを便利に使うためのTipsについて紹介したいと思います。

この記事を読めば、VSCodeでGit管理を完結することが出来るかと思います。今回はサンプルとしてVue.jsの公式リポジトリを使用します。開発者の方、ありがとうございます。
では、始めましょう＼(^o^)／

前提条件

Mac環境のVSCodeを想定しています。
(Windowsでも基本的には変わらないかと、、、)
また、下記のプラグインの追加をお願いします。

• GitLens
• Git History

Gitの基本操作

VSCodeでのGit操作は、まず左のメニュー（？）から、ソース管理(図内の赤枠のアイコン)を選択します。
「3」のアイコンがついているのは、3つのファイルに変更があるよ、という意味です。
最新バージョン(2019年8月11日時点)なので、アイコンが異なる可能性があります。

すると、下記画像のようになるかと思います。
「STAGED CHANGES」に２つのファイル(README.mdとBACKERS.md)、「CHANGES」に一つのファイル(error-detector.js)があることが分かります。
では、このerror-detector.jsをクリックしてみましょう。

すると下記画像のようにファイルのどの部分を変更したのかが、非常に分かりやすく表示されます。

ちなみに、右上にある矢印をクリックすると、「次の変更」、「前の変更」に移動することが可能です。

また、ファイルの変更箇所については、右側にあるバーを見ることで確認できます。
下記画像では、5件の追加(緑色)と、4件の削除(赤色)が行われていることが分かります。

ステージング、アンステージング

次に、ステージング、アンステージングをVSCodeで試してみましょう。
ファイル名の上にカーソルを持っていくかファイルを選択すると、下記画像のようなアイコンが表示されます。
左から、「ファイルを開く」、「変更をステージ」、「変更を破棄」となっています。
今回は真ん中のプラスボタンである変更をステージをクリックしてみましょう。

すると、下記画像のように、error-detector.jsがSTAGED CHANGESに移動して、ステージされたことが分かります。

先ほどと同様にファイル名を選択すると、下記画像のようにアイコンが２つ表示されます。
左から、「ファイルを開く」、「変更のステージングを解除」となっています。
アンステージするために、マイナスのアイコンをクリックします。

すると、下記画像のようにアンステージされたことが分かります。

コミット

コミットは、下記画像のようにコミットメッセージを入力した後、Command+Enterか、チェックマークをクリックします。

その他の操作

下記画像のように三点リーダーをクリックします。
すると、いろいろな選択肢が表示されますので、使いたいものを選択して下さい。
プッシュやスタッシュはよく使う機能かと思います。

Git応用編

ここからは使用頻度は少ないですが、いざというときに役に立つTipsを紹介します。

この行の変更者は誰？

チーム開発していると、このコードの意味がわからないけど、誰に聞いたら良いのか分からない。
この部分を実装した人を知りたい、ということがよくあります。
そのときに、便利なテクニックです。

まず、左のメニューからエクスプローラー(下図の赤枠)を選択して下さい。

右上にあるGitのアイコン(赤枠)をクリックして下さい。
(Gitのアイコンが２つありますが、マウスオーバーした時に、「Toggle File Blame Annatations」と表示される方を選択して下さい。)

すると、その行に対するコミットの対応が表示されます。

試しに、一つコミットを選択してみましょう。
選択すると、下記画像のようになります。
Jasonさんが、8ヶ月前に変更した行がハイライトされて表示されます。

また、いちいちボタンを押して、コミットの対応を表示するのがめんどくさい、という方は、
ソースコードの右側に表示されるコメントの部分にマウスカーソルを置くだけで、どのコミットの変更かを表示させることが可能です。
下記画像の赤枠部分にカーソルを持っていくと、ポップアップでどのコミットで変更されたのかが表示されます。
8ヶ月前のb31alaaのコミットでの変更だということが分かります。

ちなみに、コードの右側に表示されるコミットの情報を非表示にしたい場合は、下記画像のように「Toggle Line Blame Annotations」を押すと、表示と非表示を切り替えることが出来ます。

このファイルの変更履歴を見たい

あるファイルがどのタイミングでどの様な変更が行われたのかを知りたいこともよくあります。
機能追加のコミットが複数に分かれていた場合、変更のあったコミットを洗い出したい場合に、便利なテクニックを紹介します。

まず、変更履歴を見たいファイルのコード内で右クリックします。
表示されたメニューから「Git: View File History」をクリックします。

すると、下記画像のように「error-detector.js」の変更履歴のコミットが一覧で表示されます。

試しに、一つコミットをクリックしてみましょう。
すると、下側にそのコミットがどのファイルを変更しているのかが分かります。

そのコミットでどの様な変更を行っているのかを見たい場合は、まず見たいファイルをクリックして(下図の1)、開いたコマンドパレットから「Compare against previous version」をクリックします。(下図の2)

すると、ebcf586のコミットとd891cd17のコミットとの変更を見ることが出来ます。(下図)

自分が作ったコミットの一覧を見たい

このパターンもたまに出会います。
自分が実装した記憶があるのですが、どのコミットでどのファイルを編集したのかがわからない場合、自分が作ったコミットの一覧がわかると、そのコミットをさかのぼって記憶を呼び出すことが出来ます。

まずコマンドパレットを開きます。(Macの場合は、Command+Shift+P)
「Git: VIew History(git log)」をクリックします。

するとGit logの結果が表示されます。

右上にあるAll Authorsのプルダウンをクリックして、絞り込みたい人名を選択します。
今回は、Vue.jsの開発者であるEvan Youさんを選択します。

すると、下記画像のようにEvanさんのコミットのみに絞り込むことが出来ます。

よく使うショートカット

おまけとして、よく使うショートカットを記載します。

コマンドパレットを開く
Cammand+Shift+P

ウィンドウを閉じる
Command+W

ウィンドウを右に移動
Command+Shift+]

ウィンドウを左に移動
Command+Shift+[

最後に

基本的なことであれば、VSCode内でGit管理は完結できるかと思います。
一部、複雑な操作(originの変更やreflog使った巻き戻しなど)は、コマンドを叩くこともありますし、Sourcetreeも愛用しているので使うこともありますが、大体はVSCodeで欲しい機能は足りてるかな、という印象です。
他にも色々と便利な機能があると思いますので、もしよければコメントなどで教えて頂ければ幸いです。
皆さんもVSCodeで良い開発者ライフを。

問題

ローカル環境のmasterブランチを最新のものにしようと思い、git pull を実行した。

すると、以下のようなエラーが現れた。

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

`git pull <remote> <branch>`

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/<branch> master`

結論⇨ローカルmasterブランチにupstreamを指定する

以下のコマンドで、ローカル環境masterブランチのupstreamとしてリモート環境masterブランチを指定してあげると解決しました。

git branch --set-upstream-to=origin/master master`

解説

git pull <remote> <branch> の <remote> と <branch> という引数が省略された場合は、

「現在いるブランチの upstream から現在いるブランチに pull する」という挙動をとります。

この時に、upstremに何らかのブランチがされていない場合はこの警告が出るみたいです。

僕の事例とその解決方法

僕の事例とその解決方法をまとめると以下のようになります。

①ローカルmasterブランチを最新の状態にするためにgit pullを実行

②引数がないgit pullなので、ローカルmasterブランチに設定されているupstreamを参照しようとするも、upstreamが設定されていなかったので上記の警告が出る

③git branch --set-upstream-to=origin/master masterを実行してローカルmasterブランチのupstream をリモートmasterブランチに設定

④再度git pull 実行 ⇨ 成功

参考

Git で git pull するとマージすべきブランチがわからないと言われる場合の対処方法

かなり参考にさせていただいたサイトです。合わせてご確認ください。

なんとなくGitを使っていました。
基本的にはgit add/commit/push/pull/cloneができれば、最低限は開発できたので、困るまでそれでいいかななんて思っていたのですが、
ブランチ操作でローカルレポジトリがよくわからないことになったので、ちゃんと勉強するか〜と思って勉強しました。

概要

Gitのブランチ操作は、HEADの位置をズラしているだけ。
別ディレクトリを切り出しているわけではない。

ブランチ操作のときに起きた問題

ブランチを3つ作って、

• リモートレポジトリ同様のブランチ(develop)
• 実験ブランチ
• 必須要件ブランチ

という役割分担で運営してました。
ローカルのdevelopから、実験ブランチ→必須要件ブランチという順番にブランチを切っていきました。
必須要件ブランチをリモートリポジトリにｐushすっぞ、となったときに、リモートのバージョンが結構進んでいたので、pullして新しい差分をとりこむことにしました。
結構ガチャガチャやったら、なぜか実験ブランチの修正内容が消えていました。

原因はっきりわかっていないのですが、未commitのまま、ブランチを切り替えたので、
ワークディレクトリの内容が消えてしまったのだと思われます。
（消える危険があるときはcheckoutできないと思っていたのですが、できる場合もある？）

ブランチ運用を雰囲気でやっていたツケでした。
幸い実験ブランチはコード自体は微修正だったので、結局「git reset」で最終commit時まで戻して、コード内容だけをコピーして、
ブランチ自体を消してしまって、きれいにつくりなおすという原始的な手段を使いました。
ただリモートレポジトリに更新あるたびに、実験中のブランチめちゃくちゃになったら怖いです。

ブランチを切ったときに本当に起きていること

ブランチを切る操作は、下記のコマンドをうちますね？

b1をつくる

git branch b1

b1にブランチを移動

git checkout b1

僕はこっちでやる派ですが、１つのコマンドでもできます。
（オプションを覚えられないんですよね……）

b1をつくって、移動

git checkout -b b1

僕は今まで、この操作で別ディレクトリができているイメージでいました。
これは完全に間違い。
他のバージョン管理システムだと、ブランチを切る作業＝作業ディレクトリの丸コピーというものもあるみたいです。

Gitはlinus torvalds（Linux作ったフィンランド人）が、それまでのバージョン管理システム（VCS）にムカついて作ったものです。
僕自身はSubversionなどのバージョン管理システム使ったことなくて、いきなりgitだったので、branch操作が高速！　という感覚もなく、
それを当たり前として受け入れてしまいましたが、違うみたいです。

Git のブランチモデルは、Git の機能の中でもっともすばらしいものだという人もいるほどです。
そしてこの機能こそが Git を他の VCS とは一線を画すものとしています。
何がそんなにすばらしいのでしょう?
Git のブランチ機能は圧倒的に軽量です。
ブランチの作成はほぼ一瞬で完了しますし、ブランチの切り替えも高速に行えます。
その他大勢の VCS とは異なり、Git では頻繁にブランチ作成とマージを繰り返すワークフローを推奨しています。
一日に複数のブランチを切ることさえ珍しくありません。
この機能を理解して身につけることで、あなたはパワフルで他に類を見ないツールを手に入れることになります。
これは、あなたの開発手法を文字通り一変させてくれるでしょう。

3.1 Git のブランチ機能 - ブランチとは

でも作業ディレクトリコピーしないとしたら、どうやってGitはブランチ変更してるのか？　を説明します。
Gitのバージョン管理は、commitした時点のスナップショットによって行われます。
現在自分がどのスナップショットにいるのかを把握するために、「HEAD」というポインタを持っています。
commitを取り消したいときに

git reset --hard HEAD

というコマンドはうったことがありましたが、実はHEADが何かわかっていませんでした。
HEADは「レポジトリの中で現在どのコミット位置にいるか」を指すポインタなんですね。

commitだけではなく、branchもこのHEADを活用しています。

branch

git branch testing

branchを切ったとき、ここではmaster→testingと切ったとしましょう。
その場合、見ているスナップショットの位置は一緒です。
更にHEADはmasterを指しています。

checkoutしてみましょう。

testingにブランチを移動

git checkout testing

checkoutによって、HEADはtestingを指すようになります。
ただこの時点では、両branchともにスナップショットの中身が一緒なので、結局は同じバージョンを指しています。

このあとtestingで開発を進めて、commitすると、branch内容が分岐します。

これ以降は、両ブランチは互いに分岐したものとして、それぞれの変更は、互いに影響しません。
実験ブランチであれば、作ってそのままにしておけばいいですし、本流に組み込みたければ、mergeを使います。
修正内容がかち合ったらconflictが発生するので、そこだけ修正すれば容易にmergeできるはずです。

リモート追跡ブランチについて

これも書きたかったんですが、長くなったので、また別記事にします。

参考

3.1 Git のブランチ機能 - ブランチとは
記事中に出てくる画像もこちらからです。

githubにpushしてみたい！のでやってみました。
端末はmac、以下のQiita記事を参考にさせていただきつつ手を動かしています。
大感謝〜！
あとわかばちゃんと学ぶGitのマンガも読みました。
結構良書ですw

https://qiita.com/nutsinshell/items/96cb83aecf9d09a7a8bc:embed:cite

https://qiita.com/nnahito/items/565f8755e70c51532459:embed:cite

やってみる

githubアカウントを作成し、リモートリポジトリを作成。

gitは以前にhomebrewでインストールしていたようです。
さっとググっておさらい。バージョンが古そうですが、今回はこれで。

# git --version

git version 2.20.1 (Apple Git-117)

homeディレクトリにgithub/githubtestディレクトリを作成し、git init。
git initでローカルリポジトリが作成されるとのこと。

ローカルリポジトリ=管理するディレクトリやファイルを置く領域。ディレクトリ。

確かに隠しディレクトリで.initが作成されました。内容はよくわからんのでそっとしておきます。

# ls -lha

.
..
.git

適当にテキストファイルを作成し、ローカルリポジトリに配置。

# vi hellogit

hello my git!github!!

git addで変更点をインデックスに追加。
インデックス=変更点をローカルリポジトリに保存する前に登録する場所？
ここにローカルリポジトリ（変更前）との差分を保存する。。のかw？時間経過で具体化できると信じよう。

# git add hellogit

インデックスに変更点を追加したらコミットする。
コミット=ローカルリポジトリへの変更点の登録。上書き？
で、そのバージョン管理をしているからいついつ変更したファイルを何時でも使用できるのがgit。。のように読み取れますがどうなのでしょうねw
-mはmsgの略とのことです。

# git commit -m "はじめてのgithub!"
>

改行されて>が出力されましたが、たぶんこれは意図せぬ何かの気がしますw
git commitでググるとgit statusなるコマンドがヒットしました。見てみる。

# git status

No commits yet

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

    new file:   hellogit

まだコミットしてませんよ〜できてませんよ〜かな？
適当に手を動かしたら'文字列'で成功しました。

# git commit -m 'はじめてのgithub!'

これでインデックスの内容がローカルリポジトリへ登録されました。なんか嬉しい。

リモートリポジトリを作成した時に生成されたgithubのURLをインデックスへ登録。
先ほどのインデックスの理解が少し違う気がするけど進める。

# git remote add origin URL

インデックスに登録したよ！みたいなメッセージはないんですね。
続いていよいよpush。

# git push origin master

Username for 'https://github.com':  #githubのUsernameを入力
Password for 'https://Username@github.com':  #Usernameに対するPasswordを入力

一瞬ん？となりましたがユーザ名とパスを入力し無事pushできた。。ように見えますのでw、ブラウザで確認。
pushできてる！やったぜ！

ちなみにorigin masterはローカルのmasterブランチを git にpushする、を意味するらしい。
我が地元の雄、Backlogの記事がとてもわかりやすかったです。

https://backlog.com/ja/git-tutorial/stepup/stepup1_1.html:embed:cite

編集してみる。
viで適当に行を追加、インデックスにaddしてgit statusで確認。
commit -mしてpushしてブラウザで確認して完了！手を動かすと理解も早いですね。
コンソール開きっぱで作業したのですが、ユーザ名とパスは聞かれませんでした。
1度pushしたからかな？
ここまでで基本の基本は一旦完了。

ブランチ

ブランチ。。。。？？？
とりあえずQiita記事にありがたく倣ってみます。

git branch testbranch
git branch

* master
  testbranch

Railsチュートリアルで見た事あるやつが！！！
うっすらと思い出しました。

ブランチの変更。

git checkout testbranch

  master
* testbranch

おお。なんか嬉しくなりますねw

ブランチを変更したあとは先の流れ通り。
インデックスにaddしてローカルリポジトリにcommitしてgit push origin testbranch。
ブラウザで確認して完了です。
先人の知恵に感謝感謝であります。

マージ

testbranchでの変更点をmasterbranchに反映させることをマージと呼ぶそうです。ふむ（わかってない）

git checkout masterでブランチの切り替え後にmergeするようです。
merge後はmasterをpush。

git merge testbranch
git push origin master

ブラウザでmasterブランチを選択し確認。反映されてました。

ブランチの削除

お試しブランチ作成時に速攻で間違えたので調べましたw
gitってタブで補完してくれないんですね。プラグインとかあるのかな。

git branch --delete ブランチ名

本日はここまで。
よく聞くpull、クローン、ローカルのコンソールで作業してる時の切り替え（これはgit）など疑問が残っていますので改めて調べたいと思います。