- 投稿日:2021-01-03T22:48:02+09:00
GitHubのwikiをローカル編集してPushする際に出たエラー
要点
- GitHubレポジトリのwikiクローン→ローカルで編集→Pushする際にエラーが発生しました。
- 原因は、二段階認証を有効にしている状態で、HTTPSでPushしてることにありました。
- なので、.git/configのリモートURLをSSHプロトコルに変更すればPushできました。
エラー発生→解決までの経緯
前提条件
- GitHubで二段階認証を有効にしているため、SSHでPushするのがマストな状態。
- SSH接続に必要な設定は済ませてある。
※GitHubにSSH接続するための手順は、こちらの記事がわかりやすかったです!
発生したエラー
GitHubレポジトリのwikiをローカルにcloneして編集し、Pushしようとしたところ以下のようなエラーが発生しました。
$ git push origin master Username for 'https://github.com': USERNAME Password for 'https://USERNAME@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/USERNAME/REPOSITORY.wiki.git/'解決方法
二段階認証を有効にしている状態で、HTTPSプロトコルでPushしようとしているため、上記のようなエラーが起こるようです。
# 元の状態 $ git remote -v origin https://github.com/USERNAME/REPOSITORY.wiki.git (fetch) origin https://github.com/USERNAME/REPOSITORY.wiki.git (push)なので、ローカルレポジトリのリモートURLをSSHプロトコルに変えてからPushする必要があります。
$ vim .git/config ------------------ [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = true [remote "origin"] # ↓ここをHTTPSからSSHプロトコルに変更 url = git@github.com:USERNAME/REPOSITORY.wiki.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/masterリモートURLが変更できていることを確認して、Push。
$ git remote -v origin git@github.com:USERNAME/REPOSITORY.wiki.git (fetch) origin git@github.com:USERNAME/REPOSITORY.wiki.git (push) $ git push origin master無事にPushできました。
(ちなみに自分は、リモートURLを修正する際に
git@github.com:
の:
を/
のままにしていて、一瞬「あれ?Pushできない?」となりました。)その他気づいた点
なお、この記事を書いている2021年1月現在では、GitHubレポジトリのwikiはHTTPSでしかクローンできないみたいです。
そのため、wikiをローカルで編集する際は、必要に応じてリモートURLをSSHに変えておく必要がありそうです。参照
解決の際に拝見した記事
- 投稿日:2021-01-03T22:32:18+09:00
開発現場でよく使うGit コマンドシリーズ
ファイルの変更を保存する系
ワークツリーからインデックスにファイルの変更内容を移動する。
$ git add -Aインデックスに置かれたファイルの変更内容をコメットメッセージを添えて保存する。
$ git commit -m 'message'現在チェックアウトしているブランチの最新の状態をgitlab、もしくはgithubのリモートリポジトリにpushする。
$ git push origin HEADワークツリー
自分が作業している場所
HEAD
現在checkoutしているブランチの先頭
commitの履歴閲覧系
コミット履歴を見ることができる。
$ git reflog 8645cbf (HEAD -> test) HEAD@{0}: commit: test 9656c9d (origin/master, typescripts, master) HEAD@{1}: checkout: moving from test2 to test f0698c6 (test2) HEAD@{2}: commit: test 9656c9d (origin/master, typescripts, master) HEAD@{3}: checkout: moving from test to test2 9656c9d (origin/master, typescripts, master) HEAD@{4}: checkout: moving from master to test 9656c9d (origin/master, typescripts, master) HEAD@{5}: checkout: moving from typescripts to master特定のcommitまで戻す系
上の
git reflog
で出力されたコミット一覧の中に、HEAD@{番号}
の表記があるので、これを使って特定のコミットまで戻ることができる。
ちなみに、--hard
オプションをつけると、HEADの位置、ワークツリー、インデックスの全てをHEAD@{0}
の位置に移動することができる。$ git reset --hard HEAD@{0}addした内容、つまりインデックスにある内容を取り消したい場合は
--mixed
オプションをつける。$ git reset --mixed HEAD@{0}参考サイト
https://qiita.com/shuntaro_tamura/items/db1aef9cf9d78db50ffe
一時待避系
ファイルの変更内容を一時的に退避させる。
$ git stash save退避させた内容をワークツリーに戻す。
$ git stash pop退避させた変更内容の一覧を表示する。
$ git stash list stash@{0}: WIP on typescripts: 9656c9d yaml修正 stash@{1}: WIP on typescripts: 9656c9d yaml修正 stash@{2}: WIP on typescripts: 9656c9d yaml修正退避させた変更内容をワークツリーに適用する。
$ git stash apply stash@{1}以前のcommitとの差分を見る
差分を見る系
以前のcommitとの差分を見る。
$ git diff /var/www/html/sample_project/index.htmlブランチ間で差分を見る。
$ git diff [branchA] [branchB]ブランチ操作系
新規ブランチを作成する
$ git branch -b example-branch指定したブランチにチェックアウトする
$ git checkout example-branch新規ブランチを作成した上でチェックアウトする。
$ git checkout -b example-branchremoteリポジトリにあるブランチをローカルに持ってくる
remoteリポジトリの状態をローカルリポジトリに反映する
$ git remote updateリモートリポジトリのブランチをローカルリポジトリに持ってくる。
$ git checkout -b example-branch origin/example-branchコンフリクト解消系
test1ブランチにtest2ブランチを取り込む場合。
$ git checkout test1 $ git merge test2test1ブランチとtest2ブランチで同様の箇所を修正していた場合にコンフリクト(衝突)が発生し、開発者自身がコンフリクトの解消を行わなければいけない。
コンフリクト発生画面localhost@root:laravel_project $ git merge test2 CONFLICT (add/add): Merge conflict in app/Http/Controllers/conf copy.php Auto-merging app/Http/Controllers/conf copy.php Automatic merge failed; fix conflicts and then commit the result.VSCodeにてコンフリクトを解消する
VSCodeのファイル一覧を見ると、コンフリクトが発生しているファイル名のところに「C」のマークがついているのがわかる。
このファイルにてコンフリクトが発生している。コンフリクトが起きているファイルを開くと、2つのブランチ間での差分が表示される。
HEAD (Current Change)
の部分が、現在チェックアウトしているブランチにて加えられている変更内容である。
test2 (Incoming Change)
の部分が、チェックアウトしているブランチに取り込みたいブランチにて加えられた変更内容である。この2つのブランチにて加えられた変更内容のどちらを採用するのかを開発者自身が選択する。
上記の画像のように、VSCode上の各ボタンを選択することで、コンフリクトを解消することができるようになっている。
Accept Current Change
は 現在チェックアウトしているブランチの内容を採用する。Accept Incoming Change` は取り込まれる側のブランチの内容を採用する。
Compare Changes
を選択すると、以下のように差分を見ることができる。
Accept Both Changes
は現在チェックアウトしているブランチと、取り込まれるブランチの両方をブランチの変更内容を採用する。コンフリクトを解消した後は、解消した内容をcommitする必要がある。
$ git add -A $ git commit -m 'resove conflict'以上で、test2ブランチの内容をtest1に取り込んだ上で、その際に発生したコンフリクトを解消することができた。
fast-forward とは
developブランチをmasterブランチにマージするときに、masterに変更がなかったときに、行われるマージをfast-forwardマージとする。
- 投稿日:2021-01-03T16:38:12+09:00
Gitの勉強1日目
はじめに
gitは以前から使用していましたが、なんとなく add → commit → push を使っているだけでした。そこで体系化されたもので学習しようと思い、「GitHub実践入門」でgitの基礎を学んだので、Markdownの練習とgitの自分用のメモとしてこの記事に残しておきます。
今後も追記していく予定です。git概念図
git add : stage領域へ置き、gitの管理対象下とする
git commit : Localリポジトリへ履歴を残すよく使うコマンド
コマンド 意味 git log リポジトリにコミットされたログを確認する git diff 今回のコミットが前回のコミットとどのような差分があるのか確認(git commit する前にやる癖をつける) git checkout -b
git checkout -ブランチを作成し、切り替え
一つ前のブランチへ切り替えgit merge --no-ff マージコミットのメッセージを記入する git log --graph ブランチを視覚的に確認 git commit -am "commit massege" git add + git commit git commit --amend 直前のコミットメッセージを修正
- 投稿日:2021-01-03T16:32:27+09:00
Udemy もう怖くないGit!チーム開発で必要なGitを完全マスター (基礎編)
引用先
Udemy もう怖くないGit!チーム開発で必要なGitを完全マスター
このコースではGitの裏側でどのような挙動でGitが動いているのかを図で詳しく解説しているので深く知りたい方は受講してみることをおすすめします。Gitとは
Gitとは、分散型バージョン管理システムのこと。
簡単にいうとファイルのバージョン管理ができるツールのこと。
ファイルの変更履歴が管理できるので、前のバージョンに戻したいときにすぐに戻すことができます。GitHubとは
コードのホスティングサービス。
ファイルの変更履歴をオンライン上で扱えるサービスのこと。
Gitで扱うデータをオンラインでわかりやすくしています。Gitにユーザー情報を登録
git config --global user.name <githubで登録したユーザーネーム> git config --global user.email <githubで登録したメールアドレス> git config --global core.editor <エディタ名>git config user.name # <githubで登録したユーザーネーム> git config user.email # <githubで登録したメールアドレス> git config core.editor # <エディタ名> git config --list # 登録された情報がリスト上で確認できる基本的なGitの流れ
ワークツリー(自分のパソコンの作業場)
↓ git add
ステージ(リポジトリにコミットする前の準備エリア)
↓ git commit
ローカルリポジトリ(自分のパソコン内でファイルやディレクトリの履歴を管理する場所)
↓ git push
リモートリポジトリ(サーバー上のファイルやディレクトリの履歴を管理する場所)ローカルリポジトリを作成
git initgit initをすると.gitディレクトリ(ローカルリポジトリ)が作成される。
Gitリポジトリのコピーを作成する
git clone <リポジトリ名>ローカル内にファイルと.gitディレクトリのコピーを作成する。
変更をステージに追加する
git add <ファイル名> git add <ディレクトリ名> git add .ファイル名、ディレクトリ名を指定して追加できる。
ワークツリー内全てのファイルを追加したい時はgit add . と入力する。変更を記録する
git commit git commit -m "<コミット名>"ステージからリポジトリへ記録する。
コミットメッセージはわかりやすく書く。現在の変更状況を確認する
git statusワークツリーとステージ間、ステージとリポジトリ間の変更されたファイルを表示する。
変更差分を確認する
# git addする前 git diff git diff <ファイル名> # git addした後 git diff --stagedワークツリーとステージ間がgit diff
ステージとリポジトリ間がgit diff --staged
変更された差分を表示する。変更履歴を確認する
git log #一行で表示する git log --online #ファイルの変更差分を表示する git log -p <ファイル名> #表示するコミット数を制限する git log -n <コミット数>ファイルを削除する
#ファイルごと削除 git rm <ファイル名> git rm -r <ディレクトリ名> #ファイルを残したい時 git rm --cashed <ファイル名>ワークツリーとリポジトリを削除 → git rm
リポジトリのみ削除 → git rm --cashedファイルの移動を記録する
git mv <旧ファイル><新ファイル>ファイルの移動、ファイル名の変更を記録できる。
リモートリポジトリ(GitHub)を新規追加する
git remote add origin <リポジトリのURL>originとはリポジトリのURLのショートカット名。
originを登録しておくことで、毎回リポジトリのURLを入力しなくてすむようになります。リモートリポジトリ(GitHub)へ送信する
git push <リモート名> <ブランチ名> git push origin master #初回にやっておくと良いこと git push -u origin mastergit commitした内容を、git pushでリモートリポジトリ(GitHub)へ送信する。
初回にgit push -u origin masterと入力することで
今後git pushのみだけでgit push origin masterと同じ意味になる。コマンドにエイリアスを付ける
git config --global alias.ci commit git config --global alias.st status git config --global alias.br branch git config --global alias.co checkoutコマンドを簡略化できる。
ファイルの変更を取り消す
git checkout --<ファイル名> git checkout --<ディレクトリ名> # 全変更を取り消す git checkout --.ワークツリーで変更したファイルの変更を取り消す。
ステージした変更を取り消す
git reset HEAD <ファイル名> git reset HEAD <ディレクトリ名> # 全変更を取り消す git reset HEAD .ステージしたファイルのみを変更する。
ワークツリーのファイルは変わらない。直前のコミットを修正する
git commit --amendコミットしてプッシュする前にしか使用できない。
リモートリポジトリにプッシュしたコミットは修正すると
他の人がプルした内容と差異が生まれてしまうため。リモートを表示する
git remote #対応するURLを表示 git remote -v前述のoriginなどのショートカット名が表示される。
リモートから情報を所得する(fetch,pull)
fetch編
git fetch <リモート名> git fetch originリモートリポジトリからローカルリポジトリへ情報を保存。
リモート専用のフォルダに保存している。
mergeをしないとワークツリーに保存できない。pull編
git pull <リモート名> <ブランチ名> git pull origin master #上記コマンドは省略可能 git pullリモートからマージまでを一気にやりたい時に使う。
fetchとpullの使い分け
基本的にfetchを使うのがおすすめ。
pullをしてしまうとマスターブランチにファイルが統合されてしまうため気をつけなければならない。リモートの詳細情報を表示する
git remote show <リモート名> git remote show origingit remoteより詳しい情報が表示できる。
・fetch,pushのURL
・リモートブランチ
・git pillの挙動
・git pushの挙動リモート名の変更
git remote rename <旧リモート名> <真リモート名>リモートの削除
git remote rm <リモート名>
- 投稿日:2021-01-03T16:18:02+09:00
EclipseからGitHubにプッシュする【備忘録】
EclipseとGitの連携を5回くらいやっているのですが、
毎回どうやってやるんだっけと調べて、検索上位の記事ではうまくできなくて
手間取るので自分用の備忘録としてまとめます。
Eclipseで作成した新規プロジェクトをGitHubの新規リポジトリにプッシュするまでです。
最初の設定みたいなものは書いていません。
検索上位に出てくる記事で苦労しなかったと思うんですがね。。EclipseとGitの連携
①チーム→プロジェクトの共有
②Gitを選択
③プロジェクトの親フォルダー内のリポジトリーを使用または作成にチェックする
④リポジトリーの作成を押す
GitHubにプッシュする
①Gitパースペクティブを選ぶ
②Gitステージングの++を押してaddする
③コミットメッセージを書いてコミットおよびプッシュ
画像なくてすみません。
以上。
- 投稿日:2021-01-03T15:43:47+09:00
Udemy もう怖くないGit!チーム開発で必要なGitを完全マスター (ブランチ・マージ編)
引用先
Udemy もう怖くないGit!チーム開発で必要なGitを完全マスター
このコースではGitの裏側でどのような挙動でGitが動いているのかを図で詳しく解説しているので深く知りたい方は受講してみることをおすすめします。ブランチとは
並行して複数機能を開発するためにある。
共同開発において必ず必要となる。ブランチの仕組み
コミットをしていくと前回のコミットを親コミットとしてコミット1,2,3と時系列順にならんでいき、コミット名としてコミットID(コミットハッシュ値)を割与えられる。
ブランチとは最新のコミットIDを指すポイントにすぎない。
要するにブランチの中にデータが入っているわけではなく、いつコミットしたものかのデータ情報にすぎないということ。(余談)HEADについて
Gitを使っているとちょくちょくでてくるHEADについて記述。
今、自分が作業しているポインタのことをHEADという。新しいブランチを作成
git branch <ブランチ名>ブランチを作成するだけで、ブランチの切り替えは行わない。
ブランチの一覧を表示
git branch # 全てのブランチを表示 git branch -a何のブランチが確認する時に使う。
※印がついているのが今いるブランチ。ブランチを切り替える
git checkout <既存ブランチ名> # ブランチを新規作成して切り替える git checkout -b <新ブランチ名>-bはbranchの略。
変更をマージ(統合)する
git merge <ブランチ名> git remote <リモート名/ブランチ名>マージすると他の人の変更履歴を統合する。
マージには3種類ある
①Fast Foward : 早送りになるマージ
ブランチが枝分かれせずマージした時は、ブランチのポインタを前に進めるだけ。
②Auto Merge : 基本的なマージ
枝分かれして開発していた場合、マージコミットという新しいコミットを作る。
マージコミットは親コミットを2つ持っている特徴がある(マスターブランチとブランチ)。③コンフリクト
同じファイルを複数人で異なる変更した時に起こる。
例えば、index.htmlの3行目を二人のエンジニアが変更しマージした時に起こる。コンフリクトの解決方法
コンフリクト発生画面
<h1>Gitチュートリアル</h1> <p>ようこそ</p> <<<<<<<HEAD <p>git addについて学ぼう</p> ←今自分がいるブランチの変更内容 ======= <p>git commitを知ろう</p> ←別のブランチの変更内容 >>>>>>>feature↓ 修正
<h1>Gitチュートリアル</h1> <p>ようこそ</p> <p>git addについて学ぼう</p> <p>git commitを知ろう</p>修正方法
①ファイルの内容を書き換える
②「<<」 「==」 「>>」 の記述を削除するコンフリクトが起きないようにするには?
① 複数人で同じファイルを変更しない
② pullやmergeする前に変更中の状態をなくしておく(commit,stashをしておく)
③ pullする時は、pullするブランチに移動してからpullするブランチ名を変更
git branch -m <ブランチ名>今作業しているブランチ名を変更できる
ブランチを削除
# masterにマージされていない変更が残っている場合削除しない git branch -d <ブランチ名> # masterにマージされていなくても強制削除する git branch -D <ブランチ名>ブランチを利用した開発の流れ
masterブランチをリリース用ブランチ。
開発はトピックブランチを作成して進めるのが基本。最新のマスターからトピックごとにブランチをして、開発が終わったらマスターの方にマージしていく。
- 投稿日:2021-01-03T14:22:26+09:00
Githubから届いたDeprecation Noticeメールに対応する
メールをチェックしていたら、Githubから以下のようなメールが届いていた。
You recently used a password to access the repository at アカウント名/リポジトリ名 with git using git/2.22.0. Basic authentication using a password to Git is deprecated and will soon no longer work. Visit https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information around suggested workarounds and removal dates.
ざっくり和訳すると
最近[リポジトリ名]にパスワード利用しGitを使用しました。
ベーシック認証は非推奨になり、もうすぐ利用できなくなります。
代替策・利用できなくなる日についてはブログを確認ください。認証まわり=セキュリティにも関わりそうなことので調査&対応しました。
前半はメール記載のブログの要約が多いので、やるべきことだけをサッサと済ませたい方は何をすればいいのか?以降を読んでもらえればと思います。TL;DR
2021年8月13日から認証が必要なGit操作でパスワードを使った認証をできなくするから、
それまでにトークンorSSHキー認証に切り替えよう。影響を受けるワークフロー
ブログのWorkFlows Affectedより
- Gitコマンドを使ったアクセス
- Gitを用いたデスクトップアプリ(例:Sourcetree)
- パスワードを利用してGithubリポジトリ・Github.comにアクセスする全てのサービス
一方、以下のような利用・対応をしている場合は特に対応は必要ないとのこと
- 2段階認証を利用中(既にトークンorSSHベースの認証を設定できている)
- Githubエンタープライズサーバーを利用中
- Github Appsを利用中
変更の理由
1 パスワード トークン 詳細 ユニーク △ ○ パスワードは設定された物を使い回すのに対し、トークンは端末・使用する度に個別に生成される ランダム ✖︎ ○ トークンはランダムな文字列で生成されるため辞書型ブルートフォースアタックにも強い 制限性 ✖︎ ○ トークンは権限のスコープが制限されているため漏洩による被害を最小限にできる。パスワードは漏洩したらユーザー権限の全てがリスクに晒されてしまう 取り消し容易性 ✖︎ ○ トークンは認証情報を変えずに取り消し可能である。パスワードは、それ自体が認証情報であり取り消すことができない これらの理由から、Githubでも2段階認証・デバイス認証といったセキュリティを高める機能が多数リリースされています。
にも関わらず、現在のユーザーの多くがパスワード認証を使い回し続けてしまっている。セキュリティリスクの観点から、従来のパスワード認証を利用できなくしてでもユーザーに導入させるための対応のようです。
いつから使えなくなるのか?
ブラウンアウト(一時的にパスワード認証が利用できない状態)期間を経て、2021年8月13日からパスワード認証ができなくなります。
ブラウンアウトスケジュール(日本時間)
・2021年6月30日(水)16~19時
・2021年7月1日(木)1~4時
・2021年7月28日(水)16~19時
・2021年7月29日(木)1~4時設定を忘れたままブラウンアウトを迎えないよう、注意したいところですね。
何をすればいいのか?
* 2段階認証だけを設定して、個人アクセストークンを設定しないと、
Authentication failed for...
となりローカルでのGit操作ができなくなります。両方とも忘れず設定しましょう。対応手順
2段階認証を使用する
公式リファレンスが分かりやすいので、特に詰まることなく設定できます。
QRコードをスキャンするところでは、Googleの認証アプリが使えました。個人アクセストークンを使用する
こちらも公式リファレンスが充実しているほか、下記の記事がとても丁寧に解説して下さっています。
GitHubに二段階認証を設定した後にGit操作できない時の解決策
補足
・トークン入力を省略したい
トークン情報の入力するのが面倒な場合は認証情報ヘルパーの設定・更新をしましょう。・ローカルのプロジェクトのリモートURLのHTTPS化
個人アクセストークンを使う場合、リモートリポジトリとの通信はHTTPSが必須になります。# リモートのURLを表示 $ git remote -v # https:がついてない場合はset-urlコマンドで書き換え $ git remote set-url origin https://github.com/USERNAME/REPOSITORY.git
- 投稿日:2021-01-03T08:37:06+09:00
ad-m/github-push-action@masterのデフォルトブランチがmainに変更された
ad-m/github-push-action@masterとは
ad-m/github-push-action: GitHub actions to push back to repository eg. updated code
- リモートリポジトリに変更点をPushをするGithub Actionsである。
- GitHub Actionsで何かの処理をしたときリポジトリに変更が加わった場合、自動でPushさせることができる。
以前までPushするbranchのデフォルトがmasterだったが、mainに変更されたのでymlファイルも以下のように変更した。
action.ymlon: push: branches: - main # 修正 #snip... - name: Push changes uses: ad-m/github-push-action@master with: github_token: ${{ secrets.GITHUB_TOKEN }} branch: main # 追記(デフォルトがmasterからmainになった)
- デフォルトのbranchはmainであるが、今後変更される可能性があるので明示的に書いておく
- まだmaster branchを使用している人は
branch: master
と修正すれば良い
- 投稿日:2021-01-03T01:18:49+09:00
Git for Windowsの設定方法メモ
はじめに
windowsのPCでGitによるソースコード管理をやってみようと思い、ネットで調べながら挑戦しました。
結構大変だった(私の知識不足というのあるのですが...)ので、詰まったところと参照したページを備忘録的にまとめておこうかなと思います。メイン参照記事
メインで参照したのは下記ページです。
いまさらGit for Windowsのインストール、GitHubに接続してみた。ただ、ここに書いてないエラーなども頻発したので、その際に参照した記事も結構ありました。
詰まった点と追加の参照記事
ここについては個人的にエディターはATOMを利用する予定だったので、うっかりVimのまま素通りしてしまうところでした(どちらがいいとかはよく分からないです笑)
ここは正直最後までよく分からなかったですね...
デフォルトのホームディレクトリを変えようということなのですが、この設定変更が上手くいかず2時間くらい悩みました笑
書いてあることに従って環境変数の設定は出来るのですが、最後にBashコマンドの$ pwd
を打ち込んでもどうしても/c/home
にならなかったです。色々記事を探しているうちにこちらの記事(【Windows】Gitの環境構築をしよう!)を見つけました。
読んでいると「なんだ、別に変数変えなくてもいいのか」となり、変数を変えずGit Bashを実行すると無事開きました!ここも相当苦労したところです。
$ git clone
を実行できない以下のようなエラーが出ていました。
The authenticity of host '[XX.XX.XX.XX]:XX [XX.XX.XX.XX]:XX' can't be established. ECDSA key fingerprint is SHA256:hogehogehogehogehogehogehogehogehogehogheog. Are you sure you want to continue connecting (yes/no)?調べてみたところ、sshでの初回ログイン時に毎回これを聞かれるとのこと。
参照した記事:sshで初回ログイン時に"The authenticity of host 'host' can't be established..."を聞かれないようにする設定ということで、この参照ページにも記載の以下の方法でこのメッセージを回避しました。
host [XX.XX.XX.XX]:XX [XX.XX.XX.XX]:XX StrictHostKeyChecking no $ chmod 600 ~/.ssh/config
- git cloneがまだ実行出来ない
これで先ほどのメッセージは出なくなったのですが、まだ実行されません...
別のエラーが出ていました。fatal: could not create work tree dir '<repo name>' : Permission denied何かなと思って調べてみると、まさに同じ課題を抱えている人の以下の質問を見つけました。
参照した記事:git clone fatal: cannot create work tree dir permission denied解決策を見ると
sudo git clone <url>とすればいけるよ!と書いていたので実行。
するとまた別のエラーが...
bash: sudo: command not found調べてもよく分からなかったので、以下のページに記載されていた別の方法で試すことに。
参照した記事:fatal: could not create work tree dir 'kivy'
cd ~/ mkdir code cd code git clone https://github.com/xxxx/xxxxこれで何とかgit cloneすることが出来ました!
いやーかなり苦労しましたね笑新規ファイルを作成してインデックスに追加するという作業なのですが、これが最後の難関でした。
vi addfile
というコマンドを実行すると何やら謎のページになり、今までのGit Bashの操作が全く効かない状態に...調べてみるとそれはviエディターというものらしく、その操作方法にのっとる必要があるとのこと。
参照した記事:viコマンドについて詳しくまとめました 【Linuxコマンド集】保存は
Ctrl+S
で出来るものだとばかり思っていたのが、viコマンドでは:w
や:wq
であることに衝撃を受けつつ、何とかファイルを作成/編集することが出来ました!まとめ
初めての経験ということもあり、かなりの時間を費やしてしまいました笑
よく職場で見ている「githubを利用したバージョン管理」がこんなに未知のものであふれているのかと驚愕しつつ、完了した時と達成感もひとしおでした。記事中の記載で誤っている点などありましたら、コメントでご指摘いただけるとありがたいです!
- 投稿日:2021-01-03T00:27:23+09:00
git resetでよく使うコマンドの図解(忘備録)
ワーキングツリー:手元のファイルの状態
インデックス:ステージングしたファイルの状態
HEAD:コミットしたファイルの状態1個前にコミットした状態(HEAD^)まで、全ての状態(ワーキングツリー、インデックス、HEAD)を戻す
git reset --hard HEAD^^の数だけ戻る
直前のコミットした状態に戻す
git reset --hard HEAD直前のコミットのみの取り消し
(1個前のHEADに戻す)
git reset --soft HEAD^直前のステージのみの取り消し
(直前のHEADの状態までインデックスを戻す)
git reset --mixed HEAD参考させていただいた記事
[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法]
https://qiita.com/shuntaro_tamura/items/db1aef9cf9d78db50ffe