今までSVNを使っていて Git になって commit, push ってなんだという状態だったのでざっくり使うコマンドをメモする。
コマンドで記載しているがGUI操作が多いので間違ってたらごめんなさい。。。

リポジトリ作成

git init
git init ${repository_name}

リポジトリ取得（クローン）

git clone ${URL}

リポジトリ最新化

git pull

リポジトリ最新化（変更上書き）

git fetch origin
git reset --hard origin/master

ブランチ作成

git checkout master
git pull
git branch ${branch_name}

インデックス追加（コミット前処理）

git add -A
git add ${path}

インデックスは仮コミットみたいな感じかな。。。

インデックス確認

git status

インデックス削除

git reset
git reset ${path}

コミット（ローカルに、リモートはまだ）

git commit
git commit ${path}
git commit .

commit のみはインデックス追加したやつをコミット
. つけるとインデックス追加しなくてもコミットできるが新規ファイルがコミットされない

コミット取り消し

git reset --soft
git reset --hard

soft は変更ファイルのこる
hard は変更ファイル残らない

プッシュ（リモートにコミット）

git push

ブランチ->マスタ反映

git checkout master
git pull
git merge ${branch_name}
git push origin master

個人アプリを制作していまして
各種コマンドをすぐ忘れてしまうので、備忘録的に残しておきます。

ローカルでのブランチ名を変更する

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

今開いているブランチの名前変更

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

Github初級者がリモートブランチを操作してみた

みなさんこんにちは、久しぶりに記事を投稿しました。いつもご覧いただきありがとうございます。今回はGithubでリモートブランチを操作して行きたいと思います。

この記事の対象者
Github/Gitを知っている方
＞＞完全初心者には少し難しいかもしれませんが、少し触れたことがあるならできるかと思います。

参考記事
サル先生のGit入門

概要

・ブランチの一覧表示
・ブランチの切替
・ブランチの作成
・ブランチのリモート登録

ブランチの一覧表示

① git branch #ローカルのブランチ一覧を表示
② git branch -a #リモートも含めたローカルのブランチ一覧を表示
③ git branch <name> #<name>という名前のブランチを作成

※）ブランチが確認できなかった場合のやり方 git fetchのコマンドを端末に打つことでソースコードを最新版にしてくれます。

ブランチの切替

①git checkout <branch> #基本的な表示方法
②git checkout -b <branch> #ブランチの作成とブランチの変更を一緒に行うコマンド

EX)②は下記のようなことと同じ動作になりますが、少し手間になります。
git branch branchA
git checkout branchA 

※）git checkoutは作業ブランチの変更を行うときに用います。
※）追加：git checkout -f masterはデフォルトブランチに強制的に移動するコマンドになります。

ブランチの作成

①git branch <name> #基本的な表示方法
②git branch <new_name> <old_name>

ブランチのリモート登録

外部から自身のパソコン（ローカル）にリポジトリを反映したいときに使用するコマンドになります。

① git clone <url>　#外部から（ブラウザ等）ローカルに反省する方法
② git remote add <name> <url> ＃ローカルから外部にリポジトリを追加するとき

リモートのブランチをローカルに反映する

git checkout -b branchA origin/branchA

origin/は「リモートの」という意味

他にもいろいろあるかと思いますが、またわからなくなったときに追加していきたいと考えています。

これは何か

macPCを新しく買い替えた時用に、Pythonでの開発環境を構築するためのメモを記す。

システム環境設定

日本語入力での変換確定を2回ではなく1回にする

開発とは関係ないけど何だか気持ち悪いので変える。

• Launchpadなどから「システム環境設定」->「キーボード」->「入力ソース」を選択する。
• 画面左部より日本語を選択した状態で右画面をスクロールし、「Windows風のキー操作」にチェックを入れる。
• お好みにはなるが、「ライブ変換」のチェックを外しておくと、勝手に変換されなくなる。

ターミナルの背景色を変更する

初期設定だと白地に黒で目が疲れるし落ち着かないので変更する(大体こういうのって黒地が多いイメージ)。

• Launchpadなどからターミナルを開く
• 画面左上のメニューから「ターミナル」->「環境設定」->「プロファイル」を選択する。
• 「テキスト」タブで自由に変更ができる。また画面左部にテンプレートがあるので、そちらから設定もできる(テンプレートを選択した場合、画面下部の「デフォルト」を選択する)。

Homebrew

mac用のパッケージ管理システム。

• こちらのサイトからインストールするためのコマンドをコピーし、ターミナルで実行する(インストールに少々時間がかかる)。 例.

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

• 下記コマンドを実行し、インストールが正常に完了したか確かめる。

$ brew --version
Homebrew 2.5.

Git

バージョン管理システム。

• 下記コマンドを実行し、gitをインストールする。

$ brew install git

• 下記コマンドを実行し、インストールが正常に完了したか確かめる。

$ git —-version
git version 2.28.0

※Gitアカウントを持っている場合は、下記コマンドでconfigに設定しておくといいかもしれない。

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Python

インタープリタ型プログラミング言語。機械学習などでよく用いられる。

• 下記コマンドを実行する。

$ brew install python3

• 対話モードにて、実行確認を行う。なお、 exit() と入力すれば対話モードを終了できる。

$ python3
>>> print("Hello world!")
Hello world!

ANACONDA

Data Scientist向けのPythonおよびR言語用のディストリビューション。

• こちらのページを開く。
• 画面を下の方にスクロールしていくと、下記スクリーンショットに行き着く。
• 赤枠で囲まれている 64-Bit Graphical Installer (462 MB) をクリックし、ダウンロードする。
• インストールされた.pkgファイルをクリックし、案内にしたがってインストールを行う。

pip

Pythonで書かれたパッケージソフトウェアをインストール・管理するためのパッケージ管理システム。

• /usr/bin/easy_installがあるか確認する(大概、プレインストールされているはず)。
  • コマンド例: ls /usr/bin/easy_install
• 下記コマンドを実行する。

sudo easy_install pip

• 実行確認を行う。

$ pip --version
pip 20.2.3

Visual Studio Code(以下、VSCode)

Microsoftが開発したエディタ。

• こちらを開く。
• Download for Mac をクリックし、ダウンロードする。
• ダウンロードしたzipファイルを展開する。
• Visual Studio Codeと書かれたアプリケーションをアプリケーションフォルダにドラッグ&ドロップさせる。

VSCodeの設定について

普段、自分が開発するときに設定しているものを記載しておく。
- 事前にインストールしておくパッケージ。

$ pip install flake8
$ pip install autopep8

• VSCodeでの拡張機能

  • Python
  • Python for VSCode
  • Python Docstring Generator

• setting.json

{
    "python.linting.pylintEnabled": false,
    "python.linting.flake8Enabled": true,
    "files.autoSave": "afterDelay",
    "files.autoSaveDelay": 1000,
    "python.linting.lintOnSave": true,
    "python.formatting.provider": "autopep8",
    "python.linting.flake8Args": [
        "--ignore=E501",
    ],
    "python.formatting.autopep8Args": [
        "--aggressive", "--aggressive",
    ],
    "autoDocstring.docstringFormat": "numpy",
}

終わりに

自分が何入れたか忘れない備忘録として記した。記載漏れなどあったら随時追記していきます。

vscodeでgitを操作する方法総まとめ。各記号の意味と使い方。

vscodeにはデフォルトでgitのソース管理機能が備わっている。

この機能を使うと、普段gitコマンドで実行していることが、UI上で操作できる。使いこなせるとコマンド入力よりも早い。

左側のソース管理アイコンをクリックすると表示される。

目次

1. 現在のブランチの確認方法
2. git add
   1. 変更状態（ステージ前）
   2. ステージされている変更状態
3. git commit
4. git add & git commit
5. 主要操作メニュー
6. git clone
7. git checkout
   1. 既存のブランチに切り替え
   2. 新しいブランチを作成し切り替え
   3. 派生元のブランチを指定してブランチ作成し切り替え
8. 同期（push and/or pull）
   1. 上流ブランチが設定済みの場合
   2. 上流ブランチが設定されてない場合
9. git pull
   1. プル
   2. プル（リベース）
   3. 指定元からプル
10. git push
    1. プッシュ
    2. プッシュ先のリモートレポジトリを選択してプッシュ
    3. リモートのブランチ名を指定してpushする方法
11. git branch
    1. 派生元ブランチを指定して新規ブランチを作成し移動
    2. git merge
    3. ブランチをリモートにプッシュ
    4. ブランチ名を変更
    5. 現在のブランチから新しいブランチを作成する
12. git remote
    1. リモートの削除
    2. リモートの追加
13. git stash
    1. 一時待避
    2. 一時待避（未追跡ファイルを含む）
    3. 選択した一時待避を削除する
    4. 選択した一時待避を復活（削除しない）
    5. 選択した一時待避を復活（削除する）
    6. 最新の一時待避内容を適用
    7. 最新の一時待避内容を適用して削除
14. サブモジュールがある場合
    1. ブランチ名
    2. 円形の矢印
    3. n↓　（数字 ↓）
    4. n↑　（数字 ↑）
15. 色付きの数字とアルファベットの意味
    1. 色付きの数字
    2. 色付きのアルファベット

現在のブランチの確認方法

画面、左下の青い部分には、現在いるブランチ名やエラーの数が表示される。

実例	状態
	masterブランチで作業中。エラー、警告共にゼロ。
	topicブランチで作業中。ファイルに警告一つあり。

git add

addはブランチ全体または、ファイル毎に実行できる。

ステージ前やステージ後（コミット前）でそれぞれ分けて表示される。

・\/ ステージされている変更：git add後、commit前の状態
・\/ 変更：ステージ前の状態(git add前)
　┗ ワークツリーでの変更

変更状態（ステージ前）

ファイルにカーソルを合わせると、新たに、３つのアイコンが表示される。

　　　　　　　↓

アイコン	意味	コマンド
ファイルマーク	vscodeでファイルを開く	$ code <指定したファイル>
＋	変更をステージ	$ git add <指定したファイル>
カーブした矢印	変更を破棄	undo操作

git addの実行

＋をクリックするとファイルの場所が変更からステージされている変更に移動する。(index.htmlに注目)

すべてのファイルを一括操作

変更にカーソルを合わせると、＋と矢印の２つが表示される。

・＋をクリックするとすべてのファイルをgit addする。
　　┗ git add .

・矢印をクリックするとすべてのファイルの変更をなかったことにする(undo)。

Uマーク(新規作成)がついているファイルがあるときに、矢印をクリックするとファイルを削除することになる。

ステージされている変更状態

ステージされている変更にあるファイルにカーソルを合わせると、２つのアイコンが表示される。

アイコン	意味	コマンド
ファイルマーク	vscodeでファイルを開く	$ code <指定したファイル>
ー	変更のステージング解除	$ git reset HEAD <指定したファイル>

-マーク(ステージング解除)

-をクリックすると、ステージされている変更にあったファイルが、変更に戻る。

・$ git reset HEAD <指定したファイル>
　┗ 指定したファイルをHEADがある状態に戻す。

オプションを指定しない場合--mixedと同じ処理で、ステージの状態をクリアするが、ワークツリーは残す。

つまり、git add前の状態と同じになる。

git commit

コミットする場合は、一番上の検索窓にコミットメッセージを入力し、チェックマーク（✔︎）をクリックする。

▼コミットメッセージ（例：add h2を入力）

▼チェックマークをクリック

・$ git commit　-m "add h2"の処理となる。

コミットメッセージを入力しなかった場合
メッセージを入力する順序が変わるだけ。

$ git commitと同じ処理になり、✔︎マークをクリックした後に、メッセージの入力窓が出てくる。

git add & git commit

git addとgit commitを連続して行うこともできる。

1) 変更のみで、ステージに何もない状態であること

2)コミットメッセージを入力し上部のチェックマークをクリック

コミットメッセージが未入力の場合は、別途入力窓が表示される。

3) 操作を選択。
「はい」または「常に行う」をクリックする

↓変更ファイルが一掃され完了となる

操作コマンドは
git add . && git commit

主要操作メニュー

カラム右上・・・をクリックすると、クローンやプルなどその他のコマンドが表示される。

git clone

クローンを選択することで、git cloneが実行できる。

・git clone <リモートレポジトリのURL>

1) URLを入力。または、連携済みのGithubのレポジトリから選択

2) git cloneを実行するフォルダを選択する
実行したフォルダの中に、リモートレポジトリ名で新たなフォルダが作成される。

3) vscodeで開く

git checkout

チェックアウト先を選択すると、ブランチの切り替えができる。
切り替えオプションは３つ。

1. 既存のブランチに切り替え
2. 新らしいブランチを作成し切り替え
3. 派生元のブランチを指定してブランチ作成し切り替え

1. 既存のブランチに切り替え

git checkout <ブランチ名>

画面下に表示されたリストから移動したいブランチを選択する。

検索窓に入力すると絞り込みができる。ブランチがたくさんある場合は便利。

2. 新しいブランチを作成し切り替え

現在のブランチから新しいブランチを作成する。

git checkout -b <ブランチ名>

入力窓に作成したいブランチ名を入力し、「+新しい分岐の作成...」をクリック。

作成したブランチに切り替わる。

入力窓が未入力状態で「+新しい分岐の作成...」をクリックし、後からブランチ名を入力するのでも同じ。

3. 派生元のブランチを指定してブランチ作成し切り替え

ブランチ作成の元となるブランチを指定する。

git checkout -b <新しいブランチ名> <派生元ブランチ名>

1) 検索窓にブランチ名を入力し「+新しい分岐の作成元...」をクリック

2)派生元となるブランチを選択する

同期（push and/or pull）

「プル、プッシュ」にある同期を選択すると、ローカルのブランチとリモートのブランチの差分から、必要に応じて、pushまたはpullを行う。

実行するためには上流ブランチの設定が必要。

上流ブランチが設定済みの場合

▼現在のブランチの上流ブランチに「origin/master」が設定してある場合

上流ブランチの確認方法はgit branch -vv。[ ]の中が上流ブランチ。

$ git branch -vv
* master  c9695c8 [origin/master] commit message

上流ブランチが設定されてない場合

「ブランチを公開しますか？」と聞かれるので、OKを選択すると、<リモート名>/<現在のブランチ名>の上流ブランチが自動作成され、リモートレポジトリに同期される。

上流ブランチ

$ git branch -vv
* topic   ccf5f09 [origin/topic] add ci message

リモートブランチと同期するため、リモート追跡ブランチも追加される。

リモート追跡ブランチ

$ git branch -a
  master
* topic
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/topic

git pull

３種類のプルが選択可能。

1. プル

上流ブランチが設定されている場合に使えるコマンド。タグの情報も持ってくる。

git pull --tags

▼上流ブランチが設定されていない場合はエラーになる

2. プル（リベース）

上流ブランチが設定されている場合に使える。--rabaseオプション(-r)をつけて実行。

git pull --tags -r

コミット履歴をきれいにしたい場合に使う。

3. 指定元からプル

上流ブランチが設定されていない場合や、上流ブランチとは別のブランチからプルしたい場合に使う。

git pull --tags <リモート名> <リモートブランチ名>

リモートレポジトリとリモートブランチを順に選択する。

1) リモートレポジトリを選ぶ
　URLを入力するか、リストから選ぶ。

2) リモートブランチを選ぶ
　入力するか、リストから選ぶ。

git push

2種類のプッシュが選択可能。

1. プッシュ

上流ブランチが設定されている場合に使える。

git push

▼上流ブランチを設定していない場合
上流ブランチが設定されていない場合は、下記アラートが出るのでOKを押すと自動で上流ブランチが設定されpushを行う。

OKをクリックすると、ローカルに上流ブランチと、リモート追跡ブランチが作成される。

リモートには実行したブランチ名のリモートブランチが新たに作成される。

2. プッシュ先のリモートレポジトリを選択してプッシュ

「プッシュ先...」をクリックすると、プッシュ先のリモートレポジトリを選ぶことができる。

・git push　<url> <ローカルレポジトリ名>

ブランチは現在のブランチ名が適用される。（上記アラートでOKをクリックしたのと同じ処理）

リモートのブランチ名を指定してpushする方法

リモートのブランチをローカルと異なるものにしたい場合は、コマンド入力で対応する必要がある。

・git push <レポジトリ名> <ローカルブランチ名>:<リモートブランチ名>

このコマンドで、指定したローカルブランチの内容を、指定したリモートブランチにpushすることができる。

git branch

ブランチでは5種の処理が選択できる。

選択肢は、チェックアウト、プッシュと同じ内容のものがある。ここにしかないのは、ブランチ名の変更と、merge。

1. 派生元ブランチを指定して新規ブランチを作成し移動

「ブランチの作成元...」をクリックすると、任意の既存ブランチから、新たなブランチを作成することができる。

作成したブランチに移動するため、処理はcheckcoutも含まれる。

・git checkout -q -b <新規ブランチ名> --no-track <派生元ブランチ名>
　┗ -q: --quiet。フィードバックメッセージを表示しない
　┗ -b: 新規ブランチを作成
　┗ --no-track: 上流ブランチを設定しない（configでbranch.autoSetupMergeが設定されていたとしても）

▼作業手順
1. 入力窓にブランチ名を入力
2. リストからブランチの作成元を選択

「チェックアウト先」で「+新しい分岐の作成元...」を選択した場合と同じ。

2. git merge

「ブランチをマージ...」を選択すると、git mergeが実行される。

git merge <ブランチ>

表示されたリストからマージ元のブランチを選択する。

3. ブランチをリモートにプッシュ

「ブランチを発行...」をクリックすると、リモートレポジトリにpushを行う。

その際、上流ブランチも設定。

git push -u <リモート名> <現在のブランチ名>
　┗ -u: --set-upstream。上流ブランチとして設定

4. ブランチ名を変更

現在のブランチ名を変更できる。

git branch -m <変更後のブランチ名>
　┗ -m: --move。ブランチ名を変更

5. 現在のブランチから新しいブランチを作成する

「分岐の作成...」をクリックすると現在のブランチから新しいブランチを作成できる。

・git checkout -q -b <新しいブランチ名> --no-track HEAD

「チェックアウト先」で「+新しい分岐の作成...」を選択した場合と同じ。

git remote

リモートでは削除と追加ができる。

1. リモートの削除

ローカルに登録してあるリモートレポジトリ名を削除できる。

・git remote remove <リモート名>
　　┗ 「git remote rm <リモート名>」も同じ

2. リモートの追加

リモートレポジトリにショートカット名をつけて登録できる。

・git remote add <リモート名> <URL>

git stash

一時待避では、７種の処理が選択できる。

1. 一時待避

一時待避では、コメント付きのstashを実行できる。

・git stash push -m "コメント"

stashで-mオプションを使うにはpushが必要。
コミット前のファイルに適用されるが、未追跡ファイルは含まない。

2. 一時待避（未追跡ファイルを含む）

新規作成しgit addしていない未追跡ファイルも含めてstashする。

・git stash push -u -m
　┗ -u: --include-untracked。未追跡ファイルを含む
　┗ -m: --message。pushのオプション

3. 選択した一時待避を削除する

「一時待避を削除する...」では、リストから選んだ項目を削除できる。

・git stash drop <削除したいスタッシュ>

#待避中のスタッシュ一覧を表示
$ git stash list
stash@{0}: ブランチ名: コメントA
stash@{1}: ブランチ名: コメントB


#選択したスタッシュを削除
$git stash drop stash@{0}


#削除後のリストを確認
$ git stash list
stash@{0}: ブランチ名: コメントB

4. 選択した一時待避を復活（削除しない）

「一時待避内容を適用...」では、選択した項目を復活させることができる。

・git stash apply <復活させるスタッシュ>

• 現在のブランチに追加される
• ステージ済みの変更もadd前の状態で戻る
• 戻した待避内容はstash listから削除しない

▼ステージ済み状態で戻す
ステージ済みの変更はステージ済みとして戻したい場合は、--indexをつけて、コマンドで実行する

・git stash apply <復活するスタッシュ> --index

5. 選択した一時待避を復活（削除する）

「一時待避内容を適用して削除...」を実行すると、復活させた後に、stash listから削除する。

・git stash pop <復活させるスタッシュ>

6. 最新の一時待避内容を適用

「最新の一時待避内容を適用」は、直近保存したstash内容を復活する。(stash@{0}。stash listの一番上の項目)

git stash apply
　┗ 「git stash apply stash@{0}」と同じ

applyなのでstash listは削除しない（popは削除する）

7. 最新の一時待避内容を適用して削除

「最新の一時待避内容を適用して削除」は直近保存したstash内容を復活し、stash listから削除する。

git stash pop
　┗ 「git stash pop stash@{0}」と同じ

サブモジュールがある場合

サブモジュールがある場合、左側のカラムの表示が変わる。
メインのレポジトリとサブモジュールとして登録したレポジトリがそれぞれ表示される。

▼各レポジトリ毎に変更とステージの状況が表示される。

各記号の意味

レポジトリ名の横に、複数の記号と数値が表示される。

1. master

現在のブランチ名。
クリックするとブランチの切り替えができる。

2. 円形の矢印

現在のブランチに上流ブランチが設定してある場合に表示される。

クリックすると、状況に応じてpush/pullを実行しリモートと同期する。

▼上流ブランチが設定されていない場合

上流ブランチがない場合は、リモート未同期のマークが表示される。

クリックすると、リモートレポジトリを選択しpushする。
リモートレポジトリには、現在のブランチ名のブランチが自動作成される。

3.　n↓　（数字 ↓）

最新の同期後に、リモートブランチで更新されたコミット数を表示。

ローカルが遅れていることを表す。

例： 「8↓」
　・リモートで８個の新たなコミットあり。
　・同期ボタンをクリックすると、git pullを行う。

4.　n↑　（数字 ↑）

最新の同期後に、ローカルブランチで追加されたコミット数を表す。

ローカルが進んでいることを表す。

例： 「2↑」
　・ローカルに２個の新たなコミットあり。
　・同期ボタンをクリックすると、git pushを行う。

Gitログ

困ったときのGitログ。
vscodeのUIで実行したコードが表示される。

vscodeの右下のウインドウで、出力タブで、Gitを表示した状態。

ウインドウが表示されていない場合、下記で表示することができる。

・vscodeの表示オプションから出力を選択

・command + shift + Uを実行

・アラートの「Gitログを開く」をクリック
実行した処理にエラーがあった場合などに、「Gitログ」を開くのポップアップが表示される。

上から表示される場合と、右下から表示される場合もある。

Gitログのデフォルト表示内容

gitログを見たときに目当てのコマンドがパッと見つからないことがあるが、これは、vscodeでgit操作すると、処理の後に更新処理が自動で行われるため。

ことある毎に下記の表示を目にすることになる。

> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
> git rev-list --left-right master...refs/remotes/origin/master
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template

現在いるブランチで処理内容が若干変わるが、最初と終わりの行は基本同じ。

最初の行

> git status -z -u

終わりの行

> git config --get commit.template

色付きの数字とアルファベットの意味

作業を進めていくと、色付きの数字やアルファベットが表示される。

色付きの数字

一番左の行の青い丸の中の数字は、変更のあったファイルの総数を表している。

「変更」と「ステージされている変更」に表示されているファイルの総数になる。

色付きのアルファベット

各ファイルの横に表示されるアルファベットはファイルの状態を表している。

アルファベット	単語	意味
A	added	新規追加
M	modified	変更あり
U	untracked	gitが未追跡(新規作成、add前)
D	deleted	削除済み
C	conflict	コンフリクト発生中
R	renamed	ファイル名変更済み
S	submodule	サブモジュール

1台のPCでGitHubアカウントを切り替えようとした時にハマったので、その備忘録です。

この記事のゴール

仕事用のPCにプライベート用アカウントのリポジトリをcloneしてpushできるようにする。

切り替えの手順

1. 仕事用のPCにプライベート用アカウントに使うsshキーを作成
2. GitHubに公開キーを登録
3. ~/.ssh/configファイルにプライベート用アカウント用の設定を追加
4. 接続確認
5. git clone
6. git push

1. 仕事用のPCにプライベート用アカウントに使うsshキーを作成

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 4096 -f <YOUR_FILE_NAME> // 今回は例としてprivate_rsaで作っています

// private_rsa と private_rsa.pub が作成される 

2. GitHubに公開キーを登録

$ pbcopy < ~/.ssh/private_rsa.pub

// 公開キーがクリップボードにコピーされる

GitHubのプライベートアカウントのSettingsより公開キーを登録

3. ~/.ssh/configファイルにプライベート用アカウント用の設定を追加

~/.ssh/config

// Host githubはもともと仕事で使って存在していた
Host github
  HostName github.com
  User git
  IdentityFile ~/.ssh/main_rsa

// 以下のHost github-privateを追加する
Host github-private
    HostName github.com
    User git
    Port 22
    IdentityFile ~/.ssh/private_rsa

4. 接続確認

$ ssh -T github-private

// Hi <GITHUB_ACCONT_NAME> You've successfully authenticated, but GitHub does not provide shell access.
// 上記のように返ってくれば接続成功

5. git clone

接続までは成功しているので、 cloneで持ってくる。

@以下の Host名 を先ほど作成したHostにする。

// こちらはエラーになる
$ git clone git@github.com:<ACCOUNT_NAME>/<REPOSITORY_NAME>.git

// こちらはOK 
$ git clone git@github-private:<ACCOUNT_NAME>/<REPOSITORY_NAME>.git

6. git push

local userの登録をする

$ git config --local user.name <プライベートユーザー名>
$ git config --local user.email <プライベートメールアカウント>

$ git push
// pushできる

以上です。
慣れてないと結構ハマりますね。。。

Gitとはそもそも何？

ソースコードを履歴していくツール。といった認識でいました。
で、今回深堀で勉強し直しました。Gitとは、分散型バージョン管理システムである。と言うことだそうです。要は、ファイルのバージョン管理が簡単にできるツールだと書いてありました。
【ここで、バージョンと言う言葉が出てきましたが、聞いたことがありますが何かと問われたら説明できない。と言うそこのあなた！
伝えますよ、ファイルをアップデートしたり更新した時に変化するものです。iPhoneとかで最新バージョンにアップデートするように通知が来るあれです！】
と言うことは、自分の認識は合っていたと言っても過言ではないでしょうか！

Gitはなぜ必要なの？

私は、エンジニアでもなければプログラマーでもありません、ただの（エンジニアを目指し勉強をしている）ニートなので、実際に現場で使われているものを見たことがありませんが（そもそも、現場に入ったことがないので）、ネットの情報を鵜呑みにして必要性を書きます。
【プログラマーにとって、多くのコードを編集した上で何か不具合が起きた時に、元のバージョンへ戻すことは日常茶飯事です。かといって、一つ一つコードの編集の度に古いバージョンの日付や時刻をつけて保存して、また新しい作業をするようなことをしては、時間はかかりますし、人的ミスも増えます。そういった作業を無駄なく、効率的に行うためにGitは必要なんだ。】と記載されてました。
要は、ゲームで言うとこのセーブポイントなのかなと感じましたね。一つのプログラムを作成するために、違う世界線で違う人たちが作り上げていくためのツールなんだと思いました！

では、Gitに関してさらに見ていきます！

リポジトリーって何？

リポジトリーとは、Gitの管理元にあるファイルやディレクトリの変更履歴を保管する箱のようなものです。
で、そのリポジトリーには、ローカルリポジトリとリモートリポジトリが存在します。
ローカルリポジトリは、自分のPC上（ローカル環境）に置くリポジトリのことを指します。自分のPC上にあるファイルやディレクトリのバージョン管理をしたい場合に使用します。
リモートリポジトリは、外部のサーバなどのネットワーク上に置くリポジトリのことを指します。ネットワーク上に置くことで複数人で管理のファイルやディレクトリを共有することができます。複数人で開発を進めていく上では、必要なものです。

ちょっと長くなりますがもうちょっと付き合ってください。すみません?

Gitはわかりました！それを実際に使用する中で、GigHubなるものが存在するとのこと、なんぞやと言うことを調べていきます！

GitHubについて

Gitを利用してチーム開発に便利な機能を提供するWebサービスのことを指します。
要は、Gitのリモートリポジトリの役割を担うものだといった認識でいいのかと考えます。
GitHubを利用することで、自分の作業が他の開発者に影響を及ぼしたり、反対に他の開発者の作業が自分に影響を及ぼすことを避けて開発を進めることができるとても便利なものです。

GitHubDesktopについて

この流れで説明します。GitHubDesktopとは、GitHubが提供しているデスクトップ用のアプリケーションのことを指します。GitHubを直感的に操作しやすくしたツールです。より使いやすくなったものといった認識でいます。

最後に、このGitHubの使用手順を記述して終わります！もうちょっと付き合ってください?

GitHub Desktopの使用手順

①まず、編集を加えるファイルをGitHub Desktopで選択し、名前をつけてブランチを作ります。（ブランチとは、各々が作業する際に、一人ひとりが行う作業場的なものを指します。）

②コードを実際に触っていく作業を行います。

③とりあえず、作業にひと段落があれば、名前をつけてコミットします。（コミットとは、追加・変更したファイルをgitに登録するコマンドです。）

④コミットし終えたら、プッシュを行います。（プッシュとは、ローカルリポジトリで保存を行なったものを、リモートリポジトリに反映させるためのコマンドです。）

⑤コードの内容に間違え等がない場合、マージを行います。（マージとは、ブランチをマスターブランチに結合することを指します。マスターブランチとは、プログラムを作成する大本といった認識です。）
※マージした際に、コンフリクトが起こっていないか表示されます。その際に、コンフリクト起こっている場合、編集を加える必要があります。（コンフリクトとは、例えば、ブランチNo.１で「A」と入力した箇所を、ブランチNo.２では「B」と入力をし、マージを行なった場合に表示されるものです。ブランチNo.1の変更とブランチNo.２の変更をどちらをマスターブランチに結合するかといった状態を指します。）

⑥マージができたら、GitHub Desktopでプルを行います。（プルとは、リモートリポジトリの変更をローカルリポジトリに取り込む操作のことを指します。）
これで一連の流れは終わりです。

まとめ

Git,github,githubdesktopはエンジニアになるには、必須なものなんだと改めて思いました。ならば、もっと勉強をしていこうと思いました。お付き合いいただきありがとうございました！

AWS C9でアプリケーション開発を行う際、SSH接続がgithubとEC2インスタンスでこんがらがった話。

C9上でgit管理している場合
githubをリポジトリとしてssh接続する際は~/environment/.sshフォルダに置いておくと思う（当時無知識だったため、そのままid_rsaという名前にした）
ここで登録する際に名前を例えばid_rsa_githubなどに変更するか、もしくはディレクトリを切ってgithubを指定しておけば後々詰まることもなかっただろう

そして開発がある程度終了し
EC2インスタンスに接続するためのid_rsaを同じフォルダに上書きしてしまっていた

今までgithubにssh接続出来ていたものが、突然Permission denied (publickey).と怒られるようになる

上書きしてしまったのものは仕方ないので、こういった場合はgithubのssh接続を再登録すればOK
その際、ちゃんとディレクトリを切るなり、ファイル名を変更するなりして
.ssh/configファイルの中のパスを指定してあげましょう。

はじめに

タイトルで「おかしい」と書きましたが、正確には「既にマージ済みの内容が差分と表示されている」ということが起きましたのでまとめます。

事象

・developmentブランチからmasterブランチへSquash & mergeした後、別のマージリクエストでmasterブランチへマージしようとしたとき、Squash & mergeした時の内容が差分に表示されている。

・git diff development masterコマンドを打った時も同様に、既にマージ済みの内容が差分として表示される

解決方法

・Squash & mergeをしない

…解決方法、ではないですね。

featureからdevelopmentへ

Gitの運用方法は職場・現場によって様々だと思いますが、多くのところではmaster > staging > development > featureとブランチが切られているのではないでしょうか。

この時、developmentブランチから、個人の開発用・issueブランチとしてfeatureブランチを切って作業をする場合、微修正コミットや、ローカルでは動作が確認できないのでとりあえずPushしてリモート環境で確認するためのコミットを連発してしまった、などでブランチ内のログを荒らしてしまったことはありませんか？僕はあります。

上記のような場合には、GitLabでdevelopmentに向けてマージリクエストを作成する時に、「Squash commits」にチェックを入れてコミットを一纏めにすると同時に、「Delete source branch」にもチェックを入れることでマージ後にはfeatureブランチを削除する、という流れがきれいだと思っており、実際にこの方法で運用しています。

git rebaseでコミットをまとめる方法もありますが、上記のような、①ターゲットブランチに対して新規のコミットである、②全てのコミットが自分だけである、③粒度がそれほど大きくならない、という状況であればSquash & mergeの方が早くて簡単かなと個人的に思っています。

developmentからmaster(staging)へ

個人開発用・issueブランチはマージリクエスト完了後、つまりそのissueを解決した後は削除した方がごちゃごちゃせずに済むかと思います。リモートブランチにはmaster staging developmentブランチが存在し、進行中のfeatureブランチだけが残っている状態が簡潔で良いです。

さて、今度はdevelopmentからmaster(staging)へ向けてマージしたいと思います。featureは都度削除をしていましたが、今回はdevelopmentブランチなので「Delete source branch」にはチェックを入れずに、「Squash commits」だけチェックを入れ、Squash & merghを行います。作成したマージリクエスト上で特にコンフリクトがなければそのままマージしてしまいます。問題なくマージが完了しました。

GitLabのCompareから、developmentとmasterの差分を確認すると、マージしたばかりなので差分もなくきれいな状態になっているハズ…あれ？たった今マージした内容が全て表示されている…だと？

featureブランチは開発が終わる事に削除していたため気づきませんでしたが、Squash & mergeでコミットをまとめてマージした場合、そのまとめたコミットは新規のコミットとして扱われるため、まとめた複数のコミットと中身は同じですが、異なるものとして判定され差分が表示されてしまったのではないかと思っています。

ここら辺が、自分のほうで調べても確定的なことがわからなかったのですが、今回のようなケースはソースコードは全く一緒なので、gitの差分はコミット（ソースコードのスナップショット）で判断しているのではないかと思っています。が、間違えていたらご指摘頂けますと幸いです。

featureの方でSquash & mergeしても良いときの条件を自分なりに書きましたが、developmentからmasterへのマージですと、粒度がかなり大きくなってしまい、内容も様々なものが混ざったコミットが出来上がってしまうので良くないですね。ここは自分でもわかっていたはずなのですが、今回やらかしてしまいました…反省ですね。

ちなみに、試験的に、今回のような既にマージ済みの内容が差分として表示されている状態で、強制的にマージしてみましたが、問題なく新規の変更点だけが変更された形になっていました。ただし、差分は依然として残り続けます。

まとめ

・developmentブランチのような、常に残り続ける大きなブランチからmasterブランチなどへのマージの際は、Squash & mergeをしないようにした方が良い