「GitHubにリポジトリを作ったぞ～さっそくSourceTreeでクローンするぞ！」と意気込むが、

「なにこれ……」となり解決するのにだいぶ時間がかかったので解決方法を記録。

※Windows版 SourceTree のバージョンが2.5.5のときの情報です。

エラーの原因

GitHub と SourceTree の間で通信する際、「SSHキー」という鍵でファイルを暗号化する必要があります。
SourceTree をインストールしたばかりのときはその鍵がないので通信ができず、エラーになっていました。

というわけで、SSHキーを作り、GitHub と SourceTreeに「この鍵で暗号化してね！」と教えることでクローンができるようになります。

手順

SourceTreeでSSHキーを生成

1. SourceTreeを起動します。
2. メニューの「ツール」→「SSHキーの作成/インポート」をクリックして「PuTTY Key Generator」ウィンドウを出します。
   
3. 一番下の「Parameters」を次のように変更します（上記画像と同じならそのままでOK）。
   • Type of key to generate: RSA
   • Number of bits in a generated key: 2048
4. 「Actions」の「Generate」をクリック
5. 緑のバーが出るので、ウィンドウの中でマウスを適当に動かします。
   
   • バーの上にある "Please genarate some randomnss by mobing the mouse over the blank area." に書いてあるように、マウスの座標を乱数として鍵を生成しています。
   • 英語を読もうとせず「生成に時間がかかるんだろうな～」と1時間放置したのは私ですorz
6. 緑のバーがいっぱいになると鍵の生成が完了します。
   
   • 一番上の黒塗りの部分に公開鍵が表示されます。
   • 「Key Comment」はそのまま鍵の名前みたいなものです。
     • 分かりやすいのにしてもいいですし、デフォルトのままでもいいです。
   • 「Key passphrase」と「Confirm passphrase」はパスフレーズです。入力するとプッシュやフェッチの度にパスフレーズを入力することになり、面倒になるため空欄のままでいいです。
7. 公開鍵をGitHubに登録するため、メモ帳などにコピペしておきます。
8. 「Save private key」をクリックし、任意の場所に保存します。
   • 拡張子：*.ppk

GitHubに公開鍵を登録

1. GitHubの設定画面にアクセスします。
2. 右上の緑のボタン「New SSH Key」をクリック。
3. 入力画面に移るので、下記を入力します。
   • 「Title」: 分かりやすい名前をつけます（ここでは「Key Comment」と同じにしました）
   • 「Key」: SourceTreeで生成した公開鍵をコピペします。
4. 「Add SSH Key」をクリック。

SourceTreeに秘密鍵を登録

1. SourceTreeの「ツール」→「SSHエージェントを起動...」をクリック
   • 一見何も起こりませんが大丈夫です。
2. タスクバーに「帽子を被ったパソコンのようなアイコン」が出ているので、タブルクリック
   
3. 「Pageant Key List」ウィンドウが出るので「Add Key」をクリック
4. 先程保存した秘密鍵(*.ppk)を選択します。
5. 「開く」をクリック

これでクローンの準備ができました。

GitHubからリポジトリのアドレス取得

1. クローンしたいリポジトリのwebページを開きます。
   • 「https://github.com/ユーザー名/リポジトリ名」の形式になっているURLです。
2. 右の緑のボタン「Clone or download」をクリック
3. 「Clone with SSH」と書かれていることを確認して「git@github.com:ユーザー名/リポジトリ名」となっている部分をコピー
   • 「Clone with HTTPS」の場合はすぐ右隣の「Use SSH」をクリックで「Clone with SSH」に変更されます。

SourceTreeでクローン

1. SourceTreeのタブの「+」ボタンで「New tab」を開きます。
2. 左から3つ目の「Clone」をクリック。
3. 上から1つ目の入力欄に先程GitHubでコピーした文字列を貼り付けます。
4. 「これはGitリポジトリです」と表示されることを確認
   • 表示されない場合、コピペし直す、SSHエージェントをもう一度起動してみるなどを試す
5. 2つ目の入力欄にパスを指定します。
   • これがローカルリポジトリになります。
   • 基本的にはデフォルトのままで大丈夫です。
   • Dドライブだったり既にファイルが入っているフォルダだとエラーになります。
6. 3つ目の入力欄へSourceTreeのタブに表示される名前を設定します。
7. 「クローン」をクリック

やっておくべきSSHエージェントの設定

以上の方法でクローンはできますが、このままではプッシュ・プルをするときに毎回秘密鍵を読み込ませる必要があります。
面倒なので下記の設定を行います。

1. SourceTree メニューの「ツール」→「オプション」で「オプション」画面を表示します。
2. 「全般」タブの中央「SSH クライアントの設定」の各項目を次のようにします。
   • SSHキー: 秘密鍵が保存されている場所のフルパス
   • SSH クライアント: PuTTY/Plink
   • 「SourceTree起動時にSSHエージェントを起動」にチェック
3. 「OK」をクリック

SSHエージェントは常駐させること！

上記の設定でSourceTreeを起動するとSSHエージェントが起動するようになりましたが、
間違えてSSHエージェントを終了させても再起動はしてくれません。
もう一度起動させるには「ツール」→「SSHエージェントを起動...」から行えます。

ファイルサーバーの共有フォルダにリモートリポジトリを置く場合、

ファイルサーバー側

リポジトリ用のフォルダを作成して、ベアリポジトリを生成

$ git init --bare myproject.git

クライアント側

クローンする場合

$ git clone //fileserver/repo/myproject.git

元々あるローカルリポジトリをリモートに接続する場合

$ git remote add origin //fileserver/repo/myproject.git

経緯

新人の子が作成したプロジェクトをGitで管理できるよう設定していたときのこと。

GitLabのアカウントを作成してもらう
グループに招待
GitLabに公開鍵を設定 ← ココ

sshの鍵を作成し、
公開鍵をGitLabに登録しているときだった。

「その鍵で何が開くんですか・・・？」

・・・（・v・）？？

「そもそもsshって・・・？」

・・・・・・（・v・）？？

私氏 「なんだっけねーーー（爆死）」

これ使ったらssh「というもの」ができてGitLabやGitHubに接続できる

となんとなく漠然と「そういうもの」として捉えていたため
ちゃんと考えることなく過ごしていたことを深く反省し今に至る

そもそもsshってなんだっけ？

sshとは

Secure Shell（セキュアシェル、SSH）は、暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。

参照：Wikipedia

ざっくり訳してみると「他のコンピューターと通信（アクセスしたり、操作する）するときに
安全に接続できるシェルですよ」ということ

どう安全？

他のプロトコルとしてはtelenetというものがあるのだが、こんな感じに違う。

ssh ←暗号化されている
telenet ←暗号化されていない

暗号化されていない従来のプロトコルでは他のコンピューターとの通信をみられてしまう危険がある。
なので暗号化されているsshが安全といわれているのだ。

GitLabの導入になぜssh？

今回はGitLabだしたが、GitHubでも同じで
元をただすと「Gitのソース管理のできるWebサービス」なのである。

GitLabでソース管理をするということは
GitLabのデータベースに対して自分のコードを送っているということだ。

まさに、「他のコンピュータにアクセス」している状態なのである。
ここで安全でに接続するためのsshが用いられるのだ。

秘密鍵？公開鍵？公開鍵認証とは？

sshの接続の際の認証方法にはパスワード認証と公開鍵認証があり、
今回は公開鍵認証というものを使用したため秘密鍵と公開鍵が必要であった。

ここで、とんでもなくスペシャルにわかりやすく説明されているサイトを投下。
百聞一見にしかず。図を含めた説明がとんでもなくやさしい。

Adminweb 共通鍵暗号と公開鍵暗号の解説とSSHでの認証手順

今回のパターン

• 自分のコンピュータで秘密鍵と公開鍵を作成
• GitLaboに公開鍵を設定

公開鍵で暗号化されたものは秘密鍵でしか復号化できないため
GitLabに設定してある公開鍵の秘密鍵を持つ者にしか接続ができないということになる。

これでGitLabにssh接続する際に秘密鍵を持っていれば
パスワードを打ち込む必要なくスムーズに接続することができるのだ！

最後に

どうもローマ字3文字か4文字（いや、長くても短くてもか・・）の
sshやらsslやらhttpsやらが苦手で仕方ない。
「なんとなくこんなかんじっしょ！」というのが多いのでひとつずつ整理していきたいものだ。

完成図がこちら。

はじめに

git logを見やすくする方法としては
git log を見やすくする - Qiita
などでも紹介されていますが、git logのオプション整理と勉強も兼ねて、せっかくなので自分でしっくりくるフォーマットにまとめて見ました。

git log にくっつけるオプションたち

コマンド全体はこちら。

$ git log --all --date-order --date=format:"%Y-%m-%d" --graph --format=" <%h> %ad [%an] %C(green)%d%Creset %s"

使用したオプションたちは以下になります。

--all

全ブランチを表示する。

--date-order

コミット順で表示する。
(デフォルトは親子関係を元に表示順が決定される。)

--date=format:"<format>"

dateを指定フォーマットで表示する。

• %Y : 西暦4桁
• %y : 西暦2桁
• %m : 月2桁
• %d : 日2桁

その他のプレースホルダーはgit help logでご確認ください(丸投げ)。

--graph

コミット履歴をラインで結んで可視化する。

--format="<format>"

コミットログの各情報の表示/非表示やフォーマットを指定する。

• %H : コミットハッシュ
• %h : コミットハッシュ(短縮版)
• %ad : Authorの日付
• %an : Authorの名前
• %d : HEADとブランチ
• %s : コミットメッセージ(の１行目)
• %C(<color> <style>) : 表示色のフォーマットを指定する。
  • <color> : normal, black, red, green, yellow, blue, magenta, cyan, white
  • <style> : bold(太字), dim(減光), ul(下線), blink(点滅), reverse(反転)
• %Creset : 指定した表示色を解除してデフォルトにする。

その他のプレースホルダーはgit help logで略。

aliasに登録

無限回使用するのでaliasに登録しておくと便利です。

git config --global alias.tree 'log --all --date-order --date=format:"%Y-%m-%d" --graph --format=" <%h> %ad [%an] %C(green)%d%Creset %s"'

あとはgit treeとするだけで↑が実行されます。
<format>を極めて僕の/私の考えた最強のtreeコマンドを作ろう！

オチ(蛇足)

そもそも何でこんなこと調べることになったかと言うと、
PC更新にあたってgitのconfigもお引越ししようと思ったのですが、
git config --globalをはじめどこを見てもtreeのaliasが見当たらない、という(しょーもない)ことがキッカケでした。
そもそも息を吸うように使っていたので完全にgit for windowsのデフォルトコマンドだと思い込んでいました。

しかも、確かに冒頭の記事を参考にしたはずなのですが、何故か自分の使用していたフォーマットと微妙に異なる(冒頭の図)。

昔のことすぎて何も思い出せないので、この際一から調べて同じフォーマットを再現しよう、ということになりました。

オチ(隙を生じぬ二段構え)

試しに旧PCでgit help treeと叩いたら

'tree' is aliased to 'log --graph --date-order -C -M --pretty=format:"<%h> %ad [%an] %Cgreen%d%Creset %s" --all --date=short'

と吐き出しました。
一体、いつ、誰が、どこに定義したんだ。。。

諸々調べてた時間とは
改めてmanualページなどをちゃんと読む良い機会になりました。

参考

git help log(manualページ)
git log を見やすくする - Qiita
git logを時間順にソートする
GoogleCloudPlatform/nodejs-docs-samples

経緯

ずっと使っていなかった昔のlinuxマシンでgithubにpush使用としたらerror:1407742Eが起きた。

環境

VineLinux6.1
git1.7
git version 2.2.1

対処法

gitのバージョンが古かったので、アップデートをした。

まずは、既存のgitを削除した

sudo apt-get remove git

make時にエラーが起きないように以下のパッケージをインストールしておく

sudo apt-get install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

インストールしたいgitをダウンロードし、解凍したあとにディレクトリを変更

sudo wget https://www.kernel.org/pub/software/scm/git/git-2.22.0.tar.gz
tar zxvf git-2.22.0.tar.gz
cd git-2.22.0

ビルドとインストール

make prefix=/usr/local all
make prefix=/usr/local install

もし、makeコマンドで以下のエラーが出るようなら

/usr/bin/ld: BFD version ~

以下のコマンドでインストールしてから再度実行すればできた

sudo apt-get install binutils

まとめ

突貫工事で対処してきたので、まちがっているかもしれない

この記事は何？

Xcode Help ドキュメントより、Use Source Control を要約

環境

• Xcode11 beta
• macOS Mojave 10.14.6

手順

ファイルをバックアップし、他のユーザーと共同作業し、リリースにタグを付けるには、ソース管理を使用します。

Step1: ローカルリポジトリを使う

新しいプロジェクトまたは既存プロジェクト用のローカルソース管理リポジトリを作成できます。
後で、プロジェクトを共有したり、複数のMacコンピュータからプロジェクトにアクセスしたりするには、リモートリポジトリを作成できます。

Step2: リモートリポジトリを作成する

「アカウント」環境設定で、以下のリモートリポジトリアカウントを追加できます。
- Bitbucket
- GitHub
- GitLab

新しいリモートリポジトリを作成したい場合は...
ローカルのソースコードリポジトリからリモートを作成してください。
既にリモートリポジトリが存在する場合は...
リモートリポジトリからプロジェクトを複製するか、既存リモートをローカルリポジトリに追加します。

Step3: 変更のプル、コミット、プッシュ

プロジェクトに変更を加えたら、ソースエディタで変更を確認するか、ファイルのリビジョンを比較します。
次に、変更をソースコードリポジトリにコミットします。
リモートリポジトリの場合は、コミットする前にリモートリポジトリから変更をプルし、コミットした後にその変更をプッシュします。

Step4：リポジトリとコミットを表示する

ソース管理ナビゲータで、リポジトリ内のブランチを選択し、履歴エディタでコミットを表示します。

ここでは他にも以下のアクションが可能です。
- コミットをフィルタリング
- 比較エディタでファイルを表示
- コミットの作成者に電子メールを送信

Step5：ブランチを管理してタグを使用する

リポジトリにブランチを作成すると、自分の変更を分離して他の人に影響を与えないようにできます。
後から、リポジトリ内で分岐したブランチをマージします。
ブランチでコミットをタグ付けして、後で簡単にチェックアウトすることもできます。
特に、アプリを配布する前はコミットにタグを付けてください。
また、Tagsフォルダにグループを作成してリリースを整理することもできます。

参考: ソース管理を構成する

要するに

ソースをバーション管理するには...

• まず、リポジトリを作る
• 後からリモート化もできる

リポジトリに変更をコミットするときは...

• コミットする前に、過去の変更をプル
• コミットした後に、新しい変更をプッシュ

複数人でソース管理する場合は...

• ブランチを作る
• ブランチは、後でマージする
• ブランチにタグをつけておくと、チェックアウトするときに目印になる

バージョン管理をはじめる方（自分）に

まずは、リモートではなくローカルで行うことから始めるといいでしょう。
GitHubやbitbucketなどのリモートは使わずに、Git単体で...
1. リポジトリ作成
2. 変更→コミット
3. ブランチ作成
4. チェックアウト→変更
5. マージ

を実践して、理解できたらリモートを作成してみる感じです。
XcodeはGUIでGitをサポートしているので、ターミナルから難しいコマンドを覚えたり入力する必要がありません。
意外とすんなりバージョン管理をはじめられる気がします。

環境

macOS: 10.14.4

事象

git commit
git rebase -i HEAD~3
などを行った際に下記エラーが発生。

hint: Waiting for your editor to close the file... error: cannot run : No such file or directory
error: unable to start editor ''

解決方法

.gitconfigの設定を修正することで解決。

手順

# .gitconfigの内容を確認
$ less ~/.gitconfig

# 設定変更（他のリポジトリでも使いたいのでグローバルで良いかと）
$ git config --global core.editor vi

# .gitconfigが変更されていることを確認
$ less ~/.gitconfig 

Gitの最後のプッシュを取り消す

準備

何かあった時に取り戻せるように、処理したいブランチをbackupすること

操作

git reset --hard HEAD^
git push -f origin master

参考にした記事

http://www-creators.com/archives/2020#git_push

ある日の弊社

ワイ「ああ、昨日までにReactの環境構築をせなあかんかったのに、Elmで遊んでもうた・・・」
ワイ「環境構築できてへん・・・」

イケメン君（後輩）「やめ太郎さん、僕が構築しておきましたよ！（キラッ）」

ワイ「おお・・・！おおきにやで」
ワイ「（中身までイケメンやん）」
ワイ「（鼻につくわぁ・・・）」

リーダー「（やめ太郎、相変わらずクズやな・・・）」

コンポーネント作り開始

ワイ「よっしゃ、そしたら次はコンポーネント作りや」
ワイ「ワイはReactよう分からんから北海道支社の新人君にお願いしよか」
ワイ「早速Slackでお願いや」

ワイ「おーい、北海道新人くん」
ワイ「Reactの環境構築しといたから」
ワイ「北海道新人くんは、コンポーネントの作成を頼むで！」
ワイ「サンプルとしてExampleっていうコンポーネントを（イケメン君が）作ったから」
ワイ「それを元に頼むわ！」

ワイ「よっしゃ、送信、と」

北海道新人くん「了解です！」
北海道新人くん「React案件はじめてなので、まずはExampleコンポーネントを色々いじってみますね！」

ワイ「うむうむ」
ワイ「よっしゃ、ワイはElmでもやろか」

ところが

リーダー「おい、やめ太郎」
リーダー「ディレクトリ構成はAtomic Designを参考にしろっていうたのに」
リーダー「全然なっとらんやんけ」

ワイ「（そういえばそんなこと言ってはった・・・！）」

イケメン君「この構成の方がいいじゃないですか！（キラッ）」

リーダー「ぐぬぬ」

ワイ「わ、分かりましたで」
ワイ「ワイがディレクトリ構成を修正しておきますわ」

ディレクトリ再構成開始

ワイ「ええと、ほなExampleコンポーネントのファイル一式は」
ワイ「atomsっていうディレクトリに移動させて、と」
ワイ「これでGitコミットや」
ワイ「ポチッ、と」

ワイ「しまった！！！」

ワイ「そういえば北海道新人くんが」

北海道新人くん「Exampleコンポーネントを色々いじってみますね！」

ワイ「って言うてたやん・・・！」
ワイ「なのに、Exampleコンポーネント関連のファイルを移動してGitコミットしてもうた・・・」
ワイ「これはGit君がマージしたときに、Exampleコンポーネントが2つに増えてまう感じか・・・？」
ワイ「めんどくさいわぁ・・・」
ワイ「どないしよか・・・」
ワイ「とりあえずElmでも勉強しよか・・・」

リーダー「（他言語の勉強！？今！？）」

1時間経過

ワイ「やっぱElmはシンプルに書けてええなぁ・・・」

リーダー「（ほんまに他言語の勉強してるやん・・・）」

ワイ「・・・そんでReactのコンポーネントの件、結局どうなったんやろ」
ワイ「SourceTreeでリポジトリを覗いてみよか」
ワイ「あ、北海道新人くんがExampleコンポーネントを修正した分がコミットされてる・・・」
ワイ「やっぱExampleコンポーネントは2つに増えてもうたんやろか・・・？」

ところが

ワイ「！？」
ワイ「2つに増えてへんわ・・・！」
ワイ「Exampleコンポーネントに、ちゃんと北海道新人くんの修正も反映されとるし」
ワイ「ちゃんとディレクトリも移動しとる・・・！」
ワイ「そんなところまで上手いことマージしてくれるんか・・・！」

結論

Gitドチャクソ有能でした。

目的

• 外部サーバにあるソースコードをbitbucket経由でローカルリポジトリにいれる
• 既存のリモートリポジトリ(git cloneしてきたリポジトリ)を変更

前提

• リモートリポジトリ作成済み
• ローカルリポジトリとすでに同期済み
• 外部サーバのソースコードフォルダは別のリモートリポジトリで管理されていた
• 外部サーバのソースコード優先
• ローカルで変更したものは無視していい

外部サーバで

git管理されているかどうか確認

$ git status
# On branch master
# 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)

リモートリポジトリのURLを確認

$ git remote -v
origin  git@bitbucket.org:hogehoge/hugahuga.git (fetch)
origin  git@bitbucket.org:hogehoge/hugahuga.git (push)

リモートリポジトリを変更

$ git remote set-url origin https://piyopiyo@bitbucket.org/piyopiyo/nyaanyaa.git
$ git remote -v
origin  https://piyopiyo@bitbucket.org/piyopiyo/nyaanyaa.git (fetch)
origin  https://piyopiyo@bitbucket.org/piyopiyo/nyaanyaa.git (push)

コミットしてpushします

$ git push origin master
Password for 'https://piyopiyo@bitbucket.org': 

httpsなのでpasswordが必要（外部サーバなので結果オーライ）

To https://piyopiyo@bitbucket.org/piyopiyo/nyaanyaa.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://piyopiyo@bitbucket.org/piyopiyo/nyaanyaa.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

リモートリポジトリにはすでにローカルで行なっていた変更が記録されているため、マージか強制上書きしないといけないようです

なので強制上書き-fオプションをつけてpush

$ git push -f origin master

今度はうまくいきました

ローカル（自分のマシン）で

$ git pull
remote: Counting objects: 422, done.
remote: Compressing objects: 100% (213/213), done.
remote: Total 422 (delta 196), reused 422 (delta 196)
Receiving objects: 100% (422/422), 1.60 MiB | 1.13 MiB/s, done.
Resolving deltas: 100% (196/196), done.
From https://bitbucket.org/piyopiyo/nyaanyaa
 + a38b3bb...dabba87 master     -> origin/master  (forced update)
fatal: refusing to merge unrelated histories

エラーになってしまったので--allow-unrelated-historiesをつけてpullします

(base) kawaduzakura:egrabase sakamotomika$ git pull --allow-unrelated-histories

通りました

これからは外部サーバでソースコードを変更してもリモートリポジトリとローカルで同期できます

向き間違えないようにしないと（汗

はじめに

個人用と職場や研究室用でGitHubアカウントを複数持つ場面は往往にしてあると思う．そして，サブアカウントを使っているときにエラーが出ることが多いので，サブアカウントでのinitからPRまでの流れを記事にまとめたいと思う．

gitリポジトリを始める

gitで管理したいディレクトリにて以下のコマンドを入力

command-line

$ git init
Initialized empty Git repository in /Users/.../<git_manage_directory>/.git

$ git config --local user.name "Your Name"
$ git config --local user.email you@example.com

Your Nameとyou@example.comはについてはサブアカウントで使ってるものを使用する．
git config --localでディレクトリ単位でユーザーを指定できる．
また，.gitignoreファイルを作成し，gitの管理に反映させたくないファイルを記載する．

.gitignore

.vscode/
.DS_Store

ディレクトリをコミットするまで

command-line

$ git add -A
$ git commit -m "first commit(コメントはなんでも良い)"
 [...]
 13 files changed, 200 insertions(+)
 create mode 100644 .gitignore
 [...]
 create mode 100644 requirement.txt

GitHubにコードをプッシュする

https://github.com/new にてRepository nameを入力し，Create repositoryをクリックする．


Create repositoryをクリック後出てくるページにしたがって以下のコマンドを入力しても失敗する．

command-line

$ git remote add origin https//github.com/<sub_username>/my-page.git
$ git push -u origin master
remote: Permission to <sub_username>/mypage.git denied to <main_username>.
fatal: unable to access 'https://github.com/<sub_username>/my-page.git/': The requested URL returned error: 403

この部分を以下のコマンドにすればエラーなくGitHub上にコードが反映される．

command-line

$ git remote add origin https://<sub_username>@github.com/<sub_username>/my-page.git
$ git push -u origin master
[...]
To https://github.com/<sub_username>/my-page.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

ただし，一度以下のコマンドを入力するとエラーが起きる．

command-line

$ git remote add origin https//github.com/<sub_username>/my-page.git
$ git remote add origin https://<sub_username>@github.com/<sub_username>/my-page.git
fatal: remote origin already exists.

これはoriginを一度削除すると解決する．

command-line

$ git remote rm origin
$ git remote add origin https://<sub_username>@github.com/<sub_username>/my-page.git
$ git push -u origin master
[...]
To https://github.com/<sub_username>/my-page.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.