Udemy『もう怖くないGit！チーム開発で必要なGitを完全マスター』学習メモ

---

・masterブランチはリリース用とし、別のブランチを作成して開発作業する。(49.ブランチを利用した開発の流れ)
・ワークツリー(作業領域)→ステージ(リポジトリへのコミットを準備する領域)→ローカルリポジトリ(ここまではローカル領域)→リモートリポジトリ(GitHub)という各領域で何が起きているかをイメージしながら作業する。

---

ローカルリポジトリの新規作成(.gitディレクトリが作成される)

git init

Gitの設定を確認する

git config --list

GitHub上にあるプロジェクトから始める場合

git clone (リポジトリ名。GitHubよりURLをコピペする)

変更をステージに追加する

git add (ファイル名orディレクトリ名)
git add .
↑全て追加される場合

変更状況を確認する(リポジトリ←→ステージ間、ステージ←→ワークツリー間で変更されたファイルを確認する)

git status

変更をコミットする

git commit
atomの場合コミットメッセージタブが立ち上がるので、コメント入力後command+Sで保存してXマークでタブを閉じるとコミットが完了する。

変更差分を確認する

git addする前の変更分
git diff
git diff (ファイル名)

git addした後の変更分
git diff --staged

変更履歴を確認する

git log

一行で表示する
git log --oneline

ファイルの変更差分を表示する
git log -p (ファイル名)

表示するコミット数を指定する
git log -n(コミット数)

ファイルの削除を記録する

git rm (ファイル名)
git rm -r(ディレクトリ名)

ファイルを残したいとき(リポジトリからのみ削除したい)
git rm --cached

ファイルの移動を記録する

git mv (旧ファイル)(新ファイル)

以下のコマンドと同じ
mv(旧ファイル)(新ファイル)
git rm (旧ファイル)
git add (新ファイル)

リモートリポジトリを新規追加する

git remote add origin (GitHubのURL)

リモートリポジトリの設定を変更する

他人のリポジトリからプルしてきた場合等は下記コマンドで紐付けを削除し、上のコマンドで再設定する。
git remote rm origin

リモートリポジトリへ送信する

git push (リモート名)(ブランチ名)
git push -u origin master
(初回以降はgit push origin masterのみでOK)

コマンドにエイリアスを付ける

(globalオプションを付けるとPC全体の設定になる)
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout

gitignoreファイルの編集

ファイル新規作成し、プロジェクトファイル下の「.gitignore」ファイルを作成。
・シャープから始まる行はコメント
・ルートディレクトリを指定
/root.html
・ディレクトリ以下を除外
dir/
・/以外の文字列にマッチ「」
//*.css

ファイルへの変更を取り消す

・git checkout (ファイル名orディレクトリ名)
・全変更を取り消す
git checkout -- .

ステージに追加した変更を取り消す

git reset HEAD (ファイル名orディレクトリ名)
・全変更を取り消す
git reser HEAD .
ステージに追加した変更を取り消すだけで、ワークツリーの変更は取り消されていないので注意。

直前のコミットをやり直す

git commit --amend
(リモートリポジトリにプッシュしたファイルは取り消してはいけない！その場合、再度コミット・プッシュすること！)

リモートを表示する

リポジトリ名のみ：git remote
URLを表示：git remote -v

リモートから情報を取得する(フェッチ)

git fetch (リモート名)
git fetch origin

リモートから情報を取得する(プル)

git pull (リモート名)(ブランチ名)
git pull origin master
git pull のみに省略可能

下記コマンドと同じ
git fetch origin master
git merge origin/master

リモートの詳細情報を表示する(git remoteコマンドよりも詳しい情報を表示する)

git remote show (リモート名)
git remote show origin

リモート名を変更・削除する

git remote rename (旧リモート名)(新リモート名)
git remote rm (リモート名)

ブランチを新規追加する

git branch (ブランチ名)

ブランチ一覧を表示する

・git branch
リモートリポジトリ含めて全てのブランチを表示する
・git branch -a

ブランチを切り替える

git checkout (ブランチ名)

ブランチを新規作成して切り替える
git checkout -b (ブランチ名)

変更履歴をマージする

git merge (ブランチ名)
git merge (リモート名/ブランチ名)
例：git merge origin/master

Fast Foward：早送りになるマージ（ブランチを前に進めるだけのマージ）
Auto Merge：基本的なマージ（変更を統合するマージ）

現在のブランチの名前を変更する

git branch -m (ブランチ名)

ブランチを削除する

git branch -d (ブランチ名)
強制削除する場合
git branch -D (ブランチ名)

プルリクエストの流れ

新しいブランチを作成する
(変更を加える)
コミット、プッシュする
GitHubでプルリクエストを作成
Reviewersを選択
(レビュワー側)Files chenged等をレビューしてコメントを付けるか、approve(承認)
承認されたらマージし、最初に作成した新しいブランチを削除する
ワークツリーにリモートからプルし、こちらでも最初に作成した新しいブランチを削除する

GitHub Flow

・masterブランチは常にデプロイできる状態に保つ
・新開発はmasterブランチから新しいブランチを作成してスタート
・定期的にpushする
・masterにマージするためにプルリクエストを行う
・必ずレビューを受ける
・masterブランチにマージしたらすぐにデプロイする
←テストとデプロイ作業は自動化

リベースで履歴を整えた形で変更を結合する

git rebase (ブランチ名)

---

GitHubにプッシュしたコミットをリベースしてはならない。git push -f(強制上書きプッシュ)は絶対NG
・プッシュしていないローカルの変更にはリベースを使い、プッシュした後マージを使おう。コンフリクトしそうならマージを使おう。

---

リベース型のプル

git pull --rebase (リモート名)(ブランチ名)

リベースで複数の履歴を書き換える

git rebase -i (コミットID)
例：git rebase -I (HEAD~3)
（コミットメッセージが立ち上がる）やり直したいコミットをeditにする
git commit --amend で修正
git rebase --continue で次のコミットに行く

コミットを並び替える

git rebase -i HEAD~3

コミットを削除する

タグの一覧を表示する

git tag

タグ付けする(基本的にリリースポイントに付ける)

git tag -a (タグ名) -m "(メッセージ)"
例：git tag -a "20200310" -m "version 20200310_1"

後からタグ付けする

git tag (タグ名)(コミット名)
git tag 20200310 8a6cbc4

タグのデータを表示する

git show (タグ名)
git show 20200310

タグをリモートリポジトリに送信する

git push (リモート名)(タグ名)
git push origin 20200310

タグを一斉に送信する

git push origin --tags

作業を一時避難する

git stash

避難した作業を確認する

git stash list

避難した作業を復元する

git stash apply
ステージの状況も復元する
git stash apply --index
特定の作業を復元する
git stash apply (スタッシュ名)
git stash apply stash@[1]

避難した作業を削除する

git stash drop
特定の作業を削除する
git stash drop (スタッシュ名)
git stash drop stash@[1]
全作業を削除する
git stash clear

$ git add index.html
$ git commit index.html

とコマンドするよりも、以下コマンドであれば一コマンドで済みます。

$ git commit index.html -a

Git では、git commit コマンドに -a オプションを指定すると追跡対象となっているファイルを自動的にステージしてからコミットを行います。
git add と git commit を連続でコマンドしている方はシンプルなショートカットを使っていきましょう。

不具合の背景

それまで普通に使用していたが、ちょっと大きめの push をしようとした時にエラーが発生した。
ググると似たような事例があったのですぐ解決したが、エラーコードが若干違ったりしていたので、
今回の事例でも対応できたという記録の意味で残しておく。

エラーの内容

エラー

RPC failed; curl 56 recv failure

解決方法

git のプロンプトを開いて下記コマンドを入力すると成功した。

コマンド

git config --global http.postBuffer 524288000

原因

バイナリデータがリポジトリに含まれていると起こることがあり、
git のバッファを増やすことにより解決することがあるようだ。
また、サーバー側に原因がある場合もあるようなので、確認できるならそちらを調べてみるのも良いかもしれない。

<参考>
gitで大きいサイズのファイルを扱う時
git clone時にbufferが足りなくてエラーになった話

また、上記コマンドを実行しても上手くいかない場合、再起動すると動いた事例もあった。

<参考>
SourceTree、Gitでpull出来なくなったときのメモ2

それでも解決しない場合

別リポジトリで上記対応をしても clone ができないものがあったが、
無線LAN から 有線LAN に変更すると clone できた。
通信速度が原因だったと思われるが参考までに。

1. プッシュするまでの流れ

ステージングにあげる

$ git add [file]
$ git add .

ワークスペースに戻したい

$ git reset [file]

コミットする

$ git commit -m [comment]

プッシュする

$ git push [destination] [branch]

ただし、リモートリポジトリの同一名称のブランチにpushする分には引数は省略可能。

2. ブランチ

HEADとは現在のコミットの位置を表すポインタ。checkoutコマンドはこのポインタの指す場所を変更するコマンド。
なので、ブランチ名だけでなくコミットのSHA１_IDを指定することも可能。

$ git checkout [branch]
$ git checkout -b [branch] #作成して移動
$ git checkout [SHA1_ID]

$ git branch [branch] #作成
$ git branch -d [branch] #削除

3. スタッシュ

Stushとは一時退避場所。
ステージングに変更がある状態ではブランチを移動できない。その旨のエラーが出る。そこで使用するのがStash。
移動前に格納して、移動後に取り出す。上記はmaster→branchDevへ移動する例。

$ git stash       # stashに格納
$ git stach list  # 一覧表示
$ git stash pop   # 取り出し

4. マージ

複数のブランチを一つにするときにはコンフリクトが生じることがある。
それを解決するのがmergeである。
ファイルを編集し、再度コミットすることでマージできる。
取り込む側のブランチ上でこのコマンドを実行する。

$ git merge [branch]

5. クローン

ブランチ全てを持っては行かない。追跡用のそのブランチへのパスだけ持っている。
必要であればcheckout [branch]とすると$git checkout -b branch remotes/origin/[branch]と等価な実行結果が得られる。

$ git clone [already_exist_branch] [new_branch]  #作成

6. ベアリポジトリ

作業場のないリポジトリ。github上に置いているリモートリポジトリはこれに当たる。
編集方法はpushのみ。

$ git clone --bare [already_exist_branch] [new_bare_branch]  #作成

7. remoteコマンド

リモートリポジトリの情報を取得。

$ git remote -v show originとすることで、リモートのoriginと自身を比べて最新か更新があるかがわかる。

remote origin
Fetch URL: /Users/username/bare_test
Push URL: /Users/username/bare_test HEAD branch: master Remote branches:
  branchB tracked
  branchC tracked
  branchD tracked
Local branch configured for 'git pull': 
  master merges with remote master
Local ref configured for 'git push': 
  master pushes to master (up to date)

8. プル

fetchしてmergeしている。

(1) コンフリクトしない易しい時

(2) コンフリクトしためんどくさい時

9. リモートへの新規ブランチ作成

ローカルで作った後に反映させる。

$ git push --set-upstream origin [new_branch]

10. rebaseを使う

base（ブランチが枝分かれした部分)を変更できる。

ユースケース1

ユースケース2

同じく、例としては何度も追加した対して中身のないコミットログを全てgitにあげるのは無駄なので、いらないものをスカッシュする。

11. 設定

エイリアス$ git lolは以下のようにして設定する。

$ git config --global alias.lol "log --graph --decorate --pretty=oneline --all --abbrev-commit"

はじめに

Perl って、ちょっと古いかもしれませんが 枯れていて、手に馴染む感じがいいですよね。
もうちょっとだけ AtCoder でユーザが増えてもいいと思うのですが。

実は簡単 Perl インストール

実は簡単、というかすでにインストールされている場合もあるんですよね。

Git for Windows をインストールされている場合、同時に Perl もインストールされますので、Git Bash から Perl を呼び出すことができます。
perl -v とコマンド実行して画像の様にバージョン情報が表示された場合、すでに入園済みです。

インストールされていない場合、Qiitaの諸先輩の投稿 Git インストール for Windows を参考にインストールすることができます。

エディタとして Vim が入っていますので、即プログラミング可能です。

他のインストール方法

こちらが詳しいです。
+ Strawberry PerlをWindowsにインストールする
+ ActivePerlをWindowsにインストールする
+ msys2をWindowsにインストールしてPerlを使う

VSCodeのインストール

Vim も素敵ですが、VSCode も素敵ですよね。
Qiitaの諸先輩の投稿 Visual Studio Code (Windows版) のインストール を参考にインストールすることができます。

VSCodeの設定

VSCode から Git Bash への連携をしやすくするための設定はこちらになります。
WindowsのVSCodeでGit Bashをターミナルに設定する

AtCoder の問題を実行するためのお薦め設定はこちらになります。
PerlのAtCoder向けVSCode設定(tasks.json)

まとめ

• Git いいよね
• VSCode いいよね
• Perl いいよね
• 今回はパクリ紹介ばかり

参照したサイト

• Git インストール for Windows
• Strawberry PerlをWindowsにインストールする
• ActivePerlをWindowsにインストールする
• msys2をWindowsにインストールしてPerlを使う
• Visual Studio Code (Windows版) のインストール
• WindowsのVSCodeでGit Bashをターミナルに設定する
• PerlのAtCoder向けVSCode設定(tasks.json)

Githubでプロジェクト管理をしていていつものようにマージを行おうとした時…。
マージ先を本来マージしたかったブランチと別のブランチにマージを行なってしまった…。
今回はその戒めとしてその時行なった手順をまとめていこうと思います…。
行なった手順は全てWeb上で行いました。

事の経緯

developからAブランチを伸ばし、さらにBブランチを伸ばした。
A,B共にPRを作成。
Aブランチはdevelopに、BブランチはAブランチをそれぞれマージ先に指定していた。
Aブランチを先にマージし、Bブランチのマージ作業を行う時、マージ先をAブランチにしたまま作業してしまった…。

解決まで…

BブランチのマージをRevert

とりあえずBブランチのマージをRevertしてみた。
マージした場所にある「Revert」を押下し、マージした。
するとPR作成の催促表示がA,B共に出た…。
先にマージしたはずのAブランチまで表示が…。

Bブランチで再度PRを作成

developをマージ先にしてBブランチのPRを作成…。
するとコンフリクトを起こしており、AブランチのPR作成の催促表示は出たまま…。

BブランチPRのコンフリクトを解決

「Resolve conflicts」を押下。
コンフリクトを全て解決したのち、「Commit merge」を押下…。
するとAブランチのPR作成の催促表示が消えた！

Bブランチを正しい先にマージ

マージ先をよくよく確認してマージを行なった。
無事に元の予定通りA,B共にdevelopへのマージを終えることができた…。

まとめ

マージ先をミスると手間がかかる。
１番はマージ先を間違えないこと、もし間違えてしまっても落ち着いて、冷静に対処を行うことはとても大事。
ミスをしてしまったときこそ落ち着いた対処が必要ですね…。

参考
GitHubで誤って違うブランチにマージしてしまった時にWeb上だけで戻す方法
GitHub でのマージ コンフリクトを解決する

今や旬のリモートワークにより、会社のデスクトップと家にあるノートPCでの作業が始まった。

先日、家のPCにてブランチを立ち上げ作業し、数日後に会社でそのブランチが見えずにドキドキしたときの対応について記録しておきます。

新ブランチがない。やばい

別のPCからブランチを確認するときは下記のコマンドをつかってまずは確認する
git remote -a

practice-Netlify-react$ git branch -a
* master
  remotes/origin/master

ありません。家で頑張って作ったはずのブランチがありません！！！なんたること

新ブランチを見つけてやる

色々調べると。リモートの情報がローカルのgitに反映されてないなからおこるとのことです。なのでここでリモートの情報を取得します

fetch --all

そして再度 remote -aを行うと

practice-Netlify-react$ git branch -a    
* master
  new-branch
  switch
  remotes/origin/master

ありました

ありました！！やったね！！ありました. new-branch ありました。
ブランチを移動

git switch new-branch

確認してみます

practice-Netlify-react$ git branch -a
  master
* new-branch
  switch
  remotes/origin/master

めでたしめでたし。
ところで最近は git switchがいいみたいですね。ついでに勉強になりました。

参考資料

感謝感謝です。

リモートブランチの更新が見えない時
Git 2.23.0でswitchとrestoreコマンドが追加!git checkoutから乗り換え

ウェブに限らず、今の時代はどの開発現場でもバージョン管理や共同開発のためにGitが導入されています。
Gitは、触ったことない人にとっては非常に未知のもので、慣れるまでに少し時間がかかります。

以前

Gitの知識ゼロで現場に放り込まれた時は最低これだけおさえておけ！

という記事を上げさせていただきました。
確かにこの記事にある知識だけで、開発の仕事は最低限のレベルで完結しますが、実を言うとそれだけでは不十分です。

ここでは、次のステップ…よりも半歩前、前回の記事が第一段階ならば、1.5段階目に知っておくべきことを、私が1年間でやった失敗から学び取っていただけたらと思います。

何も考えずに「git add .」をやってソースをデグレさせた

「git add .」を打ち込むと、ディレクトリ内のファイル全てをステージングエリアに上げることになります。
そうしますと、共同開発を行っているコンテンツでしたら、自分が最後にリモートリポジトリからプルした後に誰かがプッシュした場合、デグレしたものをプッシュすることになります。
自分一人で開発を進めるコンテンツならそれでもいいのですが複数人がいじっているコンテンツの場合、絶対にどこかでこのトラブルは発生させてしまいます（私の場合、最初は一人で進めていくシンプルなコンテンツだったため、この問題を起こしたのは配属半年以上たってからでした）。

・git addは基本的に編集したファイルを選択「git add something.js」のように。
・git diffというコマンドを使って、編集した覚えのない場所に差分がないかチェック

しておけば事故を防ぐことが出来ます。

大量にデータファイルや画像をコミットした

「.gitignore」で管理対象外にするファイルを記録するのは基本ですが、最初は何を管理対象外にするのかという判断がつかなかったため、膨大なファイルをコミットし続けてしまっていました。
そのおかげでリポジトリがサーバの容量を圧迫するまでに至りました。
「何を対象外にすればいいのか聞けよ」と言われたらそれまでですが、Gitにかぎらず、右も左も分からなかった中色々先輩方に尋ねていたのでそこまで及ばなかったということです。

・画像やデータなどはコミットしなくてもいい
・他人の「.gitignore」を見れば大体乗せているものは共通しているはず

また、思い出したら編集します。

問題点

Github上の自分のプライベートリポジトリからgit cloneする際に、

$ git clone https://github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Repository not found.
fatal: repository 'https://github.com/user_name/repos_name.git/' not found

あるいは

$ git clone https://user_name@github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Repository not found.
fatal: repository 'https://github.com/user_name/repos_name.git/' not found

のようにパスワード入力を求められずに失敗する。

環境

OS:Windows 10
Git Bash: ver 2.25.1

解決策 1

git clone https://user_name:password@github.com/user_name/repos_name.git

の様な形でGithubのユーザー名とパスワードをURLに含める。
しかし、これだとパスワードが********のように伏字にならず、丸見えになってしまう。

解決策 2

先ほどの:passwordを消して

git clone https://user_name@github.com/user_name/repos_name.git

とすることで、パスワード入力を求められる、、、らしいが、私の環境ではこれも同様の出力で失敗した。

解決策 3

試しにpasswordを未入力にして

git clone https://user_name:@github.com/user_name/repos_name.git

とした。すると、

$ git clone https://user_name:@github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/user_name/repos_name.git/'

と出て認証失敗。
しかし、続けて

git clone https://user_name@github.com/user_name/repos_name.git

を叩くと、今度は無事パスワードを要求された。
その後のcloneはuser_nameもpasswordも要らず、

git clone https://github.com/user_name/repos_name.git

でダウンロードが始まった。
gitわからん_(:3」[＿]

追記

コメントより、Windows資格情報マネージャー
コントロール パネル>ユーザーアカウント>資格情報マネージャー
から資格情報 git:https://github.com の編集、削除によってこの問題に対応できることを教えていただきました。

また、

$ git clone https://user_name:@github.com/user_name/repos_name.git

によって資格情報の削除が起こっていたことを確認済みです。
　削除後にGithubアカウントにログインすると新たに資格情報が登録されます。ユーザー名やパスワードの変更を行わない限り、今後はその情報を使って自動的に認証が行われるため、git clone 時のユーザー名やパスワードの入力は不要になります。

問題点

Github上の自分のプライベートリポジトリからgit cloneする際に、

$ git clone https://github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Repository not found.
fatal: repository 'https://github.com/user_name/repos_name.git/' not found

あるいは

$ git clone https://user_name@github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Repository not found.
fatal: repository 'https://github.com/user_name/repos_name.git/' not found

のようにパスワード入力を求められずに失敗する。

環境

OS:Windows 10
Git Bash: ver 2.25.1

解決策 1

git clone https://user_name:password@github.com/user_name/repos_name.git

の様な形でGithubのユーザー名とパスワードをURLに含める。
しかし、これだとパスワードが********のように伏字にならず、丸見えになってしまう。

解決策 2

先ほどの:passwordを消して

git clone https://user_name@github.com/user_name/repos_name.git

とすることで、パスワード入力を求められる、、、らしいが、私の環境ではこれも同様の出力で失敗した。

解決策 3

試しにpasswordを未入力にして

git clone https://user_name:@github.com/user_name/repos_name.git

とした。すると、

$ git clone https://user_name:@github.com/user_name/repos_name.git
Cloning into 'repos_name'...
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/user_name/repos_name.git/'

と出て認証失敗。
しかし、続けて

git clone https://user_name@github.com/user_name/repos_name.git

を叩くと、今度は無事パスワードを要求された。
その後のcloneはuser_nameもpasswordも要らず、

git clone https://github.com/user_name/repos_name.git

でダウンロードが始まった。
gitわからん_(:3」[＿]

追記

コメントより、Windows資格情報マネージャー
コントロール パネル>ユーザーアカウント>資格情報マネージャー
から資格情報 git:https://github.com の編集、削除によってこの問題に対応できることを教えていただきました。

また、

$ git clone https://user_name:@github.com/user_name/repos_name.git

によって資格情報の削除が起こっていたことを確認済みです。
　削除後にGithubアカウントにログインすると新たに資格情報が登録されます。ユーザー名やパスワードの変更を行わない限り、今後はその情報を使って自動的に認証が行われるため、git clone 時のユーザー名やパスワードの入力は不要になります。

目次

• はじめに
• この記事は
• Slackチャンネルへの参加
• 環境構築
  • GitHubリポジトリをFork
  • ローカルにCloneしてくる
  • yarnによる環境構築
    • yarnのインストール
    • 必要なパッケージのインストール
    • サーバー起動
• GitHubのissueを見てみる
  • 開けてみる
  • ラベルを見てみる
• 気になったissueを改善してみる
• 自分で改善したものをプルリクエストする
  • ForkしたリポジトリにPush
  • プルリクエストを送る
    • テンプレートに沿った文章を書く
  • マージされるの待つ
• その他の注意事項
• さいごに

はじめに

この記事を見ている人は少なからず東京都の新型コロナウイルス対策サイトへの貢献に興味を持っているのではないでしょうか。

「ガチガチのプロしか参加しちゃいけないんでしょ？」
「OSSにプルリクなんて敷居高そう...」

そんなことありません！現に私は高校２年生ですが、対策サイトのGitHubのissueには私でもできそうな課題がいっぱいあります。数多くある課題から自分にできそうなものを選び、改善し、更新の依頼（プルリクエスト）を送るだけです。簡単でしょう？

この記事は

この記事はOSSプロジェクトに１回も貢献したことがない、初心者向けの内容になっています。ベテランの人は直接GitHubのリポジトリを見て頂いた方が速いと思います。

Slackチャンネルへの参加

対策サイトのコントリビューター（貢献者）たちが集まったコミュニケーション用のSlackチャンネルがあります。
分からないことの質問や新たな提案を気軽にすることができるので、参加した方が良いと思います。

参加リンクはこちらから↓
https://cfjslackin.herokuapp.com/
チャンネル名は #covid19

環境構築

対策サイトのプログラムを修正して、内容を確認したい時にいちいちどこかしらのサーバに上げていたら面倒くさいですよね。そこで、自分のパソコン内だけでの対策サイトの動かし方を解説します。

Gitのインストール、GitHubのアカウント登録は済んでいる前提で進めます。まだの方は以下の記事を参考にしてください。
自分用 Git For Windowsのインストール手順
【2019年1月現在】GitHubアカウント作成方法
Macの場合最初からGitがインストールされています。

また、ローカルでの構築だけでなく、自分の開発用サーバを本番と同じような環境（Netlify）にデプロイしたいというベテランの方がいれば、以下の記事が参考になると思います。

東京都新型コロナウイルス感染症対策サイトをforkしてnetlifyでdev環境を立ち上げる手順

GitHubリポジトリをFork

東京都 新型コロナウイルス対策サイトのGitHubページを開けてください。
https://github.com/tokyo-metropolitan-gov/covid19
こんな画面↓↓が現れると思います。

青色の線で囲ったForkボタンをクリックしてください。

しばらくすると、自分のアカウント上でForkしてきたリポジトリが作られていると思います。

ローカルにCloneしてくる

Forkしてきたリポジトリの画面に、（下の画像では）青色の線で囲ったClone or downloadというボタンが作られていると思います。

押すと何やらURLなどが書かれた小さい画面が出てくると思うので、（下の画像では）青色の線で囲んだところのボタンをクリックして、書かれているURLをコピーしてください。

次はパソコンのターミナル（Windowsならコマンドプロンプトという名前）を開いてください。そして、Cloneしてきたいディレクトリまでcdコマンドで移動し、以下のコマンドを打ってください。

$ git clone コピーしたGitHubのリポジトリのURL

そしたら自分のパソコンの中にGitHubにあるフォルダやファイルがすべてコピーされたたと思います。

yarnによる環境構築

新型コロナウイルス対策サイトほどの規模になってくると、たくさんのパッケージを使用します。パッケージとは、ある機能を作るのが簡単にできるようにするために作られたプログラムの集まりみたいなものと思えばよいと思います。

そこで、多くのパッケージを管理してくれるパッケージマネージャがとても活躍します。
東京都新型コロナウイルス対策サイトでは、yarnというパッケージマネージャが使われています。
以下では、yarnを使った環境構築を解説します。
（実はDockerというものを使った方法もありますが、今回は導入がDockerよりも楽なyarnだけ解説します）

yarnのインストール

yarnの公式サイトを開き、yarnのインストールをしてください。
https://classic.yarnpkg.com/ja/docs/install/#windows-stable
Windowsの方はインストーラーを入れるだけ、MacOSの方はHomebrewを使えばすぐ終わると思います。

必要なパッケージのインストール

またターミナルを開きます。
先ほどGitHubからクローンしてきたものがあるディレクトリまで移動して、以下のコマンドを打ってください。

$ yarn install

そこそこ時間かかると思います。完了すると必要なパッケージがすべてインストールされます。

サーバー起動

ついにサーバーを起動させます。ターミナルで以下のコマンドを打ってください。

$ yarn dev

初回はビルドという作業をするのでかなり時間がかかると思います。ビルドが終わったら、以下のリンクにアクセスしてみてください。

http://localhost:3000

やったー！対策サイトそのまんまが表示されましたね。

ここまでくれば環境構築はほぼ全て終了です。お疲れさまでした。

GitHubのissueを見てみる

いよいよ対策サイトに貢献する時です。

GitHubにはissueというものがあります。issueは日本語訳で課題です。

対策サイトの「こんな機能がほしい！」「こんなバグがあるから治してくれ！」という課題たちがissueに全て登録されています。

対策サイトのissueを見てみましょう。以下のリンクを開いてください。
https://github.com/tokyo-metropolitan-gov/covid19/issues

こんな感じになってると思います。
ここに対策サイトの課題が登録されています。

開けてみる

適当なissueを開けてみてください。以下のような画面が出ると思います。

この画面では、そのissueの概要を見たり、そのissueに対して質問できたりします。
issueに対しての質問や提案は自由に行えます。気になったことがあれば気軽に聞いてみましょう。

ラベルを見てみる

issueのタイトルを見てみてください。なにやら様々な色でgood first issueやらhelp wantedやらと書いてあります。これはラベルと言われ、そのissueの種類みたいなものです。

以下に対策サイトのissueにおけるいくつかのラベルを紹介します。
good first issue: 初心者にお勧めのissueです。
help wanted: 特別な注意が必要。
bug: 名前の通り、バグです。
improve: 改善提案
good first issueとhelp wantedとbugは優先度が高く、なるべくこれらのラベルがついたissueに対応すると尚良いです。improveは改善提案なので、必ず反映されるかどうかは分かりません。

気になったissueを改善してみる

先ほどのissue一覧から自分ができそうなのを選びましょう。

ここで重要なのが、やりたいissueが見つかったらコメントで「このissue私がやりたいです！」と意思表明をしましょう。
意思表明をしないと誰もまだこのissueをやってないと認識され、自分が作業している間に他の人がパパッとやってしまうかもしれません。

意思表明をしたら、さっそく実装です。
自分の得意分野を活かして、より良い物を作りましょう。

自分で改善したものをプルリクエストする

ついに、自分で改善したものを実際の対策サイトに「こういう変更をしたので更新してくだい」という依頼（プルリクエスト）を送ります。

ForkしたリポジトリにPush

自分のアカウントでForkしてきたリポジトリのURLをコピーしてきてください。環境構築編の、ForkしたリポジトリをCloneしてくる項目で１度やっているはずです。

そしたら、ターミナルを開いてプロジェクトのディレクトリまで移動し、以下のコマンドを打ちましょう。

$ git add .
$ git commit -m "ここは、自分がどのような変更したかを分かりやすく書いてください。"
$ git push コピーしてきたURL development

自分で変更したところが更新されたはずです。

プルリクエストを送る

Forkしてきた方ではなく、公式の対策サイトのGitHubページを開けてください。
そして、Pull Requestsというボタンをクリックしてください。以下の画像では青色の線で囲ってあるところです。

そしたら現在送られているすべてのプルリクエストが表示されたページが開きます。このページのやや右上にあるNew Pull Requestというボタンをクリックしてください。

以下の画像のようなページが開くので、青色の線で囲ったcompare across forksというところをクリックしてください。

これで自分のForkしてきたリポジトリを指定できるようになりました。
青色の線で囲ったところをクリックすると、いろいろなリポジトリのリストが表示されます。
ここで、自分のGitHubのユーザー名/covid19を選択してください。
下の画像で言うと赤色の線で囲った部分です。

そしたら緑色のCreate pull qequestというボタンをクリックしてください。
どのような変更をしたのか書くページが開くと思います。

テンプレートに沿った文章を書く

このプルリクエストは一体どのような変更を加えるのか、という文章を書きますが、対策サイトのGitHubではこれの書き方のテンプレートが用意されています。それは以下のようになっていると思います。

## ? 関連issue / Related Issues
<!--
  ・ 関連するissue 番号を記載してください。 Issue 番号がない PR は受け付けません。
  ・ issueを閉じるとは関係ないものは#{ISSUE_NUMBER}だけでOKです?‍♂️

  ・ You can remove this section if there are no related issues
  ・ If the issue is related but doesn't close upon merge, you can just write - #{ISSUE_NUMBER} ?‍♂️
-->
<!--
  ・ Please specify related Issue ID. We don't accept PRs which has no issue ID.
  ・ If there's no reason to close the issue, just "#{ISSUE_NUMBER}" is OK?‍♂️
-->
- close {ISSUE NUMBER} 

## ⛏ 変更内容 / Details of Changes
<!-- 変更を端的に箇条書きで -->
<!-- List down your changes concisely -->

## ? スクリーンショット / Screenshots
<!-- スタイルなどの変更の場合はスクリーンショットがあるとレビューしやすいです -->
<!-- Changes in styles would be easier to review with screenshots! -->

関連issue: 全てのプルリクエストにおいて、必ずここで元のissueの番号を書く必要があります。
変更内容: どのような変更をしたか箇条書きで書いてください。
スクリーンショット: UIのスクショを貼ります。

issue番号については、改善したissueページのタイトルの右に#から始まる数字が書いてあると思います。これを#含め書いてください。

既に多くのプルリクエストがあります。他のプルリクエストの書き方を参考にして、より分かりやすく書きましょう。

書けたら緑色のCreate pull requestボタンをクリックしてください。これでプルリクエストは終わりです。お疲れさまでした。

マージされるの待つ

誰かが自分のプルリクエストの内容をコードレビュー（プログラムに何らかの問題がないかレビューすること）をして、マージ（変更内容を取り込むこと）されるのを待ちます。

もし無事マージされれば、これであなたも東京都 新型コロナウイルス対策サイトのコントリビューターの１人となります。

その他の注意事項

この記事では書ききれなかったけど、対策サイトへの貢献に際して非常に重要なことが公式のドキュメントに書いてあります。
必ず目を通しておいてください。

貢献の仕方
行動規範
Code for Japanの行動規範
Issue 番号の無いPRは禁止としました。

さいごに

最後までお読み頂きありがとうございました。
新型コロナウイルスの脅威が高まっている中、みんなで力を合わせて危機を乗り越えましょう。

ところで、これは言い訳ですが、筆者はこの記事を徹夜明けに書いています。つまりなにが言いたいかというと、どこかしらで支離滅裂なことを書いてそうなので、変なところがあればコメントで指摘して頂ければ幸いです。

理解したコードを再利用したい

私は現在、Ruby on Railsの学習をしています。

学習する順序として
1.CRUD機能を実装
2.ログイン機能を実装
3.1対多のアソシエーションの実装
4.多対多のアソシエーションの実装
5.ActionMailerの実装
6.画像アップロードの実装
7.Ajaxを使用したコメント機能の実装
8.フォローフォロワー機能の実装

上記の実装を復習も兼ねて0から実装して理解を定着させております。
しかし、機能が増えていくと

・0から作り出すと圧倒的に時間がかかる。
・復習したいところだけもう一度手を動かしたいなって思った時に気軽に手を動かせない。

ということがあるためどうにか復習用の新規リポジトリに理解したコードのみ存在する状態で
開発ができないかなと考えました。
※scaffoldでいいじゃんっていうのもありますがせっかくなら自分の書いたコードを使いたいので。。。

1度開発したリポジトリをCloneする

git clone [元のリポジトリURL]
cd [cloneしたリポジトリ]

新規リポジトリを作成し、remote-urlを変更する

Githubにてリポジトリを新規作成する。
その後、cloneした元のリポジトリのremote-urlを新規のリポジトリのurlに変更する。

git remote set-url origin [新規作成時のリポジトリURL]

gitのログを確認し、不必要なcommitメッセージを削除する。

# コミットidを確認する。
git log --oneline

# 戻りたいコミットメッセージのコミットidを指定する。
git reset --hard コミットid

これで復習したい機能だけ削除して手を動かすことができました。
もっといい方法、不都合なことがありましたら修正していきたいと思います。

参考

gitのremote urlを変更する(レポジトリ移行時)
[git] 戻したい時よく使っているコマンドまとめ

理解したコードを再利用したい

私は現在、Ruby on Railsの学習をしています。

学習する順序として
1.CRUD機能を実装
2.ログイン機能を実装
3.1対多のアソシエーションの実装
4.多対多のアソシエーションの実装
5.ActionMailerの実装
6.画像アップロードの実装
7.Ajaxを使用したコメント機能の実装
8.フォローフォロワー機能の実装

上記の実装を復習も兼ねて0から実装して理解を定着させております。
しかし、機能が増えていくと

・0から作り出すと圧倒的に時間がかかる。
・復習したいところだけもう一度手を動かしたいなって思った時に気軽に手を動かせない。

ということがあるためどうにか復習用の新規リポジトリに理解したコードのみ存在する状態で
開発ができないかなと考えました。
※scaffoldでいいじゃんっていうのもありますがせっかくなら自分の書いたコードを使いたいので。。。

1度開発したリポジトリをCloneする

git clone [元のリポジトリURL]
cd [cloneしたリポジトリ]

新規リポジトリを作成し、remote-urlを変更する

Githubにてリポジトリを新規作成する。
その後、cloneした元のリポジトリのremote-urlを新規のリポジトリのurlに変更する。

git remote set-url origin [新規作成時のリポジトリURL]

gitのログを確認し、不必要なcommitメッセージを削除する。

# コミットidを確認する。
git log --oneline

## 戻りたいコミットメッセージのコミットidを指定する。
git reset --hard コミットid

これで復習したい機能だけ削除して手を動かすことができました。
もっといい方法、不都合なことがありましたら修正していきたいと思います。

元のローカルリポジトリを削除し、新しく作成したリポジトリをCloneする

# 一つ上の階層に戻る
cd..
# ディレクトリを削除
rm -fr 元のリポジトリ

# 新しく作成したリポジトリURLを使用してclone
git clone [新しく作成したリポジトリURL]

参考

gitのremote urlを変更する(レポジトリ移行時)
[git] 戻したい時よく使っているコマンドまとめ

This way is recommended for private development.
If you are in team, use more appropriate way.

Have you experienced that your commit is not related to your account on GitHub haven't u?
Yes it's me.

So, I've wrote down here how to solve it.

1. Use filter-branch command

You'd like to change all history(all branches)

$ git filter-branch -f --env-filter "GIT_AUTHOR_NAME='new.name';GIT_COMMITTER_NAME='new.name';GIT_AUTHOR_EMAIL='new.email@mail.com';GIT_COMMITTER_EMAIL='new.email@mail.com'" -- --all

2. Use the force

You need push after modified.

git push -f

Refs

https://git-scm.com/docs/git-filter-branch

GitFlow

https://qiita.com/KosukeSone/items/514dd24828b485c69a05

---

GitFlow機能

GitFlow運用を少し便利にする機能。
SourceTree以外にも
- fork
- gitkraken

などにも標準搭載。

---

GitFlow機能で何が嬉しいのか

• GitFlow初心者の補助
• future(featureのタイポ)を防げる
• マージミスを防げる
• マージしたブランチの削除し忘れを防げる
• バージョンtagの付け忘れを防げる

かもしれない

---

初期設定

Shift + Alt + Fを同時押しします。
リポジトリを初期化 をクリック
リポジトリの初期値の設定画面が開きますが、そのままOKをクリックします。

初期化とありますが、gitflowの初期設定をしているだけですのでご安心ください。
リポジトリに影響はしません。

---

featureブランチの作成

Shift + Alt + Fを同時押しします。
次のFlow操作ウインドウが表示されます。
新規フィーチャーを開始をクリックします。

---

feature名を入力してOKをクリックします。
(feature/は書かなくてよい！）

---

featureブランチのマージ

Shift + Alt + Fを同時押しします。
フィーチャーブランチを完了をクリックします。

フィーチャー名を選びOKをクリックします。

---

release作成, masterマージとバージョンタグ付け

---

releaseを作成

Shift + Alt + Fを同時押しします。
新規リリースを開始をクリックします。

---

releaseブランチ名 ≒ version名の入力

---

プロジェクトのバージョン設定を変更

プロジェクトのバージョンファイルを書き換えてコミットします。

---

リリースの完了と バージョンタグ付け

Shift + Alt + Fを同時押し
リリースを完了をクリックする

---

OKをクリックします。

---

masterにマージ完了

次が完了します。
- releaseをmasterにマージ
- developにもマージ
- バージョンタグ付け
- 不要なブランチ削除

---

独自ブランチを作るには?

gitflowにないものは作れません
- 「bugfix/hoge」ブランチは作れませんので「feature/bugfix_hoge」で代用してください。
- featureにfeatureを生やすなどもできないので、一度featureを完了してからfeatureを作成してください。