初期設定

インストールされた Git の確認

git version

ユーザ名の設定 (Github で登録したユーザ名)

git config --global user.name "hogehoge"

メールアドレスの設定 (Github で登録したメールアドレス)

git config --global user.email test@example.com

Git でコミットやタグのメッセージを編集するときにデフォルトで使用されるエディタを設定

Atomを使う場合

git config --global core.editor "atom --wait" 

VisualStudioCodeを使う場合

git config --global core.editor "code --wait"

設定内容の確認

git config --list

ローカルリポジトリに反映させるまで

まずは Git で管理していきたいディレクトリに移動します。
その後、そのディレクトリを丸ごとローカルリポジトリに追加するために git init と打ちます。

git init

これで最初の準備の一つであるローカルリポジトリが作成できました。

さて、このあとは書いたコード等のファイルをローカルリポジトリに追加していきます。

普段、コードを書いたりファイルを作成する場所のことをGitではワークツリーといいます。
このワークツリーの状況をローカルリポジトリに反映させる前に、
一度「このファイルは反映させる準備OK」と明らかにするためステージにファイルを追加していきます。

このときのコマンドが git add です。

git add ファイル名

作業中のフォルダ内のファイルをすべて追加したければ git add . と打ちます。

git add .

これでローカルリポジトリに反映させる準備が整いました。
その他に反映させたいファイルが出来上がったら、追加で更にファイルを git add でステージに追加します。
そしていよいよ準備が整ったら、git commit でローカルリポジトリに反映させることになります。
さらにオプションで -m "こめんと" という形でコメント付きのコミットを実行できます。
変更内容が自分からみても、他の人から見ても分かるようになるので必ずつけるようにしましょう。

git commit -m "コメントを入力"

これでローカルリポジトリへ変更を反映できました。

ちなみにワークツリー内の変更を一旦、コミット前に確認することもできます。

git status

変更差分をみたいとき

git diff コマンドを使います。

ワークツリーとステージの差分を確認

git diff
or
git diff ファイル名

ステージとリポジトリの差分を確認

git diff --staged

これまでの変更履歴をみたいとき

git log

一行ずつ要約して履歴を表示

git log --oneline

特定ファイルにおける変更差分を表示

git log -p test.txt

ファイルの削除を記録

ファイルごと削除

git rm test.txt

ディレクトリごと削除

git rm -r testdir

ファイルは残すがリポジトリから削除

git rm --chached test.txt

ちなみにこのとき削除したファイルを add はできないので、既にステージングが完了している状態になっています。

ファイルの移動を記録

git mv testOld.txt testNew.txt

Github 内の既存プロジェクトを作業するとき

あなたが開発チームに参入したときなど、既にGithubに上がっているコードから作業をする時があるかもしれません。
そんなときは、まずはリモートリポジトリ（今回はGithub上）にあるファイル達を一度ローカルリポジトリとワークツリーにコピーしてきてあげます。

git clone リポジトリ名

リポジトリ名は、Githubでコピーしたいリポジトリを開いたらClone用のURLをコピーできる場所から入手します。

上記は私のGithub内に作ったテスト用のリモートリポジトリですが、これをローカルリポジトリおよびワークツリーにコピーするときはこんな感じです。

git clone https://github.com/tmasuyama1114/testgit.git

リモートリポジトリ(Github)でコードを管理

リモートリポジトリ(Github)を新規追加

git remote add origin リポジトリURL で追加できます

git remote add origin https://github.com/tmasuyama1114/testgit.git

なお、cloneしたリポジトリで作業しているときは既にorigin(ショートカット)が存在してしまっているので以下のコマンドで一度削除してあげます。

git remote rm origin

ここでいうoriginは、登録するリモートリポジトリURLの短縮名というイメージです。

リモート

git push リモート名 ブランチ名 でプッシュします

git push origin master

ちなみに最初に以下のようにオプションをつけておくと、次回以降pushするときに「origin master」とつけなくて済みます。

git push -u origin master

Gitで管理させないファイルを登録

パスワードが書いてあるファイルだったり、ただのキャッシュファイルだったりするようなものはGitでバージョン管理する必要がありませんね。
そういったファイルは .gitignore に書きます。

以下は、ignoreFile.txt というファイルをバージョン管理したくないときの .gitignore ファイルです。

.gitignore

# 以下のファイルはGit管理対象外
ignoreFile.txt

変更を戻す時

ファイルへの変更を取り消す

git checkout --test.txt

ディレクトリ全体の変更を取り消す

git checkout --testdir

全変更を取り消す

git checkout --

ステージした変更を取り消す (git add したものを取り下げる)

ステージしたファイルを取り消す

git reset HEAD test.txt

ステージしたディレクトリを取り消す

git reset HEAD testdir

ステージした全変更を取り消す

git reset HEAD

コミットのやり直し

pushする前ならばコミットをやり直せる（修正できる）

直前のコミットのやり直し(今のステージの内容で)

git commit --amend

リモートリポジトリとのやり取り

リモートリポジトリの設定

リモートを表示

git remote

詳細情報

git remote -v

リモートリポジトリを複数登録

git remote add リモート名 リモートURL

例えば origin の他に other というリモートリポジトリを登録した場合は
以下のようなコマンドでpushなどの操作を行うことになります。

git push other https://xxxxxxxxxx

リモートから取得（フェッチ）

フェッチはリモートから情報をコピーした後、すぐにマージしない時に使うコマンドです。

git fetch origin(リモート名)

フェッチの場合、ワークツリー(master)には保存されずブランチとして保存されるので
内容を表示したいときは git branch -a でフェッチしたものを確認し、
git checkout remotes/origin/master でブランチを切り替えます。

フェッチした内容を origin/master ブランチに merge したいときは
先に git checkout master でmasterブランチに戻り、以下のコマンドを入力します。

git merge origin/master

リモートから取得（プル）

プルはリモートから情報をコピーした後、すぐにマージする時に使います。

git pull origin master

そのため、上記のコマンドと下記のコマンドは同じ意味を持ちます。

git fetch origin master
git merge origin/master

リモートの詳細情報を表示

git remote show origin

リモートを変更する（リネーム）

git remote rename 古いリモート名 新リモート名

リモートを削除する

git remote rm リモート名

ブランチの操作

ブランチを追加

git branch ブランチ名

ブランチの一覧を表示

git branch

すべてのブランチを表示

git branch -a

既存のブランチを切り替える

git checkout 既存ブランチ名

ブランチを新規作成して切り替える

git checkout -b 新ブランチ名

変更をマージ

git merge ブランチ名

ブランチ名の変更(作業中のブランチで入力)

作業中のブランチで以下を実行します。

git branch -m 新しいブランチ名

ブランチの削除

git branch -d ブランチ名

上記を実行したとき、対象のブランチがもし master にマージされていないブランチである場合には削除できません。
それでも強制的にブランチを削除したいときは、

git branch -D ブランチ名

コンフリクトの扱い

同じファイルで、同じ行に対して異なる変更を行うとコンフリクトが発生します。
その際にはコンフリクトを解消してあげる必要があります。

解消方法

コンフリクトしたファイルには、コンフリクトが発生した箇所がわかるようになっているので
最終的な(正しい)形にファイルを修正してあげればOKです。

コンフリクトが起きているファイルの確認方法

git status

で確認すると、該当のファイルが表示されます。
そしてワークツリー内のファイルを確認するとコンフリクトについての記載があるので、あるべき姿になるように修正の上
git add と git commit をしてあげればコンフリクトを解消できます。

コンフリクトの防止するための注意点

• 複数人でファイルを同時に編集しないこと
• pull を行う際は、pull をしようとしているブランチに checkout してから pull を行うこと
• pull・merge をする前に commit or stash を行い、編集中のファイルを無くす

【自分とこの環境下におけるGit & GitLabレクチャー】

グループプロジェクトに関わる人達に向けて．大きく分けると以下の利用が考えられる．

• プロジェクト立ち上げ側
• プロジェクト利用側
  • 単に使いたい
  • 自分のプロジェクトの一部として使いたい
  • 使いながら追加・修正し，もとのプロジェクトに貢献もしたい
    • プロジェクト開発にも関わる

プロジェクトの立ち上げ側

流れとしては以下のようになる．

1. 個人プロジェクトとして作成．
2. 共有したいプロジェクトが出てきたらグループプロジェクトに変更

後輩などに自分のプロジェクトを使用してもらいたくなった場合，個人プロジェクトからcloneすると面倒になる．
そのような要求が出始めたらグループプロジェクトにしましょう，という話である．

グループプロジェクトへの変更方法

フォークを使用する．

GitLabでの作業

1. GitLabにログイン，グループプロジェクトに変更したいプロジェクトに移動．
2. 左ペインの「プロジェクトの概要」から「詳細」を選択．
3. メイン表示部分のフォーク(もしかしたらFork)を選択．
4. フォーク先の候補が出るので選択．

以上の作業によって個人プロジェクトがなくなることはない．
ただし，グループプロジェクトと同期しているつもりが個人プロジェクトと同期してしまっていたりすることがあるので注意すること．

立ち上げ者のローカルでの作業

git pushやpullのアドレスが合わるのでURLを更新する．
やり方としては

• git cloneをし直す
• git remote renameとaddでoriginのアドレスを更新する

のどちらか．renameとaddを使用する場合は以下の通り．

$ git remote rename origin personal
$ git remote add origin [グループプロジェクトのURL]

ここでグループプロジェクトのURLはGitLabの『クローンする』で出てくるgit@から始まるもの．

プロジェクト利用側

以下の例のもとに説明する．

• ワークスペースやプロジェクトを置きたいディレクトリ
  • 名前を[ws]
• プロジェクト
  • 名前を[proj]や[my_proj]
• プロジェクト内部の一部のディレクトリ・ファイルなど
  • 名前を[dirfile]など
• プロジェクトのURL
  • 名前を[group_url]

単に使いたい

とりあえず難しく考えずに使いたかったり，プロジェクト自体が完結しているのでそのまま使える場合を想定する．

手順

$ cd [ws]
$ git clone [group_url]

手順:ちょっと凝った手順

clone時に全部DLするのではなく，必要なもののみをDLする方法．
参考:Gitの一部のディレクトリだけ取得する方法

$ cd [ws]
$ git init
$ git config core.sparsecheckout true
$ echo [dirfile] >> .git/info/sparse-checkout # sparse-checkoutの中に記述されてるもののみをDL．複数の場合は複数行記述．
$ git remote add origin [group_url]
$ git pull origin master

自分のプロジェクトの一部として使いたい

外部のプロジェクトを自分のプロジェクトの一部として使いたい．そのプロジェクトの管理は外部に任せて，自分ではいじらない．
git cloneで持ってきちゃうとオリジナルと持ってきたもので2重になり管理が大変．そんなことはしたくない場合に使用．
基本的にROS2システムの場合，様々なパッケージ(プロジェクト)を寄せ集めて一つのやりたいこと(ワークスペース)をしているので，この使い方になりそう．
参考:

• 依存リポジトリ管理でのsubmodule/subtree/subrepoの使い分け

手順

基本的に自分のプロジェクト[my_proj]があり，その中に外部のプロジェクトgroup_urlを取り込む．
前提として自分のプロジェクトが既に存在し設定していること．

設定

設定しただけでは外部のプロジェクトの中身は空っぽです．

$ cd [my_proj]
$ git submodule add [group_url]

使用

外部プロジェクトのDL．

$ git submodule init

外部プロジェクトのアップデート．

$ git submodule update

使いながら追加・修正し，もとのプロジェクトに貢献もしたい

外部のプロジェクトを使いながら，中身を追加・修正しもとのプロジェクトに貢献したい偉い人用．
基本的にROS2システムの場合，様々なパッケージ(プロジェクト)を寄せ集めて一つのやりたいこと(ワークスペース)をしているので，この使い方になりそう．

手順:自分の好みのままにいじってみたい場合

GitLab上にて，グループプロジェクトを自分の個人プロジェクトとしてForkしていじる．
その中で他人にも使えそうなものは，グループプロジェクトにマージリクエストして還元する．

手順:自分のプロジェクトの一部として使用していく場合

基本的に自分のプロジェクト[my_proj]があり，その中に外部のプロジェクトgroup_urlを取り込む．
前提として自分のプロジェクトが既に存在し設定していること．
またremote addでつける名前はなんでもいいが，ここでは[out_name]とし，取り込むディレクトリを[out_dir]で説明．
参考:

• 依存リポジトリ管理でのsubmodule/subtree/subrepoの使い分け
• Git Subtree 事始め
• git subtreeの練習

設定

$ cd [my_proj]
$ git remote add [out_name] [group_url]
$ git subtree add --prefix [out_dir] [out_name] master --squash

更新

$ git pull -s subtree --squash [out_name] master

その他:他の人のプロジェクトを見るためには

グループプロジェクトを選択した状態で左ペインにある「メンバー」をクリックすると参加しているメンバー一覧を見ることができる．そこからメンバーをクリックすると各メンバーのページに飛び，そのメンバーが持っているプロジェクトを見ることができる．
なお，universal_toolsのグループプロジェクトには全員を登録している(つもり)なので，他のプロジェクトに参加している人にアクセスしたい場合はこちらのグループプロジェクトを参照のこと．

概要

gitについて勉強しています．Youtubeにある動画の感想を残しておきます．

動画一覧

gitの目的や考え方など、現役エンジニアが解説

最初にみるのに良いかも

【Git入門】サルでも分かるGit入門の前に！Git使い方高速入門編【入門は5分で十分だと思います】

聞いていてイラつく人もいるかもしれないが，テンポ良く説明してくれてわかりやすい（悔しいかな）．

【CC道場 #175】サルでもわかるGitスクール by Adobe x Nulab Creative Cloud -アドビ公式-

今後みたい動画．VScodeと取り合わせて説明してるっぽい．なんか馴染みやすい．