ブランチが master とそこからブランチを切った devブランチがあるとします。
例 : devブランチを作業しながら master に適用されたアップデートを取り込む方法です。
・「フェッチ」をクリックして取り込む
・ブランチ「dev」をダブルクリックしてチェックアウトする
・「マージ」をクリックしてマージするコミットを選択(オプションも合わせて選択)してマージを実行する
(現在の作業ブランチは dev とします。)
# origin を更新
git fetch origin
# 作業中ブランチへ master を取り込む
git merge origin/master
# 作業中ブランチへ master を取り込む(必ずマージした履歴を残す場合)
git merge --no-ff origin/master
git rebase -i コマンドは、インタラクティブリベースを実行するためのコマンドです。
これは、コミットの履歴を再整理し、コミットメッセージを変更したり、コミットを結合したり、
不要なコミットを削除したりするために使用されます。
git rebase -i HEAD~2
以下のように表示されます。
pick f1e2d3f 初めのコミットメッセージ
pick a4b5c6g 次のコミットメッセージ
操作としては以下の記述のどれかを指定します。
pick:そのままコミットを使う
reword:コミットメッセージを変更する
edit:コミットを変更する
squash:前のコミットに結合する
fixup:前のコミットにメッセージなしで結合する
drop:コミットを削除する
2つ前のコミットを edit にします。このコミットを変更することができるようになります。
pick f1e2d3f 初めのコミットメッセージ
edit a4b5c6g 次のコミットメッセージ
[esc] + wq!
で保存してviエディタを終了します。
git commit --amend -m "修正したコミットメッセージ"
または edit の 代わりに reword とすると、その場でコミットメッセージを変更することができます。
pick f1e2d3f 初めのコミットメッセージ
reword a4b5c6g 次のコミットメッセージ
git log --oneline
git push --force-with-lease origin ブランチ名
下記のように指定ファイルとフォルダを表示する設定を変更します
1. VSCode のメニューから File (または ファイル) > Preferences (または 設定) > Settings を選択します。
2. 左側の検索バーに「files: exclude」と入力します。
3. Files: Exclude 設定のリストから .git フォルダが含まれているか確認し、もし含まれている場合はそのチェックを外します。
GitHubのDependabotを活用して、npmやcomposerなどのパッケージの脆弱性を監視し、通知を受け取る設定は次のように行えます。
なお、脆弱性データベースはこちらを参照しています。
リポジトリのSettings > ( Security ) Code security and analysis を選択し
「Dependabot alerts」
「Enable Dependabot alerts」と「Enable Dependabot security updates」の両方にチェックを入れます。
オプションの説明はこちらです。
Settings > Security > Code security and analysis > Dependabot alerts で通知設定を行います。
「Add advisors...」から通知を受け取る対象のメンバーやTeamを追加
「Add more paths」から監視対象のディレクトリ(package.jsonがある場所)を指定
デフォルトでは脆弱性が見つかった際に新しいアラートが作成されたときにメールが送信されます。
curl -s \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer YOUR_TOKEN" \
https://api.github.com/repos/OWNER/REPO/dependabot/alerts \
> alerts.json
YOUR_TOKEN , OWNER , REPO は適宜設定してください。
あとは jq で好きなように整形できます。
.github/workflows/dependabot-alerts.yml
name: Dependabot Alerts to Slack
on:
schedule:
- cron: '0 0 * * *' # 毎日実行(必要に応じて調整)
push:
branches:
- main # メインブランチにプッシュされたときに実行
jobs:
dependabot_alerts:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3 # Node.js 20対応
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '20'
- name: Fetch Dependabot alerts
id: fetch_alerts
run: |
curl -s \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer ${{ secrets.DEPENDABOT_PAT }}" \
https://api.github.com/repos/${{ github.repository }}/dependabot/alerts \
| jq '.' > alerts.json
count=$(jq length alerts.json)
echo "count=$count" >> $GITHUB_ENV
echo "Number of alerts: $count"
- name: Debug JSON
run: cat alerts.json
- name: Send to Slack
run: |
<加工してslackに送信するスクリプト>
以下のシークレットが必要なので、プロジェクトの「Settings」 → 「Secrets and variables」 から登録します。
DEPENDABOT_PAT: パーソナルアクセストークンをGithubの対象プロジェクトのシークレットに登録します。
SLACK_DEPENDABOT_WEBHOOK_URL: SlackのフックURLを発行してGithubの対象プロジェクトのシークレットに登録します。
git reset --soft HEAD~
git reset --hard HEAD~
git log -1 --format=%cd
// Fri Jan 19 16:15:35 2024 +0900
git log -1 --format=%cd --date=short
// 2024-01-19
git log -1 --format=%cd --date=format:'%Y-%m-%d %H:%M:%S'
// 2024-01-19 16:15:35
https://github.com/Nutlope/aicommits
npm install -g aicommits
https://platform.openai.com/account/api-keys
aicommits config set OPENAI_KEY=<your token>
設定が完了するとホームディレクトリに .aicommits というファイルが作成されます。
git add -A
aicommits
オプションなしの aicommits を実行すると、コミットメッセージの候補を1つだけ表示してこれでいいか Yes , No で聞いてきます。 よければ Yes を選択するとコミットされます。
--type conventional
(または)
-t conventional
以下のようなメッセージになります。
style: Remove unnecessary gap in Header module
feat: allow provided config object to extend other configs
Conventional Commits
https://www.conventionalcommits.org/en/v1.0.0/
以下のようにすると 3件の候補を出してくれます
--generate 3
(または)
-g 3
aicommits --generate 3 --type conventional
スニペットに入れるか、シェルのコマンドにしておくと良いでしょう。
git fetch --tags
git tag --list 'staging-*' | sort -V | tail -n 1
以下の手順で用意します。
1. GitHub Actionsのワークフロー作成: リポジトリの.github/workflows/ディレクトリ内にワークフローファイル(例:deploy-staging.yml)を作成します。
2. トリガーの設定: on セクションで、push イベントとタグの名前を指定します。例えば、staging-* のようなパターンを使用できます。
3. ジョブの定義: デプロイプロセスを実行するジョブを定義します。この中に、必要なステップ(例えば、ソースコードのチェックアウト、依存関係のインストールなど)を含めます。
4. サーバーへのSSH接続: デプロイスクリプトをサーバー上で実行するためには、GitHub ActionsからサーバーへのSSH接続が必要です。これには、SSHキーを用いて認証を行います。
5. デプロイスクリプトの実行: SSH接続を確立した後、リモートサーバー上でデプロイスクリプトを実行します。
6. セキュリティ: セキュリティを保つために、秘密鍵はGitHubのSecretsに安全に保存し、ワークフローで使用します。
cd .github
mkdir workflows
vi workflows/deploy-staging.yml
.github/workflows/deploy-staging.yml
GitHubのレポジトリのトップから「Settings」直下の Default branch から変更します。
すでに main ブランチでコミットがある場合は以下のようにしてローカルもリネームします
git branch -m main develop
git fetch origin
git branch -u origin/develop develop
git remote set-head origin -a
GitHubのレポジトリのトップの「Settings」 →「Branches」から「Add branch protection rule」をクリックします。
ブランチ名「main」を入れて保存します。
これで main から develop にマージを行った時の main ブランチ自動削除は無くなります。
""GitHub Team or Enterprise organization account. が必要です""
ローカルリポジトリへタグ (v1.0.0) をつける
git tag v1.0.0
リモートリポジトリへつけたタグをpushする
git push origin v1.0.0
「ローカルリポジトリ」・「リモートリポジトリ」のタグ『v1.0.0』を削除するには
git tag -d v1.0.0
git push -d origin v1.0.0
以下の順番でおこないます
・ ローカルリポジトリのタグを削除
・ リモートリポジトリのタグを削除
・ ローカルリポジトリ笑タグをつける
・リモートリポジトリへつけたタグをpushする
大きく分けて以下の3つあります。今回は改行の扱いを .gitattributes で指定します。
・バイナリファイルの diff を表示する
・改行文字の扱いを設定する
・Linguist の扱いを設定する
プロジェクトのトップに .gitattributes ファイルを以下の内容で保存します。
* text=auto
*.txt text
*.bat text eol=crlf
*.php text eol=crlf
*.js text eol=lf
*.jpg binary
*.png binary
*.gif binary
*.mp4 binary
.bat と .php を CRLFにします。
.js をLF に指定します。
Linuxのシェルの改行コードがLFではないと、実行できません。
逆にWindowsのコマンドスクリプトの改行コードがCRLFではないと、実行出ません。
.gitattributes で改行コードを指定する
以下のように設定すると、clone や pull したときは CRLF にして push するときに LF にすることができますが、 拡張子ごとに細かい指定はできません。
git config --global core.autocrlf true
mkdir -p ~/.config/git
vi ~/.config/git/ignore
例えば、以下のように、グローバルで除外したいファイルやディレクトリを記述します
.DS_Store
.idea/*
/github subscribe list features
/github subscribe owner/repository
・Github ログイン
↓
・Settings
↓
・Developer Settings
↓
・Personal Access Tokens
↓
・Toikens(classic)
こちらからトークを作成してクリップボードにコピーします。
あとは
git clone https://..........
で。 最初にメールアドレスとパスワードを入力させられるので、そこにメールアドレスと先ほどコピーしたトークンを入力します。
https://chrome.google.com/webstore/detail/vs-code/kobakmhnkfaghloikphojodjebdelppk/related?hl=ja
これをインストールして、GitHubのリポジトリーを表示した上で「.」(ドット) を押すとブラウザ内にvscodeが立ち上がります
その他便利な拡張 GitHub上でのコードレビューに使えそうなChrome拡張をいくつか試してみた | DevelopersIO
# ディレクトリ全体を除外
/logs/*
# このファイルは git 管理する ↓
!/logs/2022_04_27_14_16_47.log
ユーザー名を確認する
git config user.name
メールアドレスを確認する
git config user.email
ユーザ名を設定する箇所は以下の3つがあります
レベル | 影響範囲 | 設定ファイルパス | コマンドオプション |
---|---|---|---|
system | システム上の全ユーザー | /etc/gitconfig | --system |
global | 該当ユーザー | ~/.gitconfig | --global |
local | 該当リポジトリ | .git/config | --local |
git config --global user.name
git config --system user.name
git config --local user.name
設定してない場合は何も表示されませんのでこちらのコマンドからどこに設定があるのかを発見することができます
git stash save
// コメントをつける場合は以下のように後ろにつけます
git stash save "stash01"
// git add していない(ステージ上にない)ファイルも全て stash します
git stash -u
(退避を行ったときのコミットIDが表示されます。ファイル一覧は表示されません。)
git stash list
git stash apply stash@{0}
git status -uall
# 鍵の作成
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa__deploy_from_gitlab_cicd
# 公開鍵
cat ~/.ssh/id_rsa__deploy_from_gitlab_cicd.pub
# 秘密鍵
cat ~/.ssh/id_rsa__deploy_from_gitlab_cicd
表示される公開鍵、秘密鍵をクリップボードにコピーしておきます
cd .ssh
vi authorized_keys
(ここでviから先ほどクリップボードにコピーした鍵をペーストする。)
(例)例えば次のように設定すると
command="echo 'SSH OK!!!'; pwd" ssh-rsa AAAAB3NzaC1yc2EAAAA...........(省略)...........== Gitlab_CICD
SSH接続するとコマンドを実行してすぐ切断されます。
(実行例)
SSH OK!!!
/var/www/vhosts/my-host.com
これを使ってデプロイするコマンドを記述しておきます。
例) .bash_profileを読み込んでパスを設定した後、deploy.sh を実行する場合
command="source ~/.bash_profile; echo '' ; echo '● SSH Command Start ↓' ; sh deploy.sh ; echo '● SSH Command End ↑' ; echo''; " ssh-rsa AAAAB3NzaC1yc2EAAAA...........(省略)...........== Gitlab_CICD
deploy.sh の内容は好きに作成してください。
設定後にssh正しく接続できるか確認します
(コマンド例)
ssh -tt <ユーザー名>@<サーバIP> -p <ポート番号> -i ~/.ssh/id_rsa__deploy_from_gitlab_cicd
グループかプロジェクトの「Settings」→「CI/CD」→「Variable」から「Add Variable」をクリックします。
次のような設定で作成します
Key : id_rsa__deploy_from_gitlab_cicd
Value : <先程のコピーした秘密鍵>
Type : File
合わせて「SSH_IP_ADDRESS」「SSH_USER」に変数を設定しておいても良いでしょう。
管理画面から編集します。 編集が完了すると対象のリポジトリの .gitlab-ci.yml に保存され、 Job が1つ実行されます。
YML ファイルサンプル
(build のステージは省略しています。デプロイの前にビルドが通ることを確認した方が良いでしょう)
stages:
- deploy
cache:
paths:
- node_modules/
deploy_production:
stage: deploy
image: kroniak/ssh-client
before_script:
- apk add curl
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
- echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
script:
- ip addr show
- curl -s http://httpbin.org/ip
- curl -s inet-ip.info
- pwd
- ssh -tt $SSH_USER@$SSH_IP_ADDRESS -p 22 -i ~/.ssh/id_rsa
接続先のターミナルを
.bash_profile
# change TERM
export TERM=xterm
としておきましょう。
git cherry-pick を使用します
git cherry-pick [取り込むコミットID]
範囲を指定して連続したコミットを取り込むには、以下のコマンドを使用します。
git cherry-pick <開始コミットID>^..<終了コミットID>
左側が古いコミット、右側が新しいコミットです。
また左側には最後 ^ をつけると、開始コミットID 自身も取り込まれます。つけない場合はその次のコミットから取り込まれます。
例: a1b2c3dのコミットからd4e5f6gまでを取り込む
git cherry-pick a1b2c3d^..d4e5f6g
git cherry-pick <コミットID1> <コミットID2> <コミットID3>
かなりの確率でコンフリクトは起こると考えておいた方が良いのでその対応を知っておきましょう。 コンフリクトが起きると次のようなログ出力となります
Auto-merging local/resources/xxxx.cs
Auto-merging local/resources/bbbb.cs
CONFLICT (content): Merge conflict in local/app/Http/Requests/cccc.cs
CONFLICT (content): Merge conflict in local/app/Http/Controllers/dddd.cs
CONFLICT (content) となっているファイルを修正、保存します。
その後に修正したファイルを追加してコミットします。
git add local/app/Http/Requests/cccc.cs
git add local/app/Http/Controllers/dddd.cs
コミットします。コメントの先頭に [cherry-pick] → をつけてわかりやすいようにします。(書き方はなんでもokです)
git commit -m "[cherry-pick] → [fix] ○○○の不具合を修正"
とします
git cherry-pick で大量のコンフリクトが発生し、元の状態に戻りたい場合、以下の手順で行うことができます。
コンフリクトが発生した状態で、まだ解消していない場合は、以下のコマンドを使用して cherry-pick を中止し、元の状態に戻すことができます。
git cherry-pick --abort
もし既にコンフリクトを手動で解消しようとしていて、それでも元に戻したい場合は、git reset --hard を使って最新のコミットの状態に戻すことができます。ただし、この操作は未保存の変更をすべて破棄するので注意が必要です。
git reset --hard HEAD
更新日のみ
git log -- path/to/myfile.html
詳細
git log -p path/to/myfile.html
最新のコミットログを後から修正します
git commit --amend
実行すると vi が起動するのでテキストを修正します。
修正が完了したら [esc] に続けて wq [enter] 入力して保存します。
git管理下には置きたいけれど 今回のブランチに限り 変更を追跡されて欲しくない時は
assume-unchanged または skip-worktree を設定することで追跡から外すことができます。
なお、これは開発側(更新、コミット、push を行う側)に設定します。
git update-index --assume-unchanged <ファイル名>
取り消す
git update-index --no-assume-unchanged <ファイル名>
git update-index --skip-worktree <ファイル名>
取り消す
git update-index --no-skip-worktree <ファイル名>
どちらもブランチごとに有効 ブランチを移動した際は再度設定が必要です
git ls-files -v
設定されているファイルには先頭に 半角の h が表示されます
設定すると、git status での更新されたファイルリストに表示されなくなります。
git add -A でステージするファイルに追加されることもありません。
ただ設定したローカルリポジトリのみに有効なので、 別のローカルにて設定忘れたまま更新してコミット・push されるともちろんリモートに反映されます。
基本的にskip-worktreeで良い。
イメージとしては、skip-worktreeは手元の変更を優先するが、 assume-unchangedはリポジトリの変更を優先する。
そのため、git reset --hardを実行したような場合は、 assume-unchangedは手元の変更が失われる。
HEADとは
今自分が作業している場所(コミット)を示すリファレンスです。コミットするたびに自動的に移動します。
です。
cat .git/HEAD
git reflog
ブランチを確認したときに、そのブランチの最新コミット以外のコミットをHEADが参照しているときに HEAD detached になります。
git branch
結果例
* (HEAD detached from e40590e)
master
これは HEADがそのブランチの最新コミット以外の特定のコミットを指している状態です。
HEADをあるブランチの最新コミットに移動したい場合は
git branch
でブランチを表示して、そのブランチへ移動します。
まだ一度もチェックアウトしていないリモートに存在するブランチへ移動したいときは
git branch -r
でリモートのブランチ一覧を表示して確認します。
master ブランチで移動する場合
git checkout master
これで戻ります。
git diff 古いほうのコミットID 新しいほうのコミットID
(「古いほうのコミットID」「新しいほうのコミットID」は 順番逆でも差分は表示されますが、patch を作成する時に、順番が逆だとリバースパッチを作成してしまうので注意。)
例
git diff f2244fdacdc8cc8ef6e8fde146842e35570e059d f007eb9f355424252687e7958f718927d70224ca
git diff 古いほうのコミットID 新しいほうのコミットID --name-only
git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only 古いほうのコミットID 新しいほうのコミットID` -o ./sabun.zip
./sabun.zip に圧縮します
Windows の場合は git bash から実行してください
普通のコマンドプロンプトだとコマンドが実行できないことがあります
まずは確認します
git diff 古いコミットID 新しいコミットID
これで更新ファイルと更新内容確認します。
問題なければバッチファイルを作成します。ファイル名を後に指定するだけです
パッチファイル(myfile.patch)を作成する
git diff 古いコミットID 新しいコミットID > myfile.patch
これでバッチファイルが作成できました。
Windows用に改行コードを CR+LF にする場合は nkf をかませます
git diff 古いコミットID 新しいコミットID | nkf -Lw > myfile.patch
patch.exe -p1 --dry-run < myfile.patch
オプション
-p1 1階層階層の違いを無視します。
--dry-run ドライラン(テスト実行します)
これでエラーが表示されなければ --dry-run をはずして実行します
patch.exe -p1 < myfile.patch
参考
https://qiita.com/sea_mountain/items/7d9c812e68a26bd1a292
http://2hz.org/akebia/item/699
こちらに、ユーザーアカウント制御(UAC)対応版を作ってくださってる方がいるのでこちらからダウンロードしましょう。
秘密鍵「id_rsa_my_gitlab」を登録します。
ssh-add ~/.ssh/id_rsa_my_gitlab
authentication agentを起動してあげましょう
eval "$(ssh-agent)"
次のコマンドで接続のテストが行えます。
ssh -T git@gitlab.com
これでうまくいけばOKです。
vi ~/.ssh/config
# Gitlab
Host gitlab
User git
Port 22
HostName gitlab.com
IdentityFile ~/.ssh/id_rsa_my_gitlab
TCPKeepAlive yes
IdentitiesOnly yes
もちろんパーミッションは 0600 で!
これで
ssh -T gitlab
でテストして接続できればokです
git log -p ファイルのパス で特定のファイル更新を調べることができます
git log -p app/myscript.js
既に master に複数のコミットを行ったあとで、masterからはそのコミットを削除したい場合。
手順としては、
「1. 現在の master 状態から新しいブランチを作成」
「2. master ブランチの不要なコミットを消す」
だけです。簡単ですね。
git branch
git checkout -b moved__20201110a
(ブランチ名はなんでもokです。)
git checkout master
git log とコミットIDを表示させる
git log --pretty=oneline
git revert 【コミットID】
実行するとエディタが立ち上がるので、コメントを記述して [esc] → : → wq します。
指定したコミットを打ち消す、コミットが実行されます。
リモートにも反映させることができます。
git reset --hard HEAD~4
最新から 4つ のコミットを取り消します。 (コミット自体をなかったことにします。)
以上です。 Souce Treeや VS Code などでブランチのツリーを確認します。
あまりにコミットが多いと、他人が見た時に更新ファイルが見つけにくいという問題がおきるというのが .git あるあるの一つです。
そこで複数のコミットを1つにまとめてみましょう。
git rebase -i HEAD~~~
git log
( ↑ ↓ キーで移動して q で終了します。)
git log --name-status
git log --name-only
git log --pretty=oneline
git log --oneline
git log --graph
よくある光景です。
現在作業中のブランチにいるとします。 リモートの情報を取得してから origin /master を取り込みます。
git fetch
git merge origin/master
現在作業中のブランチにいるとします。 リモートの情報を取得してから ローカルの master を再度ベースに変更します(リベース)。
git fetch
git rebase master
https://git-scm.com/book/ja/v2/Git-の基本-タグ
Git のタグには、軽量 (lightweight) 版と注釈付き (annotated) 版の二通りがあります。
軽量版のタグは、変更のないブランチのようなものです。特定のコミットに対する単なるポインタでしかありません。
しかし注釈付きのタグは、Git データベース内に完全なオブジェクトとして格納されます。 チェックサムが付き、タグを作成した人の名前・メールアドレス・作成日時・タグ付け時のメッセージなども含まれます。 また、署名をつけて GNU Privacy Guard (GPG) で検証することもできます。 一般的には、これらの情報を含められる注釈付きのタグを使うことをおすすめします。 しかし、一時的に使うだけのタグである場合や何らかの理由で情報を含めたくない場合は、 軽量版のタグも使用可能です。
軽量版のタグを作成するには -a、-s あるいは -m といったオプションをつけずにコマンドを実行します。
ローカル
git tag -a v1.2.3
リモートへ push
git push origin v1.2.3
タグ「v.1.2.3」を取り消します
ローカル
git tag -d v1.2.3
リモート
git push origin :refs/tags/v1.2.3
/tags/ の一覧画面からリリースを作成したいタグの右側の「...」をクリックして Create release から作成します
このコマンドで文字化けが治ります
.git リポジトリ単位に設定する場合
git config --local core.quotepath false
マシン全体に設定する場合
git config --global core.quotepath false
.bash_profile
export GIT_PAGER="LESSCHARSET=utf-8 less"
ブランチを作成するのを忘れて作業をしてしまった!!
そんな時に後からブランチを作成する方法です。
普通に新しいブランチを作成するとそのブランチに変更したファイルも引き継がれます
例: 新しいブランチ my_new_branch を作成する。( + 作成後にブランチに移動)
git checkout -b my_new_branch
以上です。
これだけでokです。
git stash
git stash list
git checkout -b my_new_branch
git stash pop
git diff --name-only HEAD HEAD~1
git diff --name-only HEAD HEAD~1 --diff-filter=d
git diff --name-only HEAD HEAD~1 --diff-filter=D
git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o ~/2020_06_18__11_46_09__sabun.zip
ローカルのマシンで
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa__github
とします。
.ssh/ ディレクトリ内に鍵ファイル
id_rsa__github
id_rsa__github.pub
が作成されます。
GitHubのWEBサイトの
「右上のメニュ」 → 「Setting」 → 「SSH and GPG keys」 → 「New SSH Key」
から鍵を登録
( id_rsa__github.pub の中身をコピペ )
します
sshの設定に githubを加えます
vi ~/.ssh/config
下記の内容を追記
# GitHub
Host mygithub
User git
Port 22
HostName github.com
IdentityFile ~/.ssh/id_rsa__github
TCPKeepAlive yes
IdentitiesOnly yes
mygithub という名前で設定を作成しました。
ssh 接続をテストします。
ssh -T mygithub
Hi <ユーザー名>! You've successfully authenticated,
と出ればOKです。
GitHub WEBサイトからリポジトリを作成してください 。
通常
git clone git@github.com:<ユーザー名>/<プロジェクト名>
としますが、これの「github.com」を「mygithub」に書き換えます。
git clone git@mygithub:<ユーザー名>/<プロジェクト名>
git push origin master
以上で失敗せずに push できます。