gitプロジェクト直下にある.gitignoreを編集する。

①C:/Users/{userName}/.gitignoreを編集する。

.gitignore

pom.xml    // pom.xmlを除外する。
bin/       // classファイルを除外する。
*.csv      // 全CSVファイルを除外する。

②作成した除外ファイルを有効にする。
C:/Users/{userName}/.gitconfigを編集する

.gitconfig

[core]
    excludesfile = ~/.gitignore

【メモ】
・上記は、全プロジェクトに対して有効
・ただし、すでにaddまたはcommitしたファイルは除外されない。
・SourceTree上でも.gitignoreを編集できるけど
　それはプロジェクト単位のやつで、かつ「.gitignore」
　自体がaddの対象になってしまうので、あんまりやりたくない。
　(間違えてcommitしたら困る)
・逆にpullしてくるファイルが除外対象になるかどうかは未確認。
　(ならないとは思うけど。)

この記事のねらい

Gitが難しいという印象を持たれがちな理由は色々あると思いますが、そもそもGitが管理しているデータが何なのかさえ理解してしまえば、後の理解は芋づる式についてくる気がします。
なので、Gitのリポジトリを構成する最低限の要素を解説し、よく使うコマンドがどう作用するのかをまとめてみます。
次のような人におすすめです。

• Gitがいいらしいのは良く聞くけど難しそうで二の足踏んでる人
• Git使ってはいるけど分からないことが多くていつ事故を起こすか不安な人
• 中身がどうなってるか把握しないとスッキリしない人

最低限の要素は2つだけ

Gitのリポジトリはコミットとブランチでできています。これが分かればもうGitは8割方理解したも同然です。残りの2割はそれをどう操作するかという応用や組み合わせの話でしかありません。

コミット

次の3つの情報を持ちます。

• 変更内容(差分とログ・変更者の情報など)
• そのコミットであることを表すユニークなID(ハッシュコード)
• 親コミットのID

このコミットがたくさん積み上がることによってリポジトリは大きくなっていきます。

ブランチ

Gitにおいてブランチが持つ重要な情報はただ1つです。

• リポジトリの現在位置となるコミットのID

名前が付けられたりといった要素もありますが、本質的にはこれだけです。いわばコミットへのポインタです。

ブランチは必要に応じて自由に作成でき、1つのリポジトリ内に複数のブランチを持つことができます。その場合は、どれか1つのブランチを選択することでそのブランチが指し示すコミットが現在位置となります。

先に述べたように、個々のコミットは自分の親しか知りません。ブランチが現在位置となるコミットを指し示し、親コミットを再帰的に辿っていくことによって、そのブランチの系譜における全ての変更内容が把握できる仕組みになっています。

運用上は「ブランチの系譜に属するコミット全体」をブランチと呼ぶことも多く、それが混乱の一因となっている気がします。あくまでGitの管理上ではブランチはコミットへのポインタでしかないことを意識してみてください。

コマンドの作用をコミットとブランチの動きだけで解説

Gitのリポジトリに対する操作とは、突き詰めれば「コミットをどう増やして、ブランチをどう動かすか」でしかありません。名前が付いている操作も分解すれば粒度の小さい操作の集合だったりするので、実はそれほど覚えるべき事は多くないのです。
というわけで、よく使う＆粒度が小さめの操作から解説していきます。

commit

現在のブランチが指すコミットを親とする新たなコミットを追加します。
ブランチは新たに追加したコミットを指します。

図ではコミットから伸びている矢印が下方向を指していますが、これはコミットが親方向への参照しか持っていないことを示しているためです。変更の時系列としては逆方向になります。

branch

新しいブランチを作成します。
デフォルトではリポジトリの現在位置を指す状態で作成されますが、既存のブランチ名やコミットIDを指定して作成することもできます。masterという名前のブランチは最初から存在しており、多くの場合はリポジトリの安定した状態を保持するために使われます。

branchコマンドでは作成のみを行い、ブランチの選択状態までは変更しません。
上図は、hogeブランチを新たに作成していますが、現在のブランチはmasterのままであることを表しています。選択状態を切り替えるには、後述するcheckoutコマンドを使用します。

checkout

現在のブランチを切り替えます。
切り替えるのと同時に、リポジトリ内の作業コピー（バージョン管理対象となっているファイル）の状態も変更されます。

ブランチを切り替えてコミットすることで、ツリーの分岐が発生します。コミットは現在のブランチが指すコミットを親とするからです。

(以下書きかけ)

このノリで書いてたら手間が大変なので挫折したのですが、この時点でもまぁまぁ価値がありそうなのでWIPで公開します。続きの需要がありそうだったら頑張ります。

リモートリポジトリからプロジェクトをgit cloneした時に、ローカルリポジトリには、masterブランチしか反映されておらず、リモートの他のブランチをローカルに反映するにはどうしたら良いのか？少し戸惑ったため、記録しておきます。

方法

結論：git checkout -b （ローカルで付けたいブランチ名）（リモートのブランチ名） を使います。

手順1

git branch -a を実行することで、リモートとローカルに存在するすべてのブランチを確認できる。
下記の通り、*がついているブランチは今作業中のブランチを表しています。※緑色で表示されているはず。
また、リモートのブランチは赤文字で表示されているはずです。

$ git branch -a 

⇒　
   * master
   remotes/origin/hoge
   remotes/origin/hogehoge

手順2

手順1で確認したように、ローカルでdevelopブランチを作成し、リモートのhogeブランチを反映します。

$ git checkout -b develop remotes/origin/hoge

再度git branch -aを実行し確認すると、ローカルにdevelopブランチが作成されており、
作業ブランチがdevelopに切り替わって、リモートのhogeブランチの内容が反映されています。

$ git branch -a 

⇒
     master
   * develop
   remotes/origin/hoge
   remotes/origin/hogehoge

終わりに

この記事を見てくださった方、ご指摘の点など、ございましたらコメントを
くださいm(_ _)m

今回は以下のような場合の対処法

• 誤ってmasterブランチで作業を行ってしまった

• 作業内容をコミットせずに別のブランチで作業を行いたい

対処法 ： git stash コマンドを使用する

git stashとは
変更を一時的に退避しておくことのできる機能

まだcommitしていない状態の変更ファイル
（addしてる or add していない)が存在する状況で、
次のコマンドを実行すると変更ファイルを退避することができる。

terminal

$ git stash

これで、
作業途中のブランチAの変更内容を退避させ、
作業したいブランチBに切り替えて作業を行うことができる。

ではブランチBでの作業完了後、ブランチAの作業に戻りたい場合はどうする？

stash（退避）した内容を確認・復活させる方法

確認

terminal

$ git stash list

上記を実行すると

terminal

$ git stash list
 stash@{0}: WIP on ブランチA: 168601a Add chat-side
 stash@{1}: WIP on ブランチB: 189061a Add chat-main

現在退避させている一覧を確認することができる。
※退避させている数だけ行が増える

説明

 stash名: WIP on stashを行ったブランチ名: ハッシュ コミットコメント

復活！

listの中から復活させたいstash名を確認し、以下コマンドを実行。

terminal

$ git stash apply stash@{0}

上記の場合、ブランチAで行ったstashが復活する。

stash applyで変更を復活した場合、stashリストのなかに復活済みの変更が残る。
これを削除するには、次のコマンドを使用する。

terminal

$ git stash drop 消したいstash名

復活と削除を同時に行う場合は

terminal

$ git stash pop stash名

stashが溜まってくると、なにを変更したのか、どれが必要な変更だったのか
わからなくなるのでこまめに消したり管理することが大切。

参考

https://qiita.com/fukajun/items/41288806e4733cb9c342