- 投稿日：2021-01-07T22:34:52+09:00
【備忘録】バージョン管理手順
事前に git のデフォルトリポジトリ名を main に設定しておく（最新の git だとインストール時に設定するか聞かれるので、バージョンが古い場合はアップデートしておく）
- GitHubでリモートリポジトリ作成
- ディレクトリ作成
git initし git の管理下に（ローカルリポジトリ作成）git add .でステージングgit commit -m "first commit"でローカルリポジトリに反映git remote add origin https://github.com/[ユーザー名]/[1で作成したリモートリポジトリ名].gitで GitHub と紐づけgit push origin mainでリモートリポジトリにプッシュ
- 投稿日：2021-01-07T21:19:50+09:00
Git・GitHubについてのメモ【これで完璧！（ではない。）】
GitとGitHubについて勉強した内容をまとめておきます。
間違いとかあれば、どしどしコメントしてくださいませ。
gitの概要
・gitはバージョン管理システム。ゲームで言うところの、セーブをするツール。
・gitはファイルを差分ではなく、スナップショットとして記録している。簡単なgitの流れ
1.ワークツリー（ローカル）でファイルを変更
2.ステージに追加（git add <ファイル名>）する
3.ローカルリポジトリ（.gitディレクトリ）に変更履歴をコミット（スナップショットとして記録）する。（git commit）
4.GitGub上のリモートリポジトリにプッシュする。（git push <リモート名> <ブランチ名>）gitのデータの持ち方
・リポジトリに
圧縮ファイル・ツリー（スナップショット）・コミットを持っている。
・圧縮ファイルはgit addした時に保存される。
・ツリーはコミットした時に保存される。
・コミットも当然、コミットした時に保存される。各コミットは1つ前のコミットの内容を持っている。
例えば、
コミット2はparentにコミット1を持っている。gitのインストール確認
git --versiongitの設定確認
git config --listまた、
homeディレクトリ直下の.gitconfigにgitの設定情報が保存されている。gitファイルの作成
プロジェクトに作業ディレクトリを変更して、下記コマンドを実行。
git initこれで、
.gitディレクトリが作成され、さらにその中に、設定ファイル（config）などが作成される。gitコマンドにエイリアスをつける
git config --global alias.<エイリアス名（ショートカット名）> <コマンド名>オプション
--globalを付ければ、プロジェクトではなく、パソコン全体の設定が変更される。GitHub上のプロジェクトをコピー
git clone [githubのURL]ワークツリーの変更をステージ（インデックス）に追加する
＊ステージまたはインデックスと呼ばれるようです。
git addワークツリー（ファイル）の変更を記録する（コミット）
git commit git commit -m "メッセージ内容" //メッセージをつける git commit -v //変更内容を確認できる現在のファイルの変更状況を確認する
git statusこれで、
・ワークツリーとステージの状況
・ステージとローカルリポジトリの状況
が、表示される。変更した差分を確認する
git diff //ワークツリーとステージの差分 git diff <ファイル名> git diff --stafe //ステージとローカルリポジトリの差分変更履歴を確認する
git log git log --oneline //一行で表示 git log -p index.html //ファイルの変更差分だけを表示 git log -n <コミット数> //表示するコミット数を指定ファイルの削除を記録する
git rm <ファイル名> //ファイル削除 git rm -r <ディレクトリ名> //ディレクトリを削除 git rm --cached <ファイル名> //git上からのみ削除。ワークツリーには残る。ファイルの移動/ファイル名の変更を記録
//ファイルの移動 git mv <ファイル名> <ディレクトリ名>//ファイル名の変更 git mv <旧ファイル> <新ファイル> //上記は下記の3つのコマンドを合わせたもの。 mv <旧ファイル> <新ファイル> git rm <旧ファイル> git add <新ファイル>リモートリポジトリの追加
git remote add origin 追加したいリポジトリ（GitHubで作ったリモートリポジトリのURL）リモートリポジトリにプッシュする
git push origin master git push <リモート名> <ブランチ名>masterはデフォルトのブランチ名のこと。
gitで管理しないファイルの設定方法
.gitignoreファイルに設定する。書き方は下記の通り。
・#以降はコメント。
・除外するファイル名を指定
・ルートディレクトリを指定する場合は/を記述。（例：/index.html）
・ディレクトリ以下を除外するときは最後に/を記述。（例：dir/）
・ワイルドカードも使える。/以外を指定できる。（例：/.html）ファイルの変更を取り消す
下記コマンドを実行することで、最新のステージの内容とファイルの内容を同じにする。
git checkout --<ファイル名> git checkout --<ディレクトリ名> git checkout --. //全ての変更を取り消す
--はブランチ名とファイル名が被ってもGitが判別できるようにするためのもの。ステージに追加した変更を取り消す
裏側では、ローカルリポジトリの最新情報（直前のコミット）の内容でステージの内容を上書きすることで、
ステージの変更を取り消すという処理を実現している。
ステージへの変更を取り消しているだけなので、ワークツリーの内容は変更されない。git reset HEAD <ファイル名> git reset HEAD <ディレクトリ名> git reset HEAD . //全ての変更を取り消す直前のコミットを修正する
注意：リモートリポジトリにプッシュした内容は変更してはいけない（複数人でしている場合に困る事があるから。）
//git addでステージに追加してから、下記コマンドの実行で直線のコミットを編集できる git commit --amendリモートリポジトリの確認
git remote //設定しているリモートリポジトリ git remote -v //URLも表示されるリモートリポジトリの複数
git remote add <リモート名> <リモートURL>リモートから情報を取得する（フェッチ）
リモートリポジトリからローカルリポジトリ（
remotes/リモート/ブランチ）にファイルをコピーする。
ワークツリーには反映されない。git fetch <リモート名> git fetch originリモートから情報を取得してマージする（プル）
git pullを使えば、リモートリポジトリの内容をローカルリポジトリに反映して、ワークツリーにも反映させる。git pull <リモート名> <ブランチ名> git pull origin master //一般的には←のコマンドになる git pull //省略形 //上記は下記2つのコマンドと同じことをしている。 git fetch origin master git merge origin/masterfetchとpullの使い分け
基本は
fetchを使うのがオススメ。
プルだと、今自分がいるブランチにファイルが統合される。例えば、hogeブランチをリモートから取得して、マージしようとした時に、pullだと間違ってmasterブランチにhogeブランチの内容を統合してしまう可能性がある。
リモートの詳細情報を表示する
git remote show <リモート名> git remote show originリモート変更・削除
//リモートの変更 git remote rename <旧リモート> <新リモート> //リモートの削除 git remote rm <リモート名>ブランチとは
ブランチは複数機能を開発するために使われるもので、複数人で開発する時に重要となってくる。
役割としては、コミットを指し示すポインター的なことをしてくれる。
例えば、
コミット3のブランチにmasterとhogeがあり、自分はmasterブランチで作業している時に、新たにコミットするとコミット4ができて、masterブランチはコミット4示すようになる。hogeブランチはコミット3を示しているまま。この時、HEADはmasterブランチを示す。次に
hogeブランチ（コミット3を示している）で作業して、新たにコミットすると、コミット4'ができて、hogeブランチはコミット4'を示すようになる。この時、HEADはhogeブランチを示す。こんな感じで、ブランチごとに作業をすると、コミットを分ける事ができるので、Aさんはこっちの機能を開発、Bさんは違う機能を開発みたいなことを同時にできるようになる。
HEADについて
HEADは今作業しているブランチを指し示すポインター。
ブランチを利用した開発の流れ
・masterブランチはリリース専用のブランチにする
・開発する時は他のブランチを作成する例えば、Aさんは
hoge1ブランチで、Bさんはhoge2ブランチで開発を進める。hoge1ブランチでの開発が終了したら、masterブランチにマージする。また新たな機能を実装する時はmasterブランチからブランチをきって、hoge3ブランチを作成する。というような感じ。ブランチを追加する
git branch <ブランチ名>ブランチの一覧を表示する
git branch git branch -a //リモートリポジトリも表示どのブランチがどのコミットを指しているかを確認する
git log --oneline --decorate別に
--onelineは一行で表示するというだけなので、なくてもOK。でもあった方がわかりやすいよ。ブランチを切り替える
git checkout <既存のブランチ名> //ブランチを新規作成しつつ、切り替える git checkout -b <新規作成するブランチ名>ブランチ（名）の変更・削除
//ブランチ名の変更 git branch -m <ブランチ名> //ブランチの削除 git branch -d <ブランチ名> //強制削除 git branch -D <ブランチ名>マージ（merge）とは
マージは他の人が変更した内容を自分のワークツリーに反映させること。
変更をマージする方法
git merge <ブランチ名> git merge <リモート名/ブランチ名>マージには3種類あるよ
・Fast Foward（早送りになるマージ）
ブランチが枝分かれしなかった時は、ブランチのポインタが前に進むだけ、ということ。例えば、自分はmasterブランチで作業している。自分の休憩中に誰かが、hogeブランチで作業して、コミットした。自分はhogeブランチで変更した内容をmasterブランチに取り込む。この場合、masterブランチがhogeブランチに追いついただけになるよねって話らしいです...
・Auto Merge（基本的なマージ）
枝分かれして開発していた場合はマージコミットという新しいファイルを作成する。・コンフリクト
↓コンフリクトとは
コンフリクトとは同じファイルの同じ行を同時に編集した時にマージしようとすると、どっちを優先すべき？という競合が発生する事。
コンフリクトの解消方法
コンフリクトが発生したファイルを確認して、最終的にどっちを優先したいのか手動で書き換えればOK。簡単。
コンフリクトの確認方法
コンフリクトが発生している場合は、
git statusコマンドで確認できる。git status //実行結果 both modeified: test.phpコンフリクト関連の予防策
・複数人で同じファイルを変更しないようにする
・pullやmergeする前に変更中の状態をなくしておく（commitしておく。）
・pullする時は、pullするブランチに移動してからpullするようにする。GitHubについて
プルリクエストとは
プルリクエストとは自分の変更したコードをリポジトリに取り込んでもらうように申請する機能。
手順としては、
1.masterブランチを最新に更新する（git pull origin master）
2.ブランチを作成（git checkout -b <ブランチ名>）
3.ファイルを変更
4.変更をコミット（git add & git commit）
5.GituHubへプッシュ（git push <リモート名> <ファイル名>）
6.プルリクエストを送る
7.コードレビュー
8.プルリクエストをマージ
9.ブランチを削除
という手順。作業を一時避難する方法
【前提】
作業が途中でコミットしたくないけど、別のブランチで作業しないといけないので、作業を一時避難する。まずはファイルを変更して、下記コマンドを実行。
すると、変更した内容がワークツリーから消えて、stash
に保存される。//下記はどっちも同じ git stash git stash savestash（避難した作業）の一覧を確認する
git stash liststash（避難した作業）の復元
//最新の作業を復元 git stash apply //ステージの状況も復元する git stash apply --index //特定の作業を復元する git stash apply <スタッシュ名>stash（避難した作業）を削除する
//最新の作業を削除する git stash drop //特定の作業を削除する git stash drop <スタッシュ名> //全作業を削除する git stash clearタグについて
タグとはコミットを参照しやすくするためにわかりやすい名前をつけるもの。
タグを作成する
//最新のコミットにタグを付ける git tag <タグ名> //特定のコミットにタグを付ける git tag <タグ名> <コミット名> //注釈版タグ git tag -a <タグ名> //ファイルを開かずメッセージを書く git tag -a <タグ名> -m "<メッセージ>"タグの一覧を表示する
git tagタグデータの表示
git show <タグ名>タグをリモートリポジトリに送る
git push <リモート名> <タグ名> //タグをリモートに一斉送信 git push origin --tags
- 投稿日：2021-01-07T21:19:50+09:00
Git・GitHubはこれで完璧！（ではない。）
GitとGitHubについて勉強した内容をまとめておきます。
間違いとかあれば、どしどしコメントしてくださいませ。
gitの概要
・gitはバージョン管理システム。ゲームで言うところの、セーブをするツール。
・gitはファイルを差分ではなく、スナップショットとして記録している。簡単なgitの流れ
1.ワークツリー（ローカル）でファイルを変更
2.ステージに追加（git add <ファイル名>）する
3.ローカルリポジトリ（.gitディレクトリ）に変更履歴をコミット（スナップショットとして記録）する。（git commit）
4.GitGub上のリモートリポジトリにプッシュする。（git push <リモート名> <ブランチ名>）gitのデータの持ち方
・リポジトリに
圧縮ファイル・ツリー（スナップショット）・コミットを持っている。
・圧縮ファイルはgit addした時に保存される。
・ツリーはコミットした時に保存される。
・コミットも当然、コミットした時に保存される。各コミットは1つ前のコミットの内容を持っている。
例えば、
コミット2はparentにコミット1を持っている。gitのインストール確認
git --versiongitの設定確認
git config --listまた、
homeディレクトリ直下の.gitconfigにgitの設定情報が保存されている。gitファイルの作成
プロジェクトに作業ディレクトリを変更して、下記コマンドを実行。
git initこれで、
.gitディレクトリが作成され、さらにその中に、設定ファイル（config）などが作成される。gitコマンドにエイリアスをつける
git config --global alias.<エイリアス名（ショートカット名）> <コマンド名>オプション
--globalを付ければ、プロジェクトではなく、パソコン全体の設定が変更される。GitHub上のプロジェクトをコピー
git clone [githubのURL]ワークツリーの変更をステージ（インデックス）に追加する
＊ステージまたはインデックスと呼ばれるようです。
git addワークツリー（ファイル）の変更を記録する（コミット）
git commit git commit -m "メッセージ内容" //メッセージをつける git commit -v //変更内容を確認できる現在のファイルの変更状況を確認する
git statusこれで、
・ワークツリーとステージの状況
・ステージとローカルリポジトリの状況
が、表示される。変更した差分を確認する
git diff //ワークツリーとステージの差分 git diff <ファイル名> git diff --stafe //ステージとローカルリポジトリの差分変更履歴を確認する
git log git log --oneline //一行で表示 git log -p index.html //ファイルの変更差分だけを表示 git log -n <コミット数> //表示するコミット数を指定ファイルの削除を記録する
git rm <ファイル名> //ファイル削除 git rm -r <ディレクトリ名> //ディレクトリを削除 git rm --cached <ファイル名> //git上からのみ削除。ワークツリーには残る。ファイルの移動/ファイル名の変更を記録
//ファイルの移動 git mv <ファイル名> <ディレクトリ名>//ファイル名の変更 git mv <旧ファイル> <新ファイル> //上記は下記の3つのコマンドを合わせたもの。 mv <旧ファイル> <新ファイル> git rm <旧ファイル> git add <新ファイル>リモートリポジトリの追加
git remote add origin 追加したいリポジトリ（GitHubで作ったリモートリポジトリのURL）リモートリポジトリにプッシュする
git push origin master git push <リモート名> <ブランチ名>masterはデフォルトのブランチ名のこと。
gitで管理しないファイルの設定方法
.gitignoreファイルに設定する。書き方は下記の通り。
・#以降はコメント。
・除外するファイル名を指定
・ルートディレクトリを指定する場合は/を記述。（例：/index.html）
・ディレクトリ以下を除外するときは最後に/を記述。（例：dir/）
・ワイルドカードも使える。/以外を指定できる。（例：/.html）ファイルの変更を取り消す
下記コマンドを実行することで、最新のステージの内容とファイルの内容を同じにする。
git checkout --<ファイル名> git checkout --<ディレクトリ名> git checkout --. //全ての変更を取り消す
--はブランチ名とファイル名が被ってもGitが判別できるようにするためのもの。ステージに追加した変更を取り消す
裏側では、ローカルリポジトリの最新情報（直前のコミット）の内容でステージの内容を上書きすることで、
ステージの変更を取り消すという処理を実現している。
ステージへの変更を取り消しているだけなので、ワークツリーの内容は変更されない。git reset HEAD <ファイル名> git reset HEAD <ディレクトリ名> git reset HEAD . //全ての変更を取り消す直前のコミットを修正する
注意：リモートリポジトリにプッシュした内容は変更してはいけない（複数人でしている場合に困る事があるから。）
//git addでステージに追加してから、下記コマンドの実行で直線のコミットを編集できる git commit --amendリモートリポジトリの確認
git remote //設定しているリモートリポジトリ git remote -v //URLも表示されるリモートリポジトリの複数
git remote add <リモート名> <リモートURL>リモートから情報を取得する（フェッチ）
リモートリポジトリからローカルリポジトリ（
remotes/リモート/ブランチ）にファイルをコピーする。
ワークツリーには反映されない。git fetch <リモート名> git fetch originリモートから情報を取得してマージする（プル）
git pullを使えば、リモートリポジトリの内容をローカルリポジトリに反映して、ワークツリーにも反映させる。git pull <リモート名> <ブランチ名> git pull origin master //一般的には←のコマンドになる git pull //省略形 //上記は下記2つのコマンドと同じことをしている。 git fetch origin master git merge origin/masterfetchとpullの使い分け
基本は
fetchを使うのがオススメ。
プルだと、今自分がいるブランチにファイルが統合される。例えば、hogeブランチをリモートから取得して、マージしようとした時に、pullだと間違ってmasterブランチにhogeブランチの内容を統合してしまう可能性がある。
リモートの詳細情報を表示する
git remote show <リモート名> git remote show originリモート変更・削除
//リモートの変更 git remote rename <旧リモート> <新リモート> //リモートの削除 git remote rm <リモート名>ブランチとは
ブランチは複数機能を開発するために使われるもので、複数人で開発する時に重要となってくる。
役割としては、コミットを指し示すポインター的なことをしてくれる。
例えば、
コミット3のブランチにmasterとhogeがあり、自分はmasterブランチで作業している時に、新たにコミットするとコミット4ができて、masterブランチはコミット4示すようになる。hogeブランチはコミット3を示しているまま。この時、HEADはmasterブランチを示す。次に
hogeブランチ（コミット3を示している）で作業して、新たにコミットすると、コミット4'ができて、hogeブランチはコミット4'を示すようになる。この時、HEADはhogeブランチを示す。こんな感じで、ブランチごとに作業をすると、コミットを分ける事ができるので、Aさんはこっちの機能を開発、Bさんは違う機能を開発みたいなことを同時にできるようになる。
HEADについて
HEADは今作業しているブランチを指し示すポインター。
ブランチを利用した開発の流れ
・masterブランチはリリース専用のブランチにする
・開発する時は他のブランチを作成する例えば、Aさんは
hoge1ブランチで、Bさんはhoge2ブランチで開発を進める。hoge1ブランチでの開発が終了したら、masterブランチにマージする。また新たな機能を実装する時はmasterブランチからブランチをきって、hoge3ブランチを作成する。というような感じ。ブランチを追加する
git branch <ブランチ名>ブランチの一覧を表示する
git branch git branch -a //リモートリポジトリも表示どのブランチがどのコミットを指しているかを確認する
git log --oneline --decorate別に
--onelineは一行で表示するというだけなので、なくてもOK。でもあった方がわかりやすいよ。ブランチを切り替える
git checkout <既存のブランチ名> //ブランチを新規作成しつつ、切り替える git checkout -b <新規作成するブランチ名>ブランチ（名）の変更・削除
//ブランチ名の変更 git branch -m <ブランチ名> //ブランチの削除 git branch -d <ブランチ名> //強制削除 git branch -D <ブランチ名>マージ（merge）とは
マージは他の人が変更した内容を自分のワークツリーに反映させること。
変更をマージする方法
git merge <ブランチ名> git merge <リモート名/ブランチ名>マージには3種類あるよ
・Fast Foward（早送りになるマージ）
ブランチが枝分かれしなかった時は、ブランチのポインタが前に進むだけ、ということ。例えば、自分はmasterブランチで作業している。自分の休憩中に誰かが、hogeブランチで作業して、コミットした。自分はhogeブランチで変更した内容をmasterブランチに取り込む。この場合、masterブランチがhogeブランチに追いついただけになるよねって話らしいです...
・Auto Merge（基本的なマージ）
枝分かれして開発していた場合はマージコミットという新しいファイルを作成する。・コンフリクト
↓コンフリクトとは
コンフリクトとは同じファイルの同じ行を同時に編集した時にマージしようとすると、どっちを優先すべき？という競合が発生する事。
コンフリクトの解消方法
コンフリクトが発生したファイルを確認して、最終的にどっちを優先したいのか手動で書き換えればOK。簡単。
コンフリクトの確認方法
コンフリクトが発生している場合は、
git statusコマンドで確認できる。git status //実行結果 both modeified: test.phpコンフリクト関連の予防策
・複数人で同じファイルを変更しないようにする
・pullやmergeする前に変更中の状態をなくしておく（commitしておく。）
・pullする時は、pullするブランチに移動してからpullするようにする。GitHubについて
プルリクエストとは
プルリクエストとは自分の変更したコードをリポジトリに取り込んでもらうように申請する機能。
手順としては、
1.masterブランチを最新に更新する（git pull origin master）
2.ブランチを作成（git checkout -b <ブランチ名>）
3.ファイルを変更
4.変更をコミット（git add & git commit）
5.GituHubへプッシュ（git push <リモート名> <ファイル名>）
6.プルリクエストを送る
7.コードレビュー
8.プルリクエストをマージ
9.ブランチを削除
という手順。作業を一時避難する方法
【前提】
作業が途中でコミットしたくないけど、別のブランチで作業しないといけないので、作業を一時避難する。まずはファイルを変更して、下記コマンドを実行。
すると、変更した内容がワークツリーから消えて、stash
に保存される。//下記はどっちも同じ git stash git stash savestash（避難した作業）の一覧を確認する
git stash liststash（避難した作業）の復元
//最新の作業を復元 git stash apply //ステージの状況も復元する git stash apply --index //特定の作業を復元する git stash apply <スタッシュ名>stash（避難した作業）を削除する
//最新の作業を削除する git stash drop //特定の作業を削除する git stash drop <スタッシュ名> //全作業を削除する git stash clearタグについて
タグとはコミットを参照しやすくするためにわかりやすい名前をつけるもの。
タグを作成する
//最新のコミットにタグを付ける git tag <タグ名> //特定のコミットにタグを付ける git tag <タグ名> <コミット名> //注釈版タグ git tag -a <タグ名> //ファイルを開かずメッセージを書く git tag -a <タグ名> -m "<メッセージ>"タグの一覧を表示する
git tagタグデータの表示
git show <タグ名>タグをリモートリポジトリに送る
git push <リモート名> <タグ名> //タグをリモートに一斉送信 git push origin --tags
- 投稿日：2021-01-07T19:27:26+09:00
2021年版 GitHub 誤ってリポジトリを削除して復元した方法
はじめに
GitHubをあまり理解していなかったからこそやらかした投稿になります。
ポートフォリオを作成していた際、Github上からリポジトリを誤って全て消してしまいました。
同じような経験があればこの記事を是非、参考にしてください。解決方法は２つあります!
2つご紹介しますが早く復元した方を先に書きます。
解決方法 1(レスポンスが一番早いです)
Githubのお問い合わせフォームに連絡する！！ただそれだけです！！
下記URLをクリックして下さい。https://support.github.com/contact?tags=rr-restore
必要事項を記入して下さい
下記のスクショを参考して下さい。
SubjectはRequest to restore the repositoryで良いと思います。
How can we help?には何を書けばいいの?
英語で記入しなければならないので例文を参考にして下さい。
//Githubのニックネーム/リポジトリ名は自分用に変更して下さい!! Hi, GitHub Team I accidentally deleted a "Githubのニックネーム/リポジトリ名" repository. Can you resurrect it?その後、しばらく待つとGitHub Developer Supportからメールが届きます。
こんな感じです。
返信に大体10分ぐらいで返信が来ると思います。メールがきたらリポジトリを見て復元されているか確認をして下さい。
解決方法1の手順は以上になります!!解決方法 2 (復元に1時間ほどかかります)
手順1
ユーザー設定下記のHPをクリックします
https://github.com/settings/profile手順2
左メニューの Repositories をクリックします。
手順3
Deleted repositories タブをクリックします。
削除したリポジトリ一覧が表示されるので、復元したいリポジトリの Restore ボタンを押します。
注意!!
操作は簡単で復元はできますが
削除したリポジトリ一覧に表示されるまで、最大1時間くらいかかる場合があるそうです
公式に書いてありました。精神的にタフな方はこちらの解決方法で良いかもしれません。最後に
今後、このような失敗を減らすためにGitHubを勉強しなければならないと思いUdemyで勉強中です・・・
危うくgithubクラッシャーになりかけました・・・
- 投稿日：2021-01-07T17:45:47+09:00
[git]基本的なコマンド入門
はじめに
結構忘れてしまうことがあるのでこちらも備忘録としてメモしていきたいと思います！！
Git
バージョンの管理システムの役割をし、コードの修正履歴を記録します。
いつどこをなぜ修正したのかの確認、複数メンバーで共同開発をする際に使用します。
シェルコマンドで操作します。3つの場所
gitを使用する際はこの場所を考えながら操作をしていきます。
ワーキングディレクトリ
自分が作業を行なっている場所、ローカルリポジトリ
ステージングエリア
変更内容を仮登録する場所。indexともいう
リポジトリ
実際に変更内容が記録される所
もっと詳細が書いてあるのを貼っておきます。
使用したバージョン管理の機能
add, commitコードの変更を記録
log, diff状態や変更箇所を記録
reset, revert前の状態を復活
branch, checkout作業に合わせて分岐
push, merge作業結果を統合リポジトリを作る
確認をしていくために実際にディレクトリを作っていきます。
1. mkdir mysample （作業のするディレクトリを作る） 2. cd mysample (移動) 3. git init (initでリポジトリを作るとmysampleが記録対象になる) 4. ls -a (確認)↓ % ls -a . .. .git （隠しディレクトリができております）状態を確認するコマンドたち
git status現在のステージングやリポジトリの状態を確認できる
- git status -s もっとシンプルに見る
git logコミットの履歴を確認する
- git log --oneline
- git log -1 直近のログだけを確認できる
git branchどこのブランチにいるのか確認ができる
ls -al使っていく
「kiroku.txt」というファイルを作ったのでまず仮登録していきます。
git add kiroku.txt # 「git status」 で確認するとような感じ On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: kiroku.txtリポジトリに追加します。
git commitそうすると
「vim」というシェルで利用できるテキストエディタが開かれます。
Gitでコミットしようとすると、コミットメッセージの入力のために、自動的に起動します。コミットメッセージを入力します。
どんな変更をしたか、なぜ変更したのかを書いていきます。1st commit # ← （ここにコミットメッセージ） # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch master # # Initial commit # # Changes to be committed: # new file: kiroku.txt # ~ ~ # （下はまだ続いてます。）「vim」 はコマンドモードと編集モードを切り替えて使用します。
編集モードに切り替える。
- A 現在の行の末尾に入力する
- a 現在のカーソル位置の右から入力する
コマンドモード
- u 元に戻す-
- :wq 保存して終了-
- :q! 保存しないで終了うーむ・・ここら辺はまた今度深掘りしましょう・・・。
無事にコミットできると# 「git status」 で確認 On branch master nothing to commit, working tree cleanコミットできました！！
このようなリポジトリにコミットしたひとまとまりの状態を
「スナップショット」と言います。複数ファイル
「.」をつけるとワーキングディレクトリの全てのファイルを指定してくれます。
git add . # (「git status」 で見る) On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: kiroku.txt new file: kiroku2.txt仮登録とコミットを一度にやってくれるコマンドもあります。
git commit -a -m "2nd commit" # ↑コミットメッセージ
「-a」
ステージングエリアに登録済みのファイルの変更について仮登録とコミットを同時にやってくれる
「-m」
コミットメッセージを１行だけ指定できる「差分」を見る
どのような変更が行われたのかを確認します。
このような比較情報を「差分」と言います。git diff最新コミットとステージングエリアを比較します。
git diff --cached最新コミットとワーキングディレクトリを比較します。
git diff HEADこんな感じで出てきます。
mysample % git diff HEAD diff --git a/kiroku2.txt b/kiroku2.txt index 360cddf..db701bb 100644 --- a/kiroku2.txt +++ b/kiroku2.txt # (比較しているファイル) @@ -1 +1,2 @@ # ファイルがどのように変更されているか @@変更前 変更後@@ -おはようございます。 \ No newline at end of file # どのような違いなのか +おはようございます。 # 空白であれば変更なし +お元気ですか # 「-」 は削除 \ No newline at end of file # 「+」 は追加作業の履歴を取り消す
ステージング上の特定ファイルを一つ前の状態に戻したい時に使用します。
git reset kiroku.txtワーキングディレクトリのファイルを前の状態に戻します。
git checkout kiroku.txt最新のコミットを打ち消すコマンドです。
git revert HEADブランチを切る
作業内容に合わせてリポジトリを分岐する機能です。ブランチを使うと昨日の追加やバグの修正といった作業内容をリポジトリにまとめることが簡単にできます。
デフォルトでは「master」というブランチが用意されています。
ブランチを作ります。
git branch add_html # 「git branch」で確認してみます。 add_html * master # できた。切り替えます。
git checkout add_html * add_html master # できた。戻します。
git checkout master add_html * master # 戻った。コミットの仕方ははじめにやったものと基本同じなのでブランチを切って移動した後もやり方は同じです。 ・・・とのこと！！！！
わかりました！！！！！
ブランチをマージする
ブランチのデータをmasterブランチに統合します。
git checkout master git merge add_html Updating 019bd0d..2a3e430 Fast-forward kiroku.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)不要になりましたら
ブランチを削除します。git branch -d add_html Deleted branch add_html (was 2a3e430).ちなみに
ブランチを作って、移動をもっと簡単に入力するにはgit checkout -b add_html2 Switched to a new branch 'add_html2' # 「git log」 で確認してみます。 add_css * add_html2 master # 便利コンフリクトを解決する
同じファイルに別々の人が同じファイルを変更して統合するとコンフリクトという衝突が起きます。
ファイルを確認して、<<<<< や ===== で囲まれているところが
衝突部分なので残したいコードのみ残して消去するか、全てを変更するかします。<!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hello git</title> </head> <body> <h1>見出し</h1> <<<<<<< HEAD <p>ここはmasterです。</p> ======= <p>ここはadd_htmlです。</p> >>>>>>> add_html </body> </html>このような感じで。残したいもの以外は消します。
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hello git</title> </head> <body> <h1>見出し</h1> (これを消す) <!-- <<<<<<< HEAD --> <p>ここはmasterです。</p> <!-- ======= <p>ここはadd_htmlです。</p> >>>>>>> add_html --> </body> </html>最後に通常通り仮登録とコミットをします。
git add index.html git commitプロジェクトを複製する（クローンする）
他のメンバーと共同開発しているプロジェクトに参加する方法です。
1. mkdir sample (格納するディレクトリを作成する) 2. cd sample (移動) 3. git clone [共有リポジトリのファイルパス].git (複製する)共有した共同のリポジトリの情報を表示します。
git remote -v修正して、仮登録とコミットしたのち、
コミットを共同リポジトリに反映させます。git push origin masterまた、プロジェクトの変更を取り込みたい場合はこのようにします。
git pull [共有リポジトリのファイルパス].gitまとめ
なんだか後半急いでダッシュな感じになってしまったので、もう少し詳しく調べてみたいと思います。
後は情報を見る時のオプションも次回は詳しくみていきたいです。
今日は終わりです！
参考
最近調べものをすると頻繁に出会うことに気付いたサイト。
見た目も素敵ですので貼っておきませう。Gitについての色々な資料が載っている興味深いものも発見です。
- 投稿日：2021-01-07T17:45:47+09:00
[Git]基本的なコマンド入門
はじめに
結構忘れてしまうことがあるのでこちらも備忘録としてメモしていきたいと思います！！
Git
バージョンの管理システムの役割をし、コードの修正履歴を記録します。
いつどこをなぜ修正したのかの確認、複数メンバーで共同開発をする際に使用します。
シェルコマンドで操作します。3つの場所
gitを使用する際はこの場所を考えながら操作をしていきます。
ワーキングディレクトリ
自分が作業を行なっている場所
ステージングエリア
変更内容を仮登録する場所。indexともいう
リポジトリ
実際に変更内容が記録される所
もっと詳細が書いてあるのを貼っておきます。
使用したバージョン管理の機能
add, commitコードの変更を記録
log, diff状態や変更箇所を記録
reset, revert前の状態を復活
branch, checkout作業に合わせて分岐
push, merge作業結果を統合リポジトリを作る
確認をしていくために実際にディレクトリを作っていきます。
1. mkdir mysample （作業のするディレクトリを作る） 2. cd mysample (移動) 3. git init (initでリポジトリを作るとmysampleが記録対象になる) 4. ls -a (確認)↓ % ls -a . .. .git （隠しディレクトリができております）状態を確認するコマンドたち
git status現在のステージングやリポジトリの状態を確認できる
- git status -s もっとシンプルに見る
git logコミットの履歴を確認する
- git log --oneline
- git log -1 直近のログだけを確認できる
git branchどこのブランチにいるのか確認ができる
ls -al使っていく
「kiroku.txt」というファイルを作ったのでまず仮登録していきます。
git add kiroku.txt # 「git status」 で確認するとような感じ On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: kiroku.txtリポジトリに追加します。
git commitそうすると
「vim」というシェルで利用できるテキストエディタが開かれます。
Gitでコミットしようとすると、コミットメッセージの入力のために、自動的に起動します。コミットメッセージを入力します。
どんな変更をしたか、なぜ変更したのかを書いていきます。1st commit # ← （ここにコミットメッセージ） # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch master # # Initial commit # # Changes to be committed: # new file: kiroku.txt # ~ ~ # （下はまだ続いてます。）「vim」 はコマンドモードと編集モードを切り替えて使用します。
編集モードに切り替える。
- A 現在の行の末尾に入力する
- a 現在のカーソル位置の右から入力する
コマンドモード
- u 元に戻す-
- :wq 保存して終了-
- :q! 保存しないで終了うーむ・・ここら辺はまた今度深掘りしましょう・・・。
無事にコミットできると# 「git status」 で確認 On branch master nothing to commit, working tree cleanコミットできました！！
このようなリポジトリにコミットしたひとまとまりの状態を
「スナップショット」と言います。複数ファイル
「.」をつけるとワーキングディレクトリの全てのファイルを指定してくれます。
git add . # (「git status」 で見る) On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: kiroku.txt new file: kiroku2.txt仮登録とコミットを一度にやってくれるコマンドもあります。
git commit -a -m "2nd commit" # ↑コミットメッセージ
「-a」
ステージングエリアに登録済みのファイルの変更について仮登録とコミットを同時にやってくれる
「-m」
コミットメッセージを１行だけ指定できる「差分」を見る
どのような変更が行われたのかを確認します。
このような比較情報を「差分」と言います。git diff最新コミットとステージングエリアを比較します。
git diff --cached最新コミットとワーキングディレクトリを比較します。
git diff HEADこんな感じで出てきます。
mysample % git diff HEAD diff --git a/kiroku2.txt b/kiroku2.txt index 360cddf..db701bb 100644 --- a/kiroku2.txt +++ b/kiroku2.txt # (比較しているファイル) @@ -1 +1,2 @@ # ファイルがどのように変更されているか @@変更前 変更後@@ -おはようございます。 \ No newline at end of file # どのような違いなのか +おはようございます。 # 空白であれば変更なし +お元気ですか # 「-」 は削除 \ No newline at end of file # 「+」 は追加作業の履歴を取り消す
ステージング上の特定ファイルを一つ前の状態に戻したい時に使用します。
git reset kiroku.txtワーキングディレクトリのファイルを前の状態に戻します。
git checkout kiroku.txt最新のコミットを打ち消すコマンドです。
git revert HEADブランチを切る
作業内容に合わせてリポジトリを分岐する機能です。ブランチを使うと昨日の追加やバグの修正といった作業内容をリポジトリにまとめることが簡単にできます。
デフォルトでは「master」というブランチが用意されています。
ブランチを作ります。
git branch add_html # 「git branch」で確認してみます。 add_html * master # できた。切り替えます。
git checkout add_html * add_html master # できた。戻します。
git checkout master add_html * master # 戻った。コミットの仕方ははじめにやったものと基本同じなのでブランチを切って移動した後もやり方は同じです。 ・・・とのこと！！！！
わかりました！！！！！
ブランチをマージする
ブランチのデータをmasterブランチに統合します。
git checkout master git merge add_html Updating 019bd0d..2a3e430 Fast-forward kiroku.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)不要になりましたら
ブランチを削除します。git branch -d add_html Deleted branch add_html (was 2a3e430).ちなみに
ブランチを作って、移動をもっと簡単に入力するにはgit checkout -b add_html2 Switched to a new branch 'add_html2' # 「git log」 で確認してみます。 add_css * add_html2 master # 便利コンフリクトを解決する
同じファイルに別々の人が同じファイルを変更して統合するとコンフリクトという衝突が起きます。
ファイルを確認して、<<<<< や ===== で囲まれているところが
衝突部分なので残したいコードのみ残して消去するか、全てを変更するかします。<!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hello git</title> </head> <body> <h1>見出し</h1> <<<<<<< HEAD <p>ここはmasterです。</p> ======= <p>ここはadd_htmlです。</p> >>>>>>> add_html </body> </html>このような感じで。残したいもの以外は消します。
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hello git</title> </head> <body> <h1>見出し</h1> (これを消す) <!-- <<<<<<< HEAD --> <p>ここはmasterです。</p> <!-- ======= <p>ここはadd_htmlです。</p> >>>>>>> add_html --> </body> </html>最後に通常通り仮登録とコミットをします。
git add index.html git commitプロジェクトを複製する（クローンする）
他のメンバーと共同開発しているプロジェクトに参加する方法です。
1. mkdir sample (格納するディレクトリを作成する) 2. cd sample (移動) 3. git clone [共有リポジトリのファイルパス].git (複製する)共有した共同のリポジトリの情報を表示します。
git remote -v修正して、仮登録とコミットしたのち、
コミットを共同リポジトリに反映させます。git push origin masterまた、プロジェクトの変更を取り込みたい場合はこのようにします。
git pull [共有リポジトリのファイルパス].gitまとめ
なんだか後半急いでダッシュな感じになってしまったので、もう少し詳しく調べてみたいと思います。
後は情報を見る時のオプションも次回は詳しくみていきたいです。
今日は終わりです！
参考
最近調べものをすると頻繁に出会うことに気付いたサイト。
見た目も素敵ですので貼っておきませう。Gitについての色々な資料が載っている興味深いものも発見です。
こちらはコマンドがたくさん載っています。
- 投稿日：2021-01-07T15:40:32+09:00
error: You have not concluded your merge
事象 : git pullしたら怒られた
- 環境
- Windows10 Pro バージョン1909
- git version 2.25.0.windows.1
$ git pull error: You have not concluded your merge (MERGE_HEAD exists). hint: Please, commit your changes before merging. fatal: Exiting because of unfinished merge.こうなるまでの経緯は...# 1. プルしないでローカルを変更してコミットした $ git commit -m 'プルしないでローカルを変更してコミットした' #...省略... # 2. プッシュしようとしたらプルしろって怒られた $ git push To https://github.com/username/repo.git ! [rejected] feature/braname -> feature/braname (fetch first) error: failed to push some refs to 'https://ponsuke:keyval@github.com/username/repo.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 integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. # 3. だからフェッチしたらリモートに変更があった $ git fetch --all --prune Fetching origin remote: Enumerating objects: 29, done. remote: Counting objects: 100% (29/29), done. #...省略... # 4. プルしたらマージが発生して、 $ git pull hint: Waiting for your editor to close the file... # 5. コメント用にエディタが開いたが、うっかりそのエディタを閉じてしまった・・・ $ # 6. 再びプルすると怒られた $ git pull error: You have not concluded your merge (MERGE_HEAD exists). #...省略...原因 : コミットしていないマージがあるから
メッセージのざっくり訳エラー:マージが完了していません(MERGE_HEADが存在します)。 ヒント:マージする前に変更をコミットしてください。 fatal:マージが完了していないため終了します。対応 : マージをリセットする
ちょっとよくわかんなくなったので、取り敢えずマージをリセットしてやり直すことにした
マージをリセットする$ git reset --mergeプルからやり直す# 再びプルしてエディタでマージコメント書いて $ git pull hint: Waiting for your editor to close the file... error: There was a problem with the editor '"C:\apps\Sublime Text 3\sublime_text.exe" -w'. Not committing merge; use 'git commit' to complete the merge. Merge made by the 'recursive' strategy. #...省略... # コミットしろとメッセージにあるのでコミットして $ git commit On branch feature/braname Your branch is ahead of 'origin/feature/braname' by 2 commits. #...省略... # プッシュしていないコミットがマージ分と自分の変更の2つあることを確認して $ git log origin/feature/braname..feature/braname commit b9... (HEAD -> feature/braname) Merge: e2... e5... #...省略... commit e2... #...省略... # プシュる $ git push Enumerating objects: 16, done. Counting objects: 100% (14/14), done. #...省略...
- 投稿日：2021-01-07T15:26:17+09:00
gitignoreのnode_modulesをコメントアウトした話(Git初心者)
対象読者
.gitignoreとnode_modulesをよくわかっていない人AdminLTEをインストールした時
Bootstrap3の管理画面等のテンプレートテーマであるAdminLTE。
これをyarnでインストールした時に、3種類の箇所が変更になる。$ yarn add admin-lte[変更箇所]
1. node_modelesディレクトリ配下にAdminLTEのパッケージファイルを生成
2. yarn.lockファイルを生成
3. package.jsonにAdminLTEのバージョンを追記しかし、2, 3は確認できたが、1については確認ができなかった。
とういより、VS codeでnode_modulesが検索できない。調べると、
.gitignoreに以下の記載のせいだとわかる.gitignore# Ignore uploaded files in development /storage/* !/storage/.keep /node_modules /yarn-error.logIgnore uploaded files in developmentとあるように、
node_modules配下のディレクトリを無視している。自分:
「アップロードされたファイルを無視しているんだね。じゃあこの記述をコメントアウトしよう」.gitignore# Ignore uploaded files in development /storage/* !/storage/.keep # コメントアウト # /node_modules /yarn-error.log「よし、
node_modulesが表示された。これで無問題。」・
・
・講師:
「はいアウト〜〜」なぜnode_modulesをignoreしているのか
自分は考えなしに
.gitignoreの設定を変え、node_modulesをコメントアウトしました。そもそも、なぜ
node_modulesをなぜ.gitignoreに書く必要があるのでしょうか。
.gitignoreとはその名の通り、記載したディレクトリ配下、ファイルをignore(無視する)ためのものです。もっとわかりやすくいうと、Gitの変更管理から外す、ということです。Gitの変更管理から外して良いファイルなんであるのと思われるかも超初心者の方、ありますよ。
例えば、今回の題材であるnode_modules配下のファイルです。
node_modules配下にはパッケージのファイルが置かれます。
パッケージのファイルとは、AdminLTEなど外部からインストールすることでその機能を定義したファイルです。
つまり、このnode_modules配下では変更されるファイルがないということなのです。
すなわち、ファイル自体に更新することはないので、gitの変更管理の対象にする必要がそもそもないということ
そして、もしそれらのファイルを管理してしまうと、変更管理する必要のないたくさんのファイルを変更管理するというなんとも無駄なことをしてしまうのです。
よって、
.gitignoreからnode_modulesをコメントアウトしてはいけません。自分みたいにならないように気をつけてください笑
node_modulesが表示されなかった原因
VS codeの設定が原因でした。
詳しくは参考記事へ。簡単に設定できます。
- 投稿日：2021-01-07T13:01:25+09:00
Command Lineでよく使うコマンドについて
はじめに
Gitの勉強を始めようと思いましたが、そもそもCommandLineの知識が不足していたのでそちらの勉強を優先させました。定期的にコマンドを使っていないと忘れそうなので、こちらにまとめておきます。
ファイルを作成するとき
touch ファイル名現在いる場所に空のファイルを作ることができる。
例：touch first.txtファイルの中身を確認するとき
cat ファイル名ファイル名を指定することで、そのファイルの中身を確認することができる。
例：cat first.txtフォルダを作る時
mkdir フォルダ名make directoryの略
例：mkdir htmlフォルダ移動する時
cd フォルダ名change directory の略
例：cd html１つ親のディレクトリに移動するとき
cd ..１つ親のディレクトリに移動する時、フォルダ名を指定しても移動できない。上記のように指定する必要がある。
例：cd ..カレントディレクトリを確認するとき
pwdルートディレクトリからカレントディレクトリまでの階層が全て表示され
例：pwd
→ /home/htmlフォルダの中身を確認するとき
lslist の略
カレントディレクトリの１つ子の階層のファイルとディレクトリを確認できる
例：ls隠しファイルも含めて確認するとき
ls -a-aは all の略
ホームディレクトリに移動するとき
cdcdの後にフォルダ名を指定しなかったときはホームディレクトリに移動する。
ファイル・ディレクトリの操作
ファイル・フォルダを移動する
mv ファイル名（もしくはフォルダ名） フォルダ名moveの略
指定したファイルまたはフォルダを指定したディレクトリに移動させることができる。
例：mv first.txt html
（first.txtというファイルをhtmlというフォルダに移動）例:mv html programing
（htmlというフォルダをprogramingというフォルダに移動）ファイル名・フォルダ名を変更する
mv 現在のファイル名（もしくはフォルダ名） 新しいファイル名（フォルダ名）例：mv first.txt second.txt
（first.txtというファイルをsecond.txtという名前に変更）ファイルをコピーする
cp コピー元のファイル名 新しいファイル名copyの略
例：mv first.txt second.txt
（first.txtというファイルをsecond.txtという名前に変更）フォルダをコピーする
cp -r コピー元のフォルダ名 新しいフォルダ名例：mv html css
（htmlというファイルをcssという名前に変更）
フォルダをコピーする際は [-r]を忘れないように注意する。ファイルを削除する
rm ファイル名removeの略
例：mv first.txt
（first.txtというファイルを削除する）フォルダを削除する
rm -r フォルダ名例：mv html
フォルダを削除する際は [-r]を忘れないように注意する。
- 投稿日：2021-01-07T11:34:25+09:00
Git-it（Git/GitHub学習アプリケーション）のインストール手順
Git、GitHubを学習する際にお世話になったこちらのアプリケーション。
下記のサイトより、インストールが可能となっていますが、
今回は、CLIからの方法でインストールする手順を書きたいと思います。
初学者あるあるなのかは分かりませんが…、
どうもまだCLI操作がうまくいかず、インストールにだいぶ時間を取られてしまいました…。素直にzipファイルからインストールすればいいだけなのですが、
ターミナルを起ち上げ、「バシッ」とコマンドを決めインストールする姿に憧れ、トライしてみました。そんな僕と同じようなCLIビギナーに、こちらの情報がお役に立てば幸いです。
インストール先はこちら
git-it-electron（CLIはこちらから）
https://github.com/jlord/git-it-electrongit-it-electron(zipファイルはこちらから)
https://github.com/jlord/git-it-electron/releases/tag/3.1.0インストール手順
環境
- OS：macOS Big Sur
- ブラウザ：Google Chrome
Windows、Linuxでも利用可能のようです。1. ターミナルを起動させる。
まず、お使いのターミナルを起動させホームディレクトリへ移動してください。
2. git cloneする。
上記のURLにアクセスし、下記のHTTPSを選択しコピーする。
コピーしたHTTPSを、引数へ指定するため以下のように記述します。
$ git clone https://github.com/jlord/git-it-electron.gitこれでインストールは完了です。
3. 中身を確認する。
以下のディレクトリが作成されています。
$ ls git-it-electron4. git-it-electronへ移動する。
$ cd git-it-electron5. npmをインストールする。
で、ここからが私が詰まったポイントです。
アプリケーションは無事にインストールされたようですが、どうやって起動するのか？
ここでだいぶ悩みました…。
GUI上のFinderからディレクトリ内を確認し起動できるアプリケーションを探したのですが見つからず…(zipファイルでインストールした場合はアイコンが出現します）色々と調べた結果、Node.jsが必要とのことでした。
Node.jsとはサーバサイド側で動くJavaScriptで、新たにnpm（Node Package Managerの略）をインストールする必要がある。とのことでした。
Node.js とは
Node Package Manager の略。
JavaScript 系のパッケージを管理するツール。
必要とするパッケージをインストールする際、依存するパッケージもまとめてインストールしてくれる。
ライセンスは Artistic License。GPL に似ているが、改造版を再配布する際に名称変更が必要な点が異なる。
npm パッケージを集めたリポジトリ (npmjs.com) が運営され、40万ものパッケージが登録されている。 引用：npm入門 - とほほのWWW入門以下のコマンドを入力しNode.jpをインストールします。
$ npm installインストールされているか確認する方法。
$ npm -v 6.14.46. npmを使い、アプリケーションを起動させる。
ここまで来たら後は起動させるだけです。
以下のコマンドを入力。$ npm start成功した場合、以下の画面と共にアプリケーションが起動します！
終了したい場合は、
ctrl + C
あとは、手順に沿ってGit/GitHubの学習を進めることができます。
アプリケーションの内容ですが、
Git、GitHubの基本について、手順を追って手を動かしながら学ぶことができ、最後はプルリクエストを実際行うところまで学習できます。Git、GitHubを始めたばかりの人から、しばらく触ってないなーと復習したい人まで、早い人だと1時間、平均3〜4時間程度で学べるそうです。（僕はだいぶかかりましたが…）
気になった方は、ぜひ一度チャレンジしてみてください！
- 投稿日：2021-01-07T09:54:39+09:00
sourcetreeでリポジトリを初期化できなかった話
初めに
開発会社でGitを使っているなら、おそら導入しているであろうSorceTree。
今回は、そんなSourceTreeを使っている中で起きた事象を書いていく。
事象
いつものようにgithubからclone用のURLをコピーしてきてSourceTreeで
新規->URLからcloneを選択してURLを貼り付けてクローンを実行。
リポジトリを初期化するために、
リポジトリ -> Git flow / Hg flow -> リポジトリを初期化を選択。
エラー発生
特に何もいじらず、OKを押下したところエラーが発生。
masterは存在しないとな。。。
よくわからん。
ということで早速Google先生に相談。すると以下の記事を発見
https://www.publickey1.jp/blog/20/githubmainmastermain.htmlGitHubは、これから新規に作成されるリポジトリのデフォルトブランチ名が「main」になると発表しました。これまでデフォルトブランチ名は「master」でした。なになに、masterからmainに変更されたとな。
解決
ということは
赤枠部分をmasterからmainに変更すればいいってことだな
早速変更してみる
これでOKを押下してみると
developブランチが作成されました?
最後に
今回、Git flow / Hg flow -> リポジトリを初期化
でProductionブランチにmasterが入っていたことに起因する事象を解決しました。productionブランチにデフォルトでmasterではなくmainが入力されることを願うばかりです。
- 投稿日：2021-01-07T08:32:31+09:00
コンフリクトしたのでrebaseしたい
- 投稿日：2021-01-07T03:49:31+09:00
Macのローカル環境からGitLabにssh接続し、ソースコードをcloneする
はじめに
エンジニア転職をして最初の課題である環境構築でタイトルの作業を行いましたが、（一応）経験のあるGitHubと異なる作業が必要で若干戸惑ったため備忘録としてにまとめた次第です。
目標
ローカルからGitLabにssh接続してcloneする。
やること一覧
- sshキー（公開鍵と秘密鍵）の作成
- 公開鍵をGitLlbに登録
- configファイルの作成
- gitコマンドでGitLabからcloneする
やっていきましょう
sshキー（公開鍵と秘密鍵）の作成
コマンド実行後に入力を求められるが、全て無視してreturnを押下。
（キーの保存場所とパスワードを求められているので、必要があれば設定する）$ ~/.ssh $ ssh-keygen -C "your@email.com" -t rsa
-C：コメントを指定。通例ではメールアドレスを記載する。-t：作成する鍵の暗号化形式を指定。参考：【 ssh-keygen 】コマンド――SSHの公開鍵と秘密鍵を作成する
lsで確認すると.ssh配下に公開鍵（id_rsa.pub）と秘密鍵（id_rsa）が作成されている。$ ~/.ssh/ls id_rsa id_rsa.pub公開鍵をGitLlbに登録
公開鍵（id_rsa.pub）の中身をクリップボードにコピーする。
$ pbcopy < ~/.ssh/id_rsa.pub一旦ターミナルから離れ、GitLlbのsettingsから'SSH keys'を選択。
Keyの箇所に先程コピーした公開鍵をそのままペーストする。
Titleは自分でわかりやすければ何でも良い。configファイルの作成
ターミナルに戻り
~/.sshにconfigファイルを作成する。$ vi ~/.ssh/config以下の内容で
~/.ssh/configを記載した。Host //ホスト HostName //ホスト名 User //GitLabのユーザー名 IdentityFile ~/.ssh/id_rsa //秘密鍵のパスHostNameの記載で「？？？」となったが、例えばGitLabのURLが
https://hoge-hoge.hello.jp:xxxx/xxxだった場合、"https"から":"直前までのhttps://hoge-hoge.hello.jpと記載。
Hostも同様の記載で統一。//例 Host https://hoge-hoge.hello.jp HostName https://hoge-hoge.hello.jp User your-name IdentityFile ~/.ssh/id_rsagitコマンドでGitLabからcloneする
ターミナルから離れ、GitLabのcloneしたいプロジェクト画面のへ行き、プルダウンメニュー
SSHの文字列をコピー。
ssh://hoge-hoge.hello.jp:xxxxx/xxx/xxxxxxx.git←こんなやつターミナルに戻り、GitLabからcloneするディレクトリを作成し、移動。
$ git cloneコマンドの後ろにコピーした文字列をペーストし実行。$ mkdir ~/projects $ cd ~/projects $ git clone ssh://hoge-hoge.hello.jp:xxxxx/xxx/xxxxxxx.gitこれでcloneできれば完了。