記事の目的

READMEをGithubにて編集後、git pushしたら ! [rejected] master -> master (fetch first) errorなどと言われ、その対処法を書いた記事になります。
筆者は、プルリクとかマージとかはやったことがあるけれども、失敗してログが出るとビビってしまう初心者of初心者なレベルです。
同じようなレベルで困っている方にログを示しながら、丁寧に解説することにより助けとなれば幸いです。（参考書や記事等をソースに書いております。）

解釈や理解が間違っていたら、ご指摘頂けると幸いです。

環境

Rails6,ローカル環境

git pushしたら ! [rejected] master -> master (fetch first) errorと言われる

zen_fumi$ git push origin master
To https://github.com/XXXXX.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/XXXX/XXXX.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.

以下の記事にこのログが出たらgit fetch && git merge origin/masterしてからpushすればOKと書いてあったのでそのように対処しました。
https://qiita.com/takanatsu/items/fc89de9bd11148da1438

zen_fumi$ git fetch
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Total 26 (delta 14), reused 14 (delta 14), pack-reused 12
Unpacking objects: 100% (26/26), done.
From https://github.com/XXXX/XXXX
   a0a483e..b9b2fac  master          -> origin/master
   b16c768..87e5c6f  Like_function#5 -> origin/Like_function#5
zen_fumi$ git merge origin/master
Merge made by the 'recursive' strategy.
 README.md | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
zen_fumi$ git push origin master
Enumerating objects: 34, done.
Counting objects: 100% (28/28), done.
Delta compression using up to 4 threads
Compressing objects: 100% (12/12), done.
Writing objects: 100% (13/13), 1.19 KiB | 611.00 KiB/s, done.
Total 13 (delta 9), reused 0 (delta 0)
remote: Resolving deltas: 100% (9/9), completed with 6 local objects.
To https://github.com/XXXX/XXXX
   b9b2fac..205a9cc  master -> master

コマンドはうまく入ったようですが、何が起きているのさっぱり。
基礎知識を入れて理解してみました。

まず、git fetchとは何？[ノンプログラマーなMacユーザーのためのGit入門から引用]

フェッチ(fetch)という操作を行うと、リモートブランチをリモート追跡ブランチに取得できる。そうすることで、リモートブランチの変更点をローカルブランチに反映する前に、リモートブランチの内容を確認できるわけです。確認後ローカルブランチにて反映してよければ、リモート追跡ブランチをローカルブランチにマージすればOKです。プルは、フェッチとマージという一連の処理を組み合わせたものです。

fetchによって、リモートで変更（READMEを編集）を反映させたリモートのmasterブランチをリモート追跡ブランチに取得できるんですね。

リモート追跡ブランチとは？と聞こえてきました。説明します。

リモート追跡ブランチとは？[ノンプログラマーなMacユーザーのためのGit入門から引用]

origin/masterのようにorigin/~となっているもので、リモートリポジトリではありません。(git branch -aでorigin/~を確認してみてください)
リモートリポジトリをローカルにコピーしたもので、そのブランチは「リモート追跡ブランチ」と呼ばれます。リモート追跡ブランチは読み取り専用のブランチでユーザが直接変更することはできません。

イメージしにくい方は、以下の記事を読むとよりイメージを理解することができました。
https://shinmedia20.com/git-remote-tracking

ややこしいですが、リモートリポジトリのリモートブランチを追跡しているローカルに存在しているブランチとでもいえるでしょうか。

まとめ

概念を入れた上で一連の流れをまとめます。

ローカルからリモートにpushしようとしたが、まずGithubでREADME.mdを編集しmasterに反映させた部分をローカルに反映させる必要があった。
だから注意されました。

そして、ローカルに反映させる為に
リモート(Github)でREADME.mdを編集して反映させたリモートブランチをfetchによってリモート追跡ブランチに取得。
その後、git merge origin/masterにより、リモート追跡ブランチ(リモートで変更したmasterブランチが呼ばれている)をローカルブランチにマージします。（上の説明・記事を読めば origin/masterの意味が理解できますね）

以上です。マニアックでお役に立てる気がしませんが、参考になれば幸いです。

普段は作業ディレクトリに移動して実行することが多いコマンドについて、作業ディレクトリを指定するオプションをまとめました。（ツールに偏りがありますが・・・）

artisan (Laravel)

実行したいプロジェクトの artisan ファイルを絶対パスで指定する。

php /path/to/project/artisan migrate

Composer

--working-dir オプションまたは -d オプション

composer install --working-dir=/path/to/project
composer install -d /path/to/project

Global Options - Command-line interface / Commands - Composer

Git

-C オプション

git -C /path/to/project pull

-C - Git - git Documentation

npm

--prefix オプション

npm install --prefix /path/to/project

prefix - config | npm Docs

Yarn

--cwd オプション

yarn --cwd /path/to/project install

Specify working directory with yarn --cwd - CLI Introduction | Yarn

（記事内で用意したプレビューが YouTube 動画のため別リンクになっている点、ご了承くださいませ。（参考にさせていただいた記事））

自身でやっているブログのテンプレート（Hugo のテンプレート）に不具合を見つけて「どうせだしプルリク送るかー」と思ってプルリクを送ったらマージしてもらえたときのお話です。

こんなブログです

見つけた不具合

ブログの記事を PC で表示しているときに右側に表示されている Table of Contents の欄。クリックするとその項目のところまでヌメっと動きます。

項目名にマルチバイト文字が入っている際にうまくいきませんでした。

どうやって直す方法を探したか

エラーメッセージでいろいろググっていたら以下のような記事を見つけました。

jQuery を用いたページ内スクロール: リンク先 ID 値が日本語である場合、エラー "Syntax error, unrecognized expression" が発生 - DEV

ID 値に日本語（マルチバイト文字）が含まれている場合うまくいかないのでは？となり、上記サイトに従って this.hash を decodeURI(this.hash) にしたところ、

うまくいきました！！

リポジトリをフォークしてプルリクエストを送るまで

OSS にプルリクエストを送る流れは以下のようになります。

• OSS のソースコードをフォークする

そうすると自分のところにリポジトリをクローンしたような形になります。

• 自分のリポジトリで新しくブランチを作成してソースコードをいじる

• プルリクエストを送る

自分も初めてだったのでわからなかったのですが、フォークしたリポジトリと元のリポジトリを比較してプルリクエストを送ることができるみたいです。

実際のプルリクエストは こちら

見事マージされて、 OSS に貢献することができました。

貢献するのは意外と難しくない

今回 OSS に貢献するうえで初めて Git の Fork を使用しましたが、それ以外はプルリクエストを送るくらいで、普段の開発＋αくらいで貢献できたので、貢献するだけなら意外と難しくないのかもしれません。

大変だったのは、プルリクエストを英語で書くところです。

ちょいちょい Google 翻訳を使用しつつ書きましたが、それでも管理者の方にちゃんと受け入れていただくことができました。

OSS を利用するにあたって

OSS を使用するうえで最も留意しなければいけない点は、 OSS 自体にバグがあるかもしれない という点です。

開発で外部のサービスを利用するのは確かに便利ですが、そのサービスの不具合やダウンによって、自分の製品にも影響があるということを忘れてはいけません。

ですが、どうしても利用したいとき、動作してくれないと困るとき、それは世界中探せば同じ問題で困っている人がいるかもしれません。

思い切ってプルリクエストを送って承認されれば、自分の市場価値を少しだけ高められると思います。

みなさんもぜひやってみてください。

はじめに

複数のリポジトリ間で統一しておきたいファイルをそれぞれのリポジトリで別々に管理していた場合、変更や修正を各リポジトリそれぞれで行う必要があり、リポジトリ間での差分発生や変更の反映漏れなどの可能性があります。
本記事では、複数のリポジトリ内で共通のファイルやコンポーネントを使い回したい時の解決方法として、Git subtree を使用した解決方法を提示します。

Git subtree を 30 秒で（なんとなく）理解する

シンプルに説明すると、
「プロジェクト内の特定のディレクトリのみ、別のリモートリポジトリにも push/pull することができるようになる」
というようなイメージが近そうです。

共通で使用したいファイルをディレクトリ単位で別リポジトリに切り離し、git subtree コマンドを使用することでファイルの共通化を図ります。
例として 『Nuxt を使用した複数プロジェクト間での components ディレクトリの共通化』 を考えていきます。

本記事での仮定

共通ファイル（今回は components）を管理するリポジトリと、2 つ以上の Nuxt プロジェクトを管理するリポジトリを用意したと考え、話を進めていきます。
また Nuxt プロジェクト A/B に関しては、create-nuxt-app（v3.4.0） にてプロジェクトを作成したものと同等のディレクトリ構成とします。

• 共通コンポーネントリポジトリ
  • プロジェクトルート直下に .vue 拡張子の単一コンポーネントファイルが保存されます。
• Nuxt プロジェクト A
• Nuxt プロジェクト B

subtree の設定方法

Git subtree によるコンポーネントの共通管理は、大きく分けて 2 step で設定できます。
共通コンポーネントを使用するプロジェクト A/B にて、subtree の設定を行います。

step 1. リモートリポジトリの設定

プロジェクト A/B のリポジトリに共通コンポーネントリポジトリをリモートリポジトリとして設定します。

$ git remote add common-components {{ リポジトリのURL }}

リポジトリの URL は clone とかの時に指定するやつです。また common-components 部分は、任意の名前で指定できます。
設定されたかどうかは $ git remote で確認でき、今回の例では origin と別に common-components がリモートリポジトリとして追加されていれば OK です。

step 2. subtree の設定

リモートリポジトリに追加した common-components を、各プロジェクトの subtree として設定します。

共通管理したいのは components ディレクトリ配下のみですので、そのディレクトリのみで push/pull を行うことができるように subtree として設定を行います。
以下のコマンド実行時に --prefix=components によって subtree 用の components ディレクトリが作成されるため、 create-nuxt-app で自動生成された components ディレクトリは一度削除します。

$ git subtree add --prefix=components --squash common-components main

step 1 で指定した共通コンポーネントリポジトリ （common-components）の main ブランチの中身が components ディレクトリとして展開されます。
これで共通コンポーネントリポジトリへの subtree push/pull を行うことができるようになりました。

なお、プロジェクト内で共通コンポーネント編集時の commit や origin への push/pull は普通にできます。
あくまで subtree として設定されているリポジトリにも push/pull ができるようになったというだけです。

subtree の push/pull コマンド

origin への push/pull とは別に、サブツリー用の push/pull コマンドがあります。

origin への push/pull では、プロジェクトのリモートリポジトリには変更が保存されるものの、subtree 側には変更が反映されないため、共通コンポーネントを変更した場合は subtree push/pull を行い、共通コンポーネントのリモートリポジトリを更新します。

// プロジェクトの変更を subtree に反映する
$ git subtree push --prefix=components {{ リポジトリのURL }} main

// subtree の変更をプロジェクトに取り込む
$ git subtree pull --prefix=components {{ リポジトリのURL }} main

プロジェクト A で subtree push を行なった後、プロジェクト B で subtree pull を実行することでコンポーネントの変更を取り込むことができます。
なお各プロジェクトに subtree として登録されている共通コンポーネントのリポジトリでは、通常通り $ git pull コマンドによって各プロジェクトからの変更をプルします。

プロジェクト間での作業手順を整理（仮）

Git-Flow だとこのような運用が良いのではないか、と考えた程度のものですので参考までに。
運用していく上でより良い方法があれば更新予定です。

1. プロジェクト A のトピックブランチでコンポーネントの追加・変更作業を行い、PR（プルリク）を作成
2. PR 承認後、main にトピックブランチがマージされたタイミングでプロジェクト A から subtree にプッシュ
3. プロジェクト B で subtree pull 用のトピックブランチを作成し、subtree から共通コンポーネントの追加・変更分をプル
4. コンポーネント追加分を取り込み、PR 作成
5. プロジェクト B でレビュー完了後、main にマージ

運用上の課題

コンポーネントを追加・変更する上で外部パッケージを追加し、package.json を変更した場合、subtree の管理外ですので各プロジェクトごとに package.json を変更する必要があります。
プロジェクト間で連絡を取り合って解決するか、components ディレクトリ内に README.md などを置き、パッケージの追加時に記載するなどの運用を行なった方が良いかもしれません。

参考

• Git subtree
• 【ATLASSIAN Blog】 Git Submodule の代替: Git Subtree
• 【ATLASSIAN Blog】 Git subtree のパワー
• 【手順】git subtreeコマンドの使い方

はじめに

aliasとは英語で別名という意味
gitのコマンド(status,commit,diffなど)に自分で別名を設定できます。

設定方法

設定の仕方はgit config [option] alias.変更後コマンド 変更前コマンドを実行します。

例えばgit commitをgit cmと短縮したい時は

git config alias.cm commit

gitに設定したaliasを確認したい時はgit config --list | grep ^alias\.

git config --list | grep ^alias\.

alias.cm=commit

設定したaliasを削除したい時はgit config --unset alias.変更後コマンド

git config --unset alias.cm

またaliasを反映させる範囲も指定できます。

マシン全体に反映させたい場合 --system

git config --system alias.cm commit

ユーザー単位で反映させたい場合 --global

git config --global alias.cm commit

optionを何も書いてない場合はリポジトリ単位で反映されます。

最後に

何か間違っている点などありましたらご指摘いただけると幸いですm(__)m

はじめに

Sourcetree でスタッシュを適用したときに下記のように怒られたときの対処法です。

Please, commit your changes or stash them before you can switch branches.

もちろん差分なんてなにもない。。。でも怒られる

対処法

とりあえずきれいにすればいい

下記コマンドで追跡対象外のファイルとディレクトリを削除します。

$ git clean -n
$ git clean -df

これでもダメならいったん他のブランチに切り替えて上記コマンドを実行してみる（わたしはこれで復帰できました）。

おわりに

今まではスタッシュに置いてるやつはちょっとした修正だけだったのであきらめてたけどこれで復帰できるようになりました

Git はこの際ターミナルで扱うようにしてもいいかもしれない

ここ見ればだいたいできそう。

Gitコマンド早見表

参考

• git clean

はじめに

2020年8月に入社した新人エンジニアです。

gitコマンド??????? なんか難しいからSourceTree使お...
とずっとSourceTreeを使っていたのですが...

遡ること１ヶ月前。
とある先輩に

「SourceTree禁止！！！最低でも１年間、Gitが使いこなせるようになるまではGitコマンドを使え！！！！！！！」

とのお言葉を頂きまして...（本当はもっと優しく言ってくださいました。）
今まで使ったGitコマンドや使い方などを備忘録として残しておこうと思います。

リモートリポジトリのURL
https://github.com/◯◯◯◯/◯◯◯◯.git

開発ブランチ
development
masterから切ったブランチ。作業ブランチをココにマージする。

自分の作業ブランチ
feature/test
developmentから切ったブランチ。機能の追加や修正をするブランチ。

【git clone】リモートリポジトリのソースをローカルにクローン

$ git clone https://github.com/◯◯◯◯/◯◯◯◯.git

リモートリポジトリにプッシュするまで...

// developmentブランチで
$ git checkout -b feature/test

// 現在のブランチの確認
$ git branch

// ステージングに追加・コミット
$ git add .
$ git commit -m 'コミットメッセージ'

// ブランチを移動
$ git checkout development

// リモートリポジトリとの差分を確認
$ git fetch

// リモートのdevelopmentの最新ソースをローカルのdevelopmentにプル
$ git pull origin development

// 作業ブランチに移動
$ git checkout feature/test

// ローカルのdevelopmentブランチのソースをfeature/testブランチにマージ
$ git merge development

// コンフリクトしていないか確認
$ git status

// リモートリポジトリにプッシュ
$ git push origin feature/test

// Github上でプルリクエストを作成！
// Githubからdevelopmentにマージしたら、リモートのdevelopmentも最新にしておく
$ git checkout development
$ git pull origin development

コミット後、安全にリモートブランチにプッシュする方法は先輩に伝授していただきました⇨【安全にリモートブランチにPushする】

【git branch】ローカルブランチの一覧を表示

ローカルにあるブランチは何？
自分は今どこのブランチにいるの？
を確認する時に使う。

$ git branch
* development
  feature/test

「*」があるところが現在のブランチ

【git checkout -b】新しくブランチを切って、そのブランチに移動

現在のブランチから新しいブランチを切ることになるので、現在のブランチは何か？を確認しておく。

$ git checkout -b feature/test

$ git branch
  development
* feature/test

【git add】編集・追加・削除したファイルをステージングに追加

コミットしたいファイルを追加する。

変更したファイル全てをステージングに追加↓

$ git add .

ファイルごとにステージングに追加したい↓

$ git add welcome.blade.php

【git commit】ステージングに追加したファイルをローカルリポジトリに記録

git logでコミット履歴を見た時に、
何をしたのかひと目で分かるようなメッセージを書く！

$ git commit -m 'コミットメッセージ'
[development fbcdc2f] コミットメッセージ
 1 file changed, 1 insertion(+), 1 deletion(-)

【git checkout [ブランチ名]】ブランチの移動

別のブランチに移動したい時。

$ git branch
  development
* feature/test // 現在のブランチ

$ git checkout development

$ git branch
* development // 現在のブランチ 「*」が移動している
  feature/test

【git fetch】リモートリポジトリから最新の情報を取得する

ローカルリポジトリのorigin/developmentが最新になる。
この時点では自分の作業ファイルなどは変更されない。

$ git fetch

【git merge】取得した最新の情報を現在のブランチに取り込む

git fetchで最新情報を取得した後に行う。
ここまですると、自分の作業ファイルも変更される。

$ git merge development

【git pull】リモートリポジトリの最新のソースをローカルリポジトリに取り込む

git fetchとgit mergeを一気に行っている。

$ git pull origin development

【git status】前回のコミットからの変更内容を表示

git add したっけ？
git commitしたっけ？
今どんな状態？
を確認する時に使う。

git addする前↓

$ git status
On branch development
Your branch is up to date with 'origin/development'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   Test/resources/views/welcome.blade.php

no changes added to commit (use "git add" and/or "git commit -a")

git addした後、git commitする前↓

$ git status
On branch development
Your branch is up to date with 'origin/development'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   Test/resources/views/welcome.blade.php

【git push】ローカルリポジトリにコミットした履歴をリモートリポジトリにアップロード

$ git push origin feature/test
  .
  .
  .
  * [new branch]      feature/test -> feature/test

エラーが出なければGithub上でプルリクエストを作成できる。
レビューしてもらい、OKだったらGithub上からdevelopmentにマージしてもらう。

【git log】今までのコミット履歴を確認する

コミットメッセージが一覧で表示される。

$ git log
commit 1ab995b929ff92a4d180d7d0786e0f6496c884dd (origin/feature/test)
Author: emika_0402 <emika_0402@test.co.jp>
Date:   Mon Dec 21 12:00:00 2020 +0900

    コミットメッセージ

コミット履歴を１行で表示したい時は↓

$ git log --oneline
1ab995b (origin/feature/test) コミットメッセージ

【git checkout】ステージング前のローカルの変更を破棄する

全ての変更を破棄↓

$ git checkout .

指定したファイルの変更を破棄↓

$ git checkout Test/resources/views/welcome.blade.php

【git branch -m】ローカルのブランチ名を変更する

$ git branch
* development
  feature/test

// feature/test を feature/test2 にしたい
$ git branch -m feature/test feature/test2

$ git branch
* development
  feature/test2

【git branch -d】ローカルのブランチを削除する

マージ済みのローカルブランチを削除する時↓

$ git branch -d feature/test

どんなブランチでも削除できる↓

$ git branch -D feature/test

さいごに...

新しく使ったgitコマンドがあったらどんどん増やしていこうと思います！

初めに

知ってる人にとっては当たり前ですが、わからなかったのでとりあえずメモ書き程度に。

Gitの管理レポジトリ作成時の注意点

そのプロジェクトがあるディレクトリに.gitファイルを製作すること。
ユーザーファイルなんかに製作すると、そのフォルダの変更点が全部未コミットとしてでてきます。
リポジトリの作成前にそのディレクトリが正しい場所にあるか確認しましょう。

[]は必要ないので消す

リポジトリが作られてない場合

git init
git add [ファイル名]
git add .
git commit -m ""
git remote add origin [url]

リポジトリがすでにあるプロジェクトの場合

git clone [url]

gitが重くてクローンできない場合

git clone --depth 1 http://hoge.com/hoge.git
git fetch --depth 5
git fetch --depth 20
git fetch --unshallow

branchを切り替え忘れた場合

git checkout [branch名]
できない場合
git stash
git checkout [branch名]
git stash pop

※コンフリクトを起こす場合があるのでその時はどちらを優先するか考える

コミットを戻す場合

git reset --hard HEAD^(変更も取り消し)
git reset --mixed HEAD^(commitとaddを取り消し)
git reset --soft HEAD^(コミットのみ取り消し)

プッシュを戻す場合

git push -f origin [commit ID]:master

変更を退避、確認、戻す

git stash
git stash push -- [path]
git stash list
git stash pop

差分ファイルの作成

git archive [branch名] --format=zip -o files.zip `git diff --name-only --diff-filter=d [過去] [最新] `

ファイルの削除

git rm ファイル名
git rm -r フォルダ名
※ワークツリー（ローカルのファイル、フォルダ）も消えるので注意
git rm --cached ファイル（リポジトリのみ削除なので.gitignoreに削除のファイル名を書けば追跡から外れる）

VSCodeくんから「早くGitを更新しなさい！」とありがたい通知を受け取った、2020年冬。

Git for Windowsの最新版を設定しようとしたところ、新しい設定が増えていたのでメモの代わりとしてまとめました。
※なるべく原文の意味を崩さず確認したいと思ったため、DeepLを使って翻訳したものをそのまま載せています

概要

Git for Windows (Ver 2.29.2.2) あたりで追加されている新規設定を順に追っていきます
設定し終わったあとに気付いたのですが
Only show new opstions （新しいオプションのみ表示）という項目にチェックを入れていると（今回のインストールではデフォルトがチェック済みでした）言葉どおり新しい設定のみ表示されるようです

新規設定のみ確認ができる便利機能ですが、これに慣れてしまうと通常の設定方法を忘れそうな気がしています・・・
また、設定の細かい部分は検証していないため、参考程度でお願いします

動作環境　OS：Windows10

設定をしよう

Git for Windows インストーラーのダウンロードまでが終わったものとして進めていきます
※★マークは今回選んだ設定というメモ書きなので、必ずしもそれが正しいとは限りません

1. Information

セットアップを続ける準備ができたら、Nextをクリックします。

2. 新規リポジトリでの初期ブランチ名の省略

git init の後の初期ブランチの名前を Git にどうしてほしいですか？

Git に決めさせましょう　★選択
新しく作成したリポジトリの最初のブランチには、Git のデフォルトのブランチ名 (現在は: "master") を使用します。Git プロジェクトは近い将来、このデフォルトのブランチ名をより包括的な名前に変更する予定です。
「master」という言葉をはじめ、差別的なイメージを連想させる言葉を別の言葉に置き換えようという動きが起こっているため → Gitとブランチの命名について

新しいリポジトリのデフォルトのブランチ名を上書きする
多くのチームがデフォルトブランチの名前を変更しています。一般的な選択肢は "main"、" trunk" および "development" です。最初のブランチに使用する "git init" の名前を指定します。
ここで入力した名前が git init コマンドで最初に作成されるブランチ名となる

この設定は既存のリポジトリには影響しません。

3. git pull のデフォルトの動作を選択します

git pull はデフォルトではどうすればいいのでしょうか？

Default：デフォルト (fast-forward または merge)　★選択
これは git pull の標準的な動作です。可能であれば現在のブランチを取得したブランチに早送りします。

git pull -–ff が実行される

通常は Default (fast-forward or merge) を選択することが多い

Rebase：リベース
現在のブランチを取得したブランチにリベースします。リベースするローカルコミットがない場合、これは fast-forward と同じです。

git pull –-rebase が実行される

Only ever fast-forward：ファストフォワードのみ
フェッチされたブランチに早送りします。それができない場合は失敗します。

git pull –-ff-only が実行される

注意：Git 2.27より git pull 時に警告メッセージが出る場合があるようです　
分岐したブランチを調整する方法を指定せずに pull するのはお勧めしません、とのこと・・・

• Git 2.27 リリースノート
• 警告ソース部分
• Git 2.27 での git pull 時の warning について

4. Credential Manager の選択

どの Credential Manager を設定する必要がありますか？

Git Credential Manager Core　★選択
新しいクロスプラットフォーム版の Git Credential Manager を使いましょう。今後のGit Credential Managerの詳細はこちらをご覧ください。→ Git Credential Manager Core
Git Credential Manager Core（GCM Core）とは：WindowsおよびmacOSで実行される.NETCore上に構築された安全なGit資格情報ヘルパー

Git Credential Manager（廃止予定）
Git Credential Manager for Windows は、Azure DevOps や GitHub などの資格情報を処理します。 (.NET framework v4.5.5.1 以降が必要)。→ Git Credential Manager for Windows

None：なし
Credential Managerを使用しないでください。

5. 実験的オプションの設定

どのような最先端の機能を有効にしたいですか？

疑似コンソールの実験的なサポートを有効にします。 ★選択しない
これにより、Winptyを使わずにNodeやPythonのようなネイティブコンソールプログラムをGit Bashウィンドウで実行できるようになりますが、まだ既知のバグがあります。

6. Installing

Setup が Git をコンピュータにインストールするまでお待ちください。

7. Git セットアップウィザードの完了

セットアップはGitのインストールを終了しました。インストールされているショートカットを選択してアプリケーションを起動することができます。Finish をクリックして Setup を終了します。

• Git Bush を起動する
• リリースノートを見る

これでインストール作業（バージョンアップ）は終了となります
資格情報ヘルパーや実験オプション等、まだ理解が追いついていないところはデフォルトのまま設定しましたが、特に問題なく動作しています?

参考

わかりやすいインストール方法をまとめてくださっているサイト様

• GitをWindowsにインストールする方法｜Git For Windows 2.28.0
• 私家版 Git For Windowsのインストール手順
• Git for Windows のインストール手順

各バージョン情報の変更点など

• Git for Windows 2.28.0
• Highlights from Git 2.28
• Git for Windows 2.29.0
• Highlights from Git 2.29

目的

• 自分のローカルにないリモートブランチを取得する方法をまとめる

詳細

※ 実行するコマンドはすべてローカルリポジトリ内で実行するものとする。

1. 最新の状態を取得する。

   $ git fetch
   

2. リモートブランチの一覧を表示する。

   $ git branch -a
   

3. リモートブランチをローカルリポジトリにチェックアウトする。（ローカルリポジトリでの表示ブランチ名は任意のもので良い、しかしリモートブランチ名と合わせることが自然である。）

   $ git checkout -b ローカルリポジトリでの表示ブランチ名 origin/リモートブランチ名
   

4. ローカルリポジトリにリモートブランチと同じブランチがない場合下記のコマンドでもチェックアウトする事ができる。

   $ git checkout リモートブランチ名
   

参考文献

• https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9

パソコンを変えたとき用のやることまとめ

vscodeダウンロード

https://code.visualstudio.com/download

homebrewのインストール

https://brew.sh/index_ja
ターミナルにペースト

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

gitのダウンロード

https://git-scm.com/download/mac
ターミナルにペースト

brew install git

vscodeとgitの接続

ユーザー名の登録

ターミナルにペースト

git config --global user.name "GitHubに登録しているユーザー名"

ユーザーアドレスの設定

ターミナルにペースト

git config --global user.email "GitHubに登録しているメールアドレス"

githubとvscodeの接続をオープンエディタの画面から？

なんか接続するための画面が出てくるのでそれを許可

ssh鍵を作成する

ターミナルに貼り付ける

ssh-keygen

これを入れたらとりあえずenterしたらpasを作成しろと出るので作成
そしてもう一度入力

ssh鍵の登録

ターミナルに貼る

ssh-add -K パスワードを入れたファイル?

正しく登録されたかの確認

ssh-add -l

鍵の中身をコピー

pbcopy < ファイル名

GithubのSettingsを開き、Githubに鍵登録
New SSH keyを押して鍵に命名
そして鍵部分に先程コピーされたものをそのまま入れる

鍵接続

ssh-add ファイル名.pub

vscode設定

code .を使えるようにする

command + shift + p
Shellと入れる
installを選ぶ

拡張機能

liveserverの追加

node周りセットアップ

nodebrewインストール

brew install nodebrew

node.jsインストール

先にディレクトリ作成してるといい感じ

mkdir -p ~/.nodebrew/src

安定版のをインストール

nodebrew install-binary stable

パスを通す

echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bash_profile

mySql接続

npm

npm install mysql

python

pythonを直接インストール

https://www.python.org/downloads/

anacondaインストール

https://www.anaconda.com/products/individual
guiとcli両方インストールしてもいいかもしれない

セットアップ色々

https://prog-8.com/docs/python-env
これ通りにやれば基本間違いない

完了

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

git登録周り
https://note.com/cd_ss_829/n/n4e7d80723381
https://qiita.com/yu0313/items/4f95fc0b7e544c42e107

公開鍵周り
https://www.velumi.com/guides/vs-code-get-permission-denied-publickey-mac/
https://qiita.com/luccafort/items/92d9643ac9ddecc0cadd
https://www.atnr.net/permission-denied-error-on-git-pushing/
https://qiita.com/takuyanin/items/c6a097028a837052c90c
https://qiita.com/tnatsume00/items/e147662368d02e6416d2

vscode設定周り
https://qiita.com/ayatokura/items/69c96306e3dee501e19b

git fetch origin master
↓
git reset --hard origin/master（強制的にpullする）
↓
EC2インスタンス再起動（これをしないとunicornの起動時にエラー）
↓
unicorn_rails -c /var/www/rails/mumu(アプリの名前)/config/unicorn.conf.rb -D -E production(unicornの起動)
↓
sudo nginx -s reload（Nginxの再起動）
↓
sudo service mysqld start（mysqlを起動していなかったら）