20210103のGitに関する記事は10件です。

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に変えておく必要がありそうです。

参照

解決の際に拝見した記事

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

開発現場でよく使う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-branch

remoteリポジトリにあるブランチをローカルに持ってくる

remoteリポジトリの状態をローカルリポジトリに反映する

$ git remote update

リモートリポジトリのブランチをローカルリポジトリに持ってくる。

$ git checkout -b example-branch origin/example-branch

コンフリクト解消系

test1ブランチにtest2ブランチを取り込む場合。

$ git checkout test1
$ git merge test2

test1ブランチと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」のマークがついているのがわかる。

このファイルにてコンフリクトが発生している。

ea11279847e06625f7c47634fd8b9d68.png

コンフリクトが起きているファイルを開くと、2つのブランチ間での差分が表示される。

74cfadc026d72851716be28275069b4f.png

HEAD (Current Change) の部分が、現在チェックアウトしているブランチにて加えられている変更内容である。

test2 (Incoming Change) の部分が、チェックアウトしているブランチに取り込みたいブランチにて加えられた変更内容である。

この2つのブランチにて加えられた変更内容のどちらを採用するのかを開発者自身が選択する。

ee9374a3ac7b5e630549f0e01084caf0.png

上記の画像のように、VSCode上の各ボタンを選択することで、コンフリクトを解消することができるようになっている。

Accept Current Change は 現在チェックアウトしているブランチの内容を採用する。

Accept Incoming Change` は取り込まれる側のブランチの内容を採用する。

Compare Changes を選択すると、以下のように差分を見ることができる。

Accept Both Changes は現在チェックアウトしているブランチと、取り込まれるブランチの両方をブランチの変更内容を採用する。

8b886157373395eab01828acfb5e125e.png

コンフリクトを解消した後は、解消した内容をcommitする必要がある。

$ git add -A
$ git commit -m 'resove conflict'

以上で、test2ブランチの内容をtest1に取り込んだ上で、その際に発生したコンフリクトを解消することができた。

fast-forward とは

developブランチをmasterブランチにマージするときに、masterに変更がなかったときに、行われるマージをfast-forwardマージとする。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitの勉強1日目

はじめに

gitは以前から使用していましたが、なんとなく add → commit → push を使っているだけでした。そこで体系化されたもので学習しようと思い、「GitHub実践入門」でgitの基礎を学んだので、Markdownの練習とgitの自分用のメモとしてこの記事に残しておきます。
今後も追記していく予定です。

GitHub実践入門 ~Pull Requestによる開発の変革~

GitHub実践入門

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 直前のコミットメッセージを修正 
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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 init

git 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 master

git 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 origin

git remoteより詳しい情報が表示できる。
・fetch,pushのURL
・リモートブランチ
・git pillの挙動
・git pushの挙動

リモート名の変更

git remote rename <旧リモート名> <真リモート名>

リモートの削除

git remote rm <リモート名>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EclipseからGitHubにプッシュする【備忘録】

EclipseとGitの連携を5回くらいやっているのですが、
毎回どうやってやるんだっけと調べて、検索上位の記事ではうまくできなくて
手間取るので自分用の備忘録としてまとめます。
Eclipseで作成した新規プロジェクトをGitHubの新規リポジトリにプッシュするまでです。
最初の設定みたいなものは書いていません。
検索上位に出てくる記事で苦労しなかったと思うんですがね。。

EclipseとGitの連携

①チーム→プロジェクトの共有

作成したプロジェクトを右クリックし
スクリーンショット 2021-01-03 14.59.01.png

②Gitを選択

スクリーンショット 2021-01-03 14.59.19.png

③プロジェクトの親フォルダー内のリポジトリーを使用または作成にチェックする

ここでいつもどうするか迷う
スクリーンショット 2021-01-03 14.59.53.png

④リポジトリーの作成を押す

もう押してしまった後ですが。その後完了ボタン。
スクリーンショット 2021-01-03 15.08.07.png

GitHubにプッシュする

①Gitパースペクティブを選ぶ

②Gitステージングの++を押してaddする

スクリーンショット 2021-01-03 15.09.24.png

③コミットメッセージを書いてコミットおよびプッシュ

画像なくてすみません。

以上。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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ブランチをリリース用ブランチ。
開発はトピックブランチを作成して進めるのが基本。

最新のマスターからトピックごとにブランチをして、開発が終わったらマスターの方にマージしていく。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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.yml
on:
  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と修正すれば良い
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git for Windowsの設定方法メモ

はじめに

windowsのPCでGitによるソースコード管理をやってみようと思い、ネットで調べながら挑戦しました。
結構大変だった(私の知識不足というのあるのですが...)ので、詰まったところと参照したページを備忘録的にまとめておこうかなと思います。

メイン参照記事

メインで参照したのは下記ページです。
いまさらGit for Windowsのインストール、GitHubに接続してみた。

ただ、ここに書いてないエラーなども頻発したので、その際に参照した記事も結構ありました。

詰まった点と追加の参照記事

デフォルトのエディタを設定(コミットコメントなどで使用します。)

ここについては個人的にエディターはATOMを利用する予定だったので、うっかりVimのまま素通りしてしまうところでした(どちらがいいとかはよく分からないです笑)

インストール後の設定

ここは正直最後までよく分からなかったですね...
デフォルトのホームディレクトリを変えようということなのですが、この設定変更が上手くいかず2時間くらい悩みました笑
書いてあることに従って環境変数の設定は出来るのですが、最後にBashコマンドの$ pwdを打ち込んでもどうしても/c/homeにならなかったです。

色々記事を探しているうちにこちらの記事(【Windows】Gitの環境構築をしよう!)を見つけました。
読んでいると「なんだ、別に変数変えなくてもいいのか」となり、変数を変えずGit Bashを実行すると無事開きました!

GitBashからGitHubへの接続

ここも相当苦労したところです。

  • $ 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することが出来ました!
いやーかなり苦労しましたね笑

add

新規ファイルを作成してインデックスに追加するという作業なのですが、これが最後の難関でした。

vi addfileというコマンドを実行すると何やら謎のページになり、今までのGit Bashの操作が全く効かない状態に...

調べてみるとそれはviエディターというものらしく、その操作方法にのっとる必要があるとのこと。
参照した記事:viコマンドについて詳しくまとめました 【Linuxコマンド集】

保存はCtrl+Sで出来るものだとばかり思っていたのが、viコマンドでは:w:wqであることに衝撃を受けつつ、何とかファイルを作成/編集することが出来ました!

まとめ

初めての経験ということもあり、かなりの時間を費やしてしまいました笑
よく職場で見ている「githubを利用したバージョン管理」がこんなに未知のものであふれているのかと驚愕しつつ、完了した時と達成感もひとしおでした。

記事中の記載で誤っている点などありましたら、コメントでご指摘いただけるとありがたいです!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git resetでよく使うコマンドの図解(忘備録)

ワーキングツリー:手元のファイルの状態
インデックス:ステージングしたファイルの状態
HEAD:コミットしたファイルの状態

1個前にコミットした状態(HEAD^)まで、全ての状態(ワーキングツリー、インデックス、HEAD)を戻す

git reset --hard HEAD^

^の数だけ戻る

38215.jpg

直前のコミットした状態に戻す

git reset --hard HEAD

38213.jpg

直前のコミットのみの取り消し

(1個前のHEADに戻す)

git reset --soft HEAD^

38214.jpg

直前のステージのみの取り消し

(直前のHEADの状態までインデックスを戻す)

git reset --mixed HEAD

38216.jpg

参考させていただいた記事

[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法]
https://qiita.com/shuntaro_tamura/items/db1aef9cf9d78db50ffe

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む