There is no active source control providers.
または
ソース管理プロバイダーが登録されていません

って出てる場合は以下記事をチェックで直せる。
http://7081.hatenablog.com/entry/2018/03/02/081044
https://blog.janjan.net/2019/10/15/vsc-not-found-source-manage-provider/

ただ、
・上記のメッセージが出ず、
・VSCodeをつかって他のリポジトリを表示してるときはうまく表示される
・SOURCE CONTROL　にGITと表示されない
という場合は、SOURCE CONTROLの下で右クリックするとリポジトリが選択肢がでてくるので選択すると表示されるようになる。
超簡単なんだけど、小一時間困ったのでいつか誰かの助けになれば。

従来の npm installを実行すると、 package.json と package-lock.json の両方を見て依存関係の解決と依存パッケージの node_modules へのインストールを行います。

動いてるのを確認してから、commitする。

❌　gem install bundler

⭕️rbenv exec gem install bundler

bash_profileにエイリアス設定したもの。

参考：https://qiita.com/naokazuterada/items/072f28ee15f8fe86bdec

$ touch text.txt

これでtext.txtファイルが作られる

rm -rf

rfについて

r=(リカーシブ)recursive
f=再帰的　フォース　

これはゴミ箱にも行かず完全に消し去る。

そのため、すごく慎重に使う。

https://github.com/search/advanced

全然草が生えなくて困ったので記事にしてみました。

TL;DR

• Githubでリポジトリを作成してからcloneしたらおきた
• githubのpublic emailの設定をしていなかったらusers.noreply.github.comになってた
• githubのアカウントの設定なおした
• リポジトリのautherを変更した
• 草生えた

初めに

先週4日間ほどまとまった休みが取れたので、久しぶりに自主開発でもしようと思い、githubでリポジトリを作りました。
そのあとSource Treeでローカルにクローンして環境構築の過程でコミットを重ねていたのですが、どうにも草が生えません。

確認したこと

• githubのメールアドレス
  • settings/Emails の Primary email address はログイン時に使用しているものが設定されていた。
• ローカルのメールアドレスもgithubと同じものが設定されていた。
• 基本的にはローカルのメールアドレスとユーザー名がコミッターとしてリポジトリの変更履歴に残る。
• initial commitのコミッター名は Googlesensei@users.noreply.github.com このような形式になっていた。

調べてみると

If you enabled email address privacy, then the commit author email address cannot be changed and is @users.noreply.github.com by default. In the upper-right corner of any page, click your profile photo, then click Settings. In the left sidebar, click Emails.

どうやら public email address として登録が済んでいない場合、デフォルトでgithubドメインのメールアドレスを利用した形式で登録されるらしい。
なので、いくらコミットしてもgithub側では同一人物として見られていなかった。

リポジトリの製作者：Googlesensei@users.noreply.github.com
リポジトリの変更者：Googlesensei@example.com(仮)

変更してみると

github/settings/Profile の Public email にローカルのメールアドレスと同じものを登録し、テストコミットをしてみるたけど、それでもまだ草は生えなかった。

ここで気になっていたの initial commit の作者 Googlesensei@users.noreply.github.com だ。
source treeからは変更できないのでCLIで変更し、リモートへプッシュ。

草生えた

というわけでようやく環境構築も済ませることが出来たのでこれからガシガシコード書いていきたいと思います。
githubに草を生やすことが目的ではないですが、自分の行動履歴のようなものにもなるので、ちゃんとコーディングしたなら生えてほしいですもんね。

草生えてなかったｗ：追記

どうやら草を生やす要件の一つに、デフォルトブランチにコミットをすることが必要条件がありました。
かくしてデフォルトブランチをdevelopに変更することで草が見事に生えました(生えてなかった日のも生えました)

参考

githubのサポートページ
GitのCommitユーザを修正する方法

まずは前置き。これは自分への自戒でもある。

ろくにコード管理をしてこなかったのを今更ながらまぁまぁ後悔しています。 gitやってなかった自分への戒めも込めて残しておこうと思います。

事前にやっておくこと（その1）

偉大なる先人たちがいらっしゃるため、以下2点は割愛致しまする。
(リンクは貼っておきますので参照ください。)

Gitのインストール
　→ ターミナルはGitBushを使用します。

githubアカウントの所持
→ まぁ、そりゃやってありますよね。。

事前にやっておくこと(その2)

これは自分のやり方残しておこうと思います。

｜gitへの登録作業

1.ユーザー名(githubでのユーザー名)

git config —global user.name “****”

2.email(githubでのemailアドレス)

git config —global user.email “****”

3.エディタの登録作業(ここではvscodeを指定)

git config —global core.editor “code —wait”

と入力

ローカルレポジトリを作成する

1.GitBushを起動後、git管理するディレクトリまで移動

2.コマンド「git init」を入力

git init

3.コマンド「git add ***」を入力。
(***の部分にはファイル名やフォルダ名などを入力する。以下のコマンドは管理するフォルダ内、全てを対象にする。)

git add .
もしくは
git add hoge.txt

4.隠しフォルダとして”.git”が同一階層に作成されていることを確認

コミットする

1.コマンド「git commit」を入力する。

2.エディタが開くので変更内容を入力する。

3.入力が終わったらエディタを保存して閉じる。

4.コマンド「git status」を入力して、「nothing to commit~」的な内容が返ってくればコミットは無事終了です。

git commit
(エディタが開きます)

git commit -m "Hello Github"

リモートレポジトリを作成する

1.githubページへ移動、ログインする。

2.「New repository」を選択する。

3.必要項目を入力。最後に「Create repository」を押すと新規作成されます。※repositorynameとプライベートorパブリックを選択すればあとは好きに選んでください。

4.画像のような状態になったら[HTTPS]を選択して、右側のコピーアイコンを押す。

さぁ、もうちょっと

ローカルリポジトリの編集内容をリモートリポジトリへプッシュする

一度、git statusでcommitされているか確認

On branch master
nothing to commit, working tree clean

これが返ってくれば大丈夫です。
では、いよいよpushします。

git remote add orijin <githubでコピーしたやつ貼り付け>

git remote 
<add時のリモートリポジトリ名が返ってくる>

git push -u origin master
 * [new branch]      master -> master
 ↑こんな内容が返ってくればOK

Githubのリモートレポジトリで確認

確認できたでしょうか？
ひとまずはここまでで終了です。

「Gitについて何も知らないのに現場に放り込まれてしまった」

そんなことになったら、まず何をどうすればいいのか混乱することがほとんどだと思います。
コピペしてローカル環境でソースを修正しようとしたら「Cloneして作業してください」と言われてCloneとコピペの違いが分からなかったり、「コミットしてください」「プルしてください」と言われたところで何が行われているのか当然最初は分かりません。

Gitの入門書を見たり、ググってみたら漠然とどういう動作しているのかはわかるかもしれませんが、Gitの挙動は初学者ですと、少し調べただけでは何がどうなっているのか直感的には分かりにくいです。

さて、以下Gitを用いる開発現場に放り込まれた初学者は、とりあえず深いこと考えずに以下のことだけを、最低限の予習だと思って押さえてください。

当然これだけでは足りないですし、現場の運用方針やルールによっては他にも覚えるべきことは出て来ると思います。
しかし、取るものとりあえず以下のことだけ覚えておくのと、何も知らない状況ですと現場に入って作業にとりかかるまでのスピードと精神的安定感は全然違います。

１．基本のコマンドは「add,commit,push,pull」のサイクルと「diff,status,checkout」

基本は以下のサイクル

git add (ファイル名）
　ディレクトリ以下すべてをaddしたい場合「git add .」とする

git commit -m 'コメント'
　これでローカルリポジトリにコミットする

git push
　ローカルリポジトリにコミットしたものをリモートリポジトリに反映させる。
これで他の人がpullしたら自分の変更分を反映できる。

git pull
　他人がローカルリポジトリにコミットしたものを自分のところに反映させる。

その他基本的なコマンド

・git reset
「addするのやっぱやめた」で最初は覚えておけばいい。

・git checkout（ファイル名　あるいは全部反映したいのなら「.」）
　作業中に、最後にpushないしpullした状態に戻したくなった時に使用するコマンド。
本来、もっと別の意味があるが、最初はそのような使い方でもいい。

・git diff
　addする前に打ち込むと、自分が変更した部分が出て来る。
これを見て自分が編集した覚えが無いものが上がっていた場合、自分のミスか、
あるいは他人の編集をデグレしてしまうことがあるため、
git resetでaddを取り消す。

・git status
　addした後、commitの前に入力すると、変更されたファイルが確認できる。
これを見て、リポジトリにあげたくないものがあった場合、git resetで取り消す。

２．git initとgit clone、git remote -v

リモートリポジトリ（pushする先）をgit initで作成する。もし、複数の人が共有できるようにするならば「git init --bare --shared」と入力。
git initしたリポジトリを自分の開発環境でローカルリポジトリに持ってきて編集する場合は「git clone (パス)」を用いる。
また、ローカルリポジトリが、どこをcloneしたものか忘れた場合は「git remote -v」を用いればパスが表示される

３．「.gitignore」ファイルを作ってリポジトリにあげたくないファイルを指定する

「git add .」とすればディレクトリ内のすべてがaddされてしまうし、いちいちあげたくないもの（特にIMGやデータファイルなど）は、gitignoreに正規表現で記入しておけば、add時に該当ファイルは対象外にしてくれる。

これらは必要条件

以上、現場に入るときに最低限覚えておくべきことについてまとめました。
無論、上記のことは最低限ですので、もしかしたらもう少し求められる（ブランチ切るなど）こともあり得ます。ただ、ここで書いたことで無駄になるものは絶対ないですし、全部最低限必要条件ですので、身に着けておくべきです。
ここで書いてある用語でよくわからない言葉（「リモートリポジトリ」とか）は調べてみてください。

まとめ—最低限覚えておいた方がいいコマンド

git add
git commit
git push
git pull
git reset
git checkout
git diff
git status
git remote
git init
git clone

その後、恐らくリポジトリ内に余計なファイルが管理されてしまうことがあると思います。その時に「いらないファイル消せ」と先輩に言われたときに「gitで登録されてるファイルってどうやって消すんだろう。えーと…そうか、『git rm』か」と言った感じで必要に応じて使えるものを増やしていきましょう。

git submodule update ができない

問題点

submoduleを含むgitのリポジトリをクローンしたが、submoduleの中身が空っぽだった。
そこで git submodule update をしてみたが、

$ git submodule update

Please make sure you have the correct access rights and the repository exists.
fatal: clone of '[shhのキー]' into submodule path '[ローカルのパス]' failed 
Failed to clone '[submoduleのリポジトリ]'. 
Retry scheduled Cloning into '[ローカルのパス]'...
Host key verification failed.
fatal: Could not read from remote repository.

以下のようなログが返ってきた。

解決策 .git/configを書き換える

.git/config内のsubmodule部分のurlをsshからhttpsに変更する。

---

.git/config

[submodule "サブモジュール名"]
    url = git@gitlab.com:******* # ssh

この部分を書き換える。

.git/config

[submodule "サブモジュール名"]
    url = https://gitlab.com/****** # https

---

別の解決策としてSSHの公開鍵を登録する方法もあります。

今回は.git/configを書き換えてgit submodule update をしたら、
空っぽだったsubmoduleのフォルダにsubmoduleのプログラムを導入することができました。

submoduleを使いこなせるようになりたいものです。以上！

参考

• https://kagasu.hatenablog.com/entry/2019/05/17/002443

目次

今回の確認内容

前回のコミットに対してtagをつけてみます。

git tag

以下のコマンドを実行します。

$ git tag -a v001 -m "first tag"

オブジェクトがどのように変わったかを見ていきます。
差分は以下の通りです。

├── .git
│   ├── objects
│   │   ├── 8b
│   │   │   └── e68ce70275726ea093eb5da6c1fe9c9566bd7e
│   └── refs
│       └── tags
│           └── v001

新しく追加されたオブジェクトの中身を見てみます。

$ git cat-file -t 8be68ce70275726ea093eb5da6c1fe9c9566bd7e
tag
$ git cat-file -p 8be68ce70275726ea093eb5da6c1fe9c9566bd7e
object 2deb1b0751cbfeffdc75683b2f61e476ef970640
type commit
tag v001
tagger Chapa <hoge@hoge.com> 1581461073 +0900

first tag

前回コミットした際にできたコミットオブジェクト（2deb1b0751cbfeffdc75683b2f61e476ef970640）とタグが紐づいていることがわかります。
試しに何もコミットしないでさらにタグを追加してみます。

$ git tag -a v002 -m "2nd tag, no changes"

差分は以下のようになりました。

├── .git
│   ├── objects
│   │   ├── ab
│   │   │   └── ca15c3e8b8f5db47539ad14551806eb2f57df4
│   └── refs
│       └── tags
│           └── v002

オブジェクトの中身を見てみます。

$ git cat-file -t abca15c3e8b8f5db47539ad14551806eb2f57df4
tag
$ git cat-file -p abca15c3e8b8f5db47539ad14551806eb2f57df4
object 2deb1b0751cbfeffdc75683b2f61e476ef970640
type commit
tag v002
tagger Chapa <hoge@hoge.com> 1581461574 +0900

2nd tag, no changes

新規にコミットをしていないので、v001と同じコミットオブジェクトが記載されています。
タグに関しては順序性がないので、「/refs/tags/」配下を見ても同列にv001とv002が存在し、タグオブジェクト以外に変更点はありません。

タグに対応するオブジェクトのハッシュ値は「/refs/tag/」配下のファイルを見るとわかります。

$ cat .git/refs/tags/v001
8be68ce70275726ea093eb5da6c1fe9c9566bd7e
$ cat .git/refs/tags/v002
abca15c3e8b8f5db47539ad14551806eb2f57df4

以下のgitのコマンドでも確認可能ですが、どこに何が作られるかを理解していると単純にcatでも情報が確認できます。

$ git rev-parse v001
8be68ce70275726ea093eb5da6c1fe9c9566bd7e
$ git rev-parse v002
abca15c3e8b8f5db47539ad14551806eb2f57df4

今回のおさらい

git tagを叩くと、どのコミットに対してどこにタグ情報やコミットとの関連が作られていくかがわかりました。意外とgitのコマンドがわからなくてもcatで必要な情報が見つかることもわかりました。