Q. みなさんのGit力を教えて下さい!

• 1. Gitなにそれおいしいの?
• 2. 触ったことはあるけど､なんなのかよく分かってない
• 3. 日常的に使っている/だいたい理解している
• 4. Gitマスター

Q. 今日はどんなテンションできましたか?

• 1. なんとなく/たまたまやってたから
• 2. 開発に必要だって聞いたから
• 3. Gitを使えるようになりたい
• 4. Gitは使えるけど､再確認したい

GitHub社がソースコードを北極圏に保存するプロジェクト

• 保存期間は1000年以上
• 2020-02-02時点でアーカイブ

> now my code can freeze before it even gets run

よく知られたソフトウェアのGitHubリポジトリ

vuejs/vue

facebook/react

torvalds/linux

nodejs/node

apple/swift

rails/rails

jquery/jquery

bitcoin/bitcoin

Node.jsのリポジトリを見てみる

そもそもGitとは

バージョン管理システム (VCS) の1つ

VCSにできることは?

• 1. ファイルの変更を追跡する
• 2. 複数のユーザーがファイルやプロジェクトで作業することを簡単にしてくれる

1. ファイルの変更を追跡する

美しいファイル名

変更した箇所がわかる

変更した箇所がわかる

2. 複数のユーザーがファイルやプロジェクトで作業することを簡単にしてくれる

2. 複数のユーザーがファイルやプロジェクトで作業することを簡単にしてくれる

2. 複数のユーザーがファイルやプロジェクトで作業することを簡単にしてくれる

VCSの種類

git

Apache Subversion

Concurrent Versions System

など

詳しくはWikipedia: List of version-control softwareを参照

Gitとは まとめ

• Gitはバージョン管理システムの1つ
• VCSにはGit以外にも多くの種類がある
• Gitを使うとファイルの変更を追跡できる
• Gitを使うと複数のユーザーがファイルやプロジェクトで作業することを簡単にしてくれる

GitHubとは

• WebベースのGitリポジトリ
• 無料でコードを保存するクラウドを提供
• オープンソースプロジェクトで他の開発者とコミュニケーションできる

GitHubの機能を見てみる

(覚えなくて良いです 聞いたら忘れてok)

CI/CD - Automate from code to cloud

• アクションの自動化できるぜ (今回は触れません)

Secure development - Securing software, together

• ソフトウェアの安全は確保するぜ (今回は触れません)

Code review - Seamless code review

• シームレスなコードレビュー環境を提供するぜ

Apps - More ways to work with GitHub

• いろいろな方法でGitHubが利用できるぜ (今回は触れません)

Hosting - All your code and documentation in one place

• ソフトウェアに必要なものはだいたい揃ってるぜ (今回は触れません)

Project management - Manage your ideas

• プロジェクトの管理もできるぜ (今回は触れません)

Team management - The human side of software

• チームの管理もできるぜ (今回は触れません)

でもお高いんでしょ?

GitHubとは まとめ

• WebベースのGitリポジトリ
• 無料でコードを保存するクラウドを提供
• オープンソースプロジェクトで他の開発者とコミュニケーションできる
• GitHubがあれば大体いける(雑)

GitとGitHubを使う理由

(やっと戻ってきた...!)

1. コードが一元化されたクラウドストレージ

• コードはいつで使用できる
• どのコンピュータでも､どのOSでも
• 全てのコードがバックアップされる

2. バージョン管理

• Gitを使用するとコードをコミットするたびに､最後にコードを保存してからなにが変更されたかを記憶する
• ファイルを1万回変更した場合でも､Gitは全ての変更を記憶する
• なにかの理由でコードを3ヶ月前に戻す必要があっても､Gitなら簡単にできる

3. チームで作業する

• 他の人との作業プロセスが簡素化され､プロジェクトでのコラボレーションが簡単になる
• 複数の人同じファイルを同時に編集できる

4. 参加する/オープンソース

• GitHubは基本的なSNS
• 初心者でも簡単に大規模なプロジェクトに貢献したり､オープンソースコミュニティに参加したりできる
• 他の開発者に会い､コードに付いて､質問し､コードの変更を提案できる
• GitHubを定期的に使用することで､開発チームの環境でうまく行動する方法を学ぶことができる

5. コードの改善

• 過去に作成したコードを振り返ることができる
• 何年も前のプロジェクトを見て改善することができる

6. 披露

• GitHubは注目を集めるのに優れた方法
• 特に､独学の開発者である場合､リクルーターや企業に技術力を証明する良い方法

7. とにかく必要になる

• 世界中の企業やテクノロジーがGitを使用している
• Amazon, Facebook, Yahoo, Microsoft, Netflix, Airbnb, Rails, Android...

の前にアンケート

使っているデバイスのosは?

• 1. Windows
• 2. macOS
• 3. Linux/Unix
• 4. その他

GitHubアカウントをつくる

Gitをインストール

macOS/Windows (macOSは標準ではいってるかも)

• 1. 公式のダウンロードページからインストーラーをインストール
  • 
• 2. インストーラーを実行 (全てデフォルト設定でok)

Linux / Unix (おそらく標準で入っている)

Linuxディストロの標準パッケージマネージャ経由 or ソースからビルド (公式ドキュメント)

$ sudo apt-get install git # Debian / Ubuntu
$ sudo pacman -S git # Arch Linux
$ sudo apk add git # Alpine

Gitがインストールできたか確認する

の前にGitを使う方法を決める

Gitを使う方法はいろいろ

• 1. GUIから使う
• 2. CLIから使う

1. GUIから使う

• GUI(Graphical user interface)とは
• 

GUIからGitを使うためのツール (公式ドキュメント)

• 
  Sourcetree

• 
  GitHub Desktop
• 
  GitKraken

2. CLIから使う

• CLI(Command-line interface)とは
• 

Q. どうやって決めればいいの?

A. Gitが使えるようになれば､自分が使うべき方法が分かります

人生で一度だけGitを使えるようになろう

今決めるもの

• 1. テキストエディタ
• 2. ターミナル (とシェル)

1. テキストエディタ

よくわからない方は選ぶ必要ないです

よくわかっていて､自分で使いたいものがる方も選ぶ必要はないです

• Windows --> メモ帳
• macOS --> テキストエディット
• Linux --> 標準ではいっているなにかviとか

今決めたのはテキストエディタと呼ばれるソフト

• テキストファイルを編集するために使います
• 高機能なものは文字に意味のある色付け(シンタックスハイライト)をしてくれたりします

今決めるもの

• 1. テキストエディタ
• 2. ターミナル (とシェル)

2. ターミナル (とシェル)

よくわからない方は選ぶ必要ないです

よくわかっていて､自分で使いたいものがる方も選ぶ必要はないです

• Windows --> MSYS2 (Git Bash)
• macOS --> ターミナル.app (Catalinaではzshになったらしい)
• Linux --> 標準で入ってるなにかTerminal (bash)とか

今決めたのはターミナルと呼ばれる黒い画面のアレ

と､シェルと呼ばれるOSと僕らの仲介役のプログラム

• 僕らはシェルを操作してOSと対話します
• シェルは最低限の機能しかないので､それを黒い画面のアレに映し出すことで､
  見た目やその他の機能(コピペとか)が使えるようにするためにターミナルを使います｡

今決めたもの

• 1. テキストエディタ
• 2. ターミナル (とシェル)

いつでも開けるようにしておいてください

早速CLIからGitを使ってみよう

Gitのバージョンを確認するコマンド

$ git --version
git version 2.17.1

Gitに自分の情報を登録する

• 複数人で開発するときにこの部分を変更したのはだれなのかという情報があったほうが良いからです
• 一度設定すればあとは､Gitが勝手に変更した人を覚えてくれます
• もちろんあとから変更もできます
• 設定はアルファベットを使う

# 名前
# 自分だとわかれば本名でもよく使うアカウント名でもok
# GitHubのアカウント名がわかりやすい
$ git config --global user.name 'your name'

# メールアドレス
# GitHubに登録したもの
$ git config --global user.email 'your@email.com'

# エディター
# 僕の個人的なおすすめ(設定しなくてもok)
$ git config --global core.editor vim

# 設定内容を確認する
$ git config --global --list
user.name=your name
user.email=your@email.com
core.editor=vim # <-- 設定しなければない
# もし､↑のような出力でなく､
# 新しい画面が開いた場合は`q`を押すと､もとの画面に戻ってこれます

リポジトリを作成する

リポジトリを作成する方法

• 1. init: 新たに始める
• 2. clone: 既存のリポジトリを複製して始める

今回は新しくリポジトリをつくってまっさらな状態から始める

リポジトリを作成する

今回はホームディレクトリにsrcというディレクトリを作って､そこで作業します

# リポジトリを置くためのディレクトリを作成して移動
$ mkdir ~/src && cd ~/src

# リポジトリを作成して移動
$ git init git-study # git-study という名前のリポジトリ
Initialized empty Git repository in /home/ユーザー名/src/git-study/.git/
$ cd ./git-study

作成したリポジトリの状態を確認する

# ディレクトのコンテンツを表示するコマンド
$ ls -a
.git # <-- `.git`というディレクトリが新たに作成された

作成したリポジトリの状態を確認する

# ディレクトのコンテンツを表示するコマンド
$ ls -a
.git # <-- `.git`というディレクトリが新たに作成された

つまり､.gitディレクトリがGitの正体

.gitディレクトリを削除すれば､リポジトリの情報は消える
バージョンの情報ももちろん.gitに入っている

作成したリポジトリの状態を確認する

# gitの状態を表示するコマンド
$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

作成したリポジトリの状態を確認する

# gitの状態を表示するコマンド
$ git status
On branch master      # <-- On branch master ってなに?

No commits yet        # <-- No commits yet ってなに?

nothing to commit (create/copy files and use "git add" to track)
#           ↑ だから commit ってなに?                         ↑ track って??

Gitを使うにはどうやら

知らない単語を覚える必要があるらしい

• branch
• master
• commit
• track etc...

commit とは

git statusを実行したときに
2箇所に単語があったらから､なんか重要そう (小並)

commit とは

commit とは

Commitを変更するたびに作れば...!

その時点でのコードの状態を順番に並べられて...

Commitをつくる方法

用意するもの

• commit自身の名前
• コミットされたときのリポジトリの状態 == スナップショット
• 親の名前
• コードを書いた人の名前とタイムスタンプ
• コミットした人の名前とタイムスタンプ
• コミットメッセージ

Commitをつくる方法

用意するもの

• commit自身の名前
• コミットされたときのリポジトリの状態 == スナップショット
• 親の名前
• コードを書いた人の名前とタイムスタンプ
• コミットした人の名前とタイムスタンプ
• コミットメッセージ

新しい状態を作るために

リポジトリのデータを変更する

リポジトリのデータを変更する

# README.mdというファイルを新規作成
$ touch README.md

リポジトリの状態を確認する

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Untracked files: # <-- なんか増えた
  (use "git add <file>..." to include in what will be committed)
#         ↑ "git add <file>..."でコミットされるコンテンツに含めろ

        README.md # README.mdはUntracked filesファイルらしい

nothing added to commit but untracked files present (use "git add" to track)
#                                    "git add" で trackできるらしい ↑

Gitを使うために必要そうな知らない単語

• branch
• master
• commit : スナップショット
• track <--

Untrackedとかtrackとか書いてあったから次はtrackが重要そう (小並)

track とは

track とは

• ファイルを追跡すること
• 追跡対象のファイルは変更されたこと記録できる
• 逆に追跡対象外のファイルはいくら変更しても何も保存されない
• 追跡されているファイルをtracked filesという
  • 直近のスナップショットに存在するファイル
• 追跡されていないファイルをUntracked filesという
  • README.mdも今はUntracked filesなので､追跡できないらしい

README.mdをtrackしてもらう

$ git add README.md

リポジトリの状態を確認する

$ git status
On branch master

No commits yet

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

        new file:   README.md

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Changes to be committed: # <-- なんか変わった
  (use "git rm --cached <file>..." to unstage)
#                                       ↑ unstageってなに?
        new file:   README.md # README.mdがコミットされるファイルになったらしい

Gitを使うために必要そうな知らない単語

• branch
• master
• commit : スナップショット
• track : ファイルを追跡すること
• stage <-- new!

README.mdがコミットされるファイルになったらしい

つまり

Commitをつくる

前に

README.mdのコンテンツを書きたい

今はまだ空のファイルをtrackしてもらっただけ

README.mdに本文を追加する

それぞれ決めてもらったテキストエディタでREADME.mdファイルを編集する

# Windowsの場合
$ notepad ./README.md

# macOSの場合
$ open -a TextEdit ./README.md

# Linuxの場合
$ vi ./README.md

# Git study

メモ帳とテキストエディットはCtrl+sでファイルの変更を保存できる
viはZ, Z

# ファイルのコンテンツを表示するコマンド
$ cat ./README.md
# Git study

リポジトリの状態を確認する

$ git status
On branch master

No commits yet

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

        new file:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Changes to be committed: # <-- ここも変わってない
  (use "git rm --cached <file>..." to unstage)
#                                       ↑ unstageってなに?
        new file:   README.md
 # ↓ ここが増えた
Changes not staged for commit: # <-- stagedってなに?
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

Gitを使うために必要そうな知らない単語

• branch
• master
• commit : スナップショット
• track : ファイルを追跡すること
• stage <--

そろそろstageがなんなのか知りたくなってきた

stageとは

stageとは

• いままで｢コミットされるコンテンツ｣と言われていたファイルをstaged fileという
• 逆に｢コミットされるコンテンツに含まれません｣と言われていたファイルをunstaged fileという
• unstaged fileをstaged fileにするためにはgit addコマンドを使う

git addコマンドには複数の意味がある

git addは

直前のスナップショットから変更されたファイルをStagedにする

コマンド

stageとは

• いままで｢コミットされるコンテンツ｣と言われていたファイルをstaged fileという
• 逆に｢コミットされるコンテンツに含まれません｣と言われていたファイルをunstaged fileという
• unstaged fileをstaged fileにするためにはgit addコマンドを使う
• この操作をステージングするという

コミットの前にファイルをステージングする必要がある

• 1. ファイルを編集する
• 2. ファイルをステージングする
• 3. コミットする

コミットの前にファイルをステージングする必要がある

• 1. ファイルを編集する
• 2. ファイルをステージングする <-- これ必要...?
• 3. コミットする

ステージングができると何が嬉しいのか

開発をしているとき...

機能Aと機能Bの実装を任されました
2つの機能を同時に実装しました
そしてひとつのCommitにまとめてコミットしました

機能Bのほうにバグが見つかりました

そうだ､Gitのちからを使って機能Bがなかった状態に戻そう!

機能Bを消そうとすると､機能Aも一緒に消えてしまう!

ステージングがあれば...

• 1. 機能Aと機能Bを実装する
• 2. 機能Aだけステージングして､コミットする
• 3. 機能Bだけステージングして､コミットする
• 4. もしも機能AかBのどちらかに問題があっても､片方だけ削除できる

ステージングができると､

使いやすいCommitを作ることができるので嬉しい!

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Changes to be committed: # <-- ここも変わってない
  (use "git rm --cached <file>..." to unstage)
#                                       ↑ unstageってなに?
        new file:   README.md
 # ↓ ここが増えた
Changes not staged for commit: # <-- stagedってなに?
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Changes to be committed: # <-- ここも変わってない
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md # <--

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md # <-- 同じファイルなのにstagedとunstagedの両方の状態がある

modifiedとは

• 直前のスナップショットと相違していること

直前のスナップショットって､直前のコミットのことじゃないの?

リポジトリの状態を確認する

$ git status
On branch master # <-- ここは変わってない

No commits yet # <-- ここも変わってない

Changes to be committed: # <-- ここも変わってない
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md # <--

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md # <-- 同じファイルなのにstagedとunstagedの両方の状態がある

git addで変更をIndexにコピーしよう

Indexと､Working directoryの差分を表示するコマンド

(qで元の画面に戻れます)

$ git diff
diff --git a/README.md b/README.md
index 8b13789..a3e7660 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@

+# Git study

変更をIndexにコピーするコマンド

$ git add README.md

リポジトリの状態を確認する

$ git status
n branch master

No commits yet

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

Commitをつくる

Commitをつくることをコミットすると言う

コミットメッセージはコミットするときに指定する

#     コミットメッセージ ↓
$ git commit -m 'create README.md'
[master (root-commit) 656c859] create README.md
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

作成したCommitを確認する

$ git log | cat
commit 656c8598dc4f6af14ec50b8b095add3bfe35c560
Author: anoriqq <shota.yoshikawa@anoriqq.com>
Date:   Thu Feb 6 18:58:33 2020 +0900

    create README.md

作成したCommitを確認する

$ git log | cat
commit 656c8598dc4f6af14ec50b8b095add3bfe35c560 # <-- commitの名前 hashと呼ばれる
Author: anoriqq <shota.yoshikawa@anoriqq.com>   # <-- コードを書いた人
Date:   Thu Feb 6 18:58:33 2020 +0900           # <-- コードを書いた時刻

    create README.md                            # <-- コミットメッセージ

リポジトリの状態を確認する

$ git status
On branch master
nothing to commit, working tree clean

working tree cleanの意味

最新の状態がクリーンで､なにもcommitをつくる材料がない
つまり､working tree == 最新のcommit
working treeに変更を加えると､最新のcommitとの差分ができるので､
新たなcommitが作れるようになる

Gitを使うために必要そうな知らない単語

• branch <-- これと
• master <-- これの話
• commit : スナップショット
• track : ファイルを追跡すること
• stage : コミットするための変更を選択すること

branchとは

• commitの名前を入れる名前付きの箱
• 例えばfeatureという名前のbranchを作ってここに
  commit-Aという名前のCommitを入れておくことができる

masterとは

• デフォルトで作成されるbranchの名前
• ちなみに今は､masterという名前のbranchに
  さっき作ったCommitの名前が入っています

On branch master

--> 今はmasterブランチにいます

今はmasterブランチにいます

いる...とは...?

比較対象がコミットを重ねるごとに変わる!

この比較対象は直前のCommitであり､
このCommitを現在行っている変更の親と呼びます

Gitさんは毎回親を覚えているのがだるいらしい

コミットするたびに次の変更の親はこのCommitです!って言ってられない...

HEADと呼ばれる親を入れる箱を用意した

コミットするたびにHEADに新しい親の名前を入れておこう!

HEADに親が入っている状態をいると表現しています

例えば､HEADがCommit-Aなら
今はCommit-Aにいます｡と言える｡

次の変更をコミットすると､そのCommitの親はCommit-Aになります
そして､次はCommit-Bにいる状態に切り替わります

あれ､今のHEADはCommit-Aじゃなくてmasterブランチだけど...

branchとは

• commitの名前を入れる名前付きの箱
• 例えばfeatureという名前のbranchを作ってここに
  commit-Aという名前のCommitを入れておくことができる

今のHEADはCommit-Aじゃなくて､

Commit-Aを表しているmasterブランチ

わざわざ2重に箱詰めする必要性

重要なのは､自動的にコミットを
進めてくれる箱に名前がつけられること

(HEADには別の名前をたくさんつけられない)

ブランチは無制限に作れる

さらに､すべてのブランチに別々のCommitを入れることができて､
さらにそれぞれを親としてcommitすると､自動的に進んでくれる｡

並列開発ができる!!!

早速新しいブランチを作る

# featureという名前の新しくブランチをつくるコマンド
$ git bransh feature

# ブランチの一覧を表示するコマンド
$ git branch -a
  feature
* master

HEADをfeatureに変更する

今いるのはmasterなので､featureに変更する必要がある

$ git checkout feature
Switched to branch 'feature'

ディレクトリ構成を確認する

$ ls -a
.  ..  .git  README.md

README.mdがある

実は今､masterとfeatureは同じCommitの名前を指している

git branch <新しいブランチ名>というコマンドは､
現在のHEADが指すCommitで新しい名前のブランチを作成するコマンド

あとはそれぞれのブランチで並行して作業すればOK

複数のブランチを1つにまとめたい

一方のブランチの変更を他方のブランチにまとめるコマンド

$ git merge <取り込みたいブランチ名>

GitとGithubを接続する

Gitでは､コードを共有するためになんらかの方法で通信する必要がある

どんな通信方法(プロトコル)があるのか

• Gitの公式ドキュメントによると､Gitが対応しているのは､
  • Local / HTTP / Secure Shell (SSH) / Git
• GitHubの公式ドキュメントによると､GitHubが対応しているのは､
  • HTTPS / SSH

つまり､HTTPかSSHを使えばOK

(GitHubの公式ドキュメントにはとくに書いてないっぽいけど､Gitプロトコルも使いますが､意識しなくてok)

Q. HTTPとSSH､どっちを使えばいいの?

A. どちらでも良いですが､今回はSSHを使います｡

• GitHub公式はHTTPSを使えといっている
• が､その理由はどうやら､SSHよりもHTTPSのほうが簡単でサポートが少なくなるからっぽい (ソース)
• 今回はサポートするのは僕だし､エンジニアならどうせSSH使うので､今のうちに触っておこう

通信内容が外部に漏れた場合､いろいろやばい (語彙力)

ので､通信相手がなりすましでないこと､
通信内容が通信相手にしかわからないこと
通信したことをバックレられないこと
が保証できるように工夫します

ので､通信相手がなりすましでないこと､
通信内容が通信相手にしかわからないこと
通信したことをバックレられないこと
が保証できるように工夫します

これに対応したのがSSH (すごい!)

SSH (Secure Shell) とは

SSHとはハイブリッド暗号通信プロトコル

• 共通鍵暗号で使用するセッション鍵の生成: 鍵交換アルゴリズム
• 通信の暗号化: 共通鍵暗号
• ホスト認証やユーザ認証: 公開鍵暗号 / パスワード認証 / ワンタイムパスワードなど

RFC4250やRFC4251などとして制定されている

SSHで使う暗号鍵ペア (公開鍵と秘密鍵) をつくる

# 鍵をつくるコマンド
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C 'your@email.com'  # GitHubに登録したメールアドレス
Enter passphrase (empty for no passphrase):                       # <-- パスフレーズを入力(任意)
Enter same passphrase again:                                      # <-- パスフレーズを確認(任意)
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.

# 鍵を置いた場所の内容を確認する
$ ls ~/.ssh
id_rsa  id_rsa.pub # <-- この2つのファイルがあればok

自分の公開鍵をGitHubに教える

# 公開鍵を表示してクリップボードにコピーする
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCbErJTyTcqp/hWh8hMowDXWKHRLIWRe2AZ+vMK
j8Sh2VcRihHm+A8WtCWXary8tkFhYjtVzgD2mTpeThr/i8ZZuMOz2gZ0iXQeOQ6fjA4sHUwCzBmI
EqcUa+dfSQI8KrY6fNMp/GFLWn2fayLPpgYoaDtEvkiVJfHnhhyNzsmX7JtzBdX3s2mwTEW0JVwh
wyf1HxBoX07E/IP0m0/K/86fptzJE1AclC8MAPPA6Zgg1dN7HjjNSqeKWd+EqBFoallDq+LEpG94
3SJIjTVuybVDRoSKyzG1eAMpagXHCe54wmWDj+zqdH1Uum+w4e23gGev76Wua0prfQMXJg4Q+udU
d1JgHclu/g+yrMnm10fKRCJ3HbcVwaGPp4N1IbszhBA27wsZR87Qu5UrkVoWg194Kxs97f+z9CsF
Atj37RQ7903ejWhsr/JI68jPgNqXz/9cZv2MJ4CxP3zMO0iLsfqHPl7RPz4bOHnInwNDUCC4Hmdl
7yt2aC30szoEehSVJZa1cNyupmRVMuin9aXlJ11x1BkL5V4JW+7ki+3JKlTmhGdT9RLOpYetNlzQ
j166ZePpKpeL6cBbDhiCCd0urOXz1z8nazHsfIe0I570Zwrd8ygik/aXNZKZreQCLjFsQ/qJ6I0k
4d6NjF+Tmajp8zTae/Tlj2t24SeDNT9iLRk7Kw== your@email.com

SSH keysが追加されたことを確認

リモートリポジトリをつくる

ローカルリポジトリにリモートリポジトリの場所を設定する

$ git remote add origin git@github.com:anoriqq/git-study.git # <-- コピーしてきたURL

ローカルリポジトリの内容をリモートリポジトリにプッシュする

$ git push -u origin master

無事､リモートにプッシュした内容が反映されているか確認する

毎日Gitを使おう