Git – ブランチ – 基本操作 – fast-forward

概要

  • ブランチをつくってコミットした内容は、他のブランチに影響しない
  • ブランチ作成後に新たなコミットがない状態で他のブランチの作業結果をマージすると、その結果が取り込まれて作業後にHEADが移動する
  • このようなマージをfast-forwardという(単に他のブランチの作業後まで早送りしているイメージ)

準備

確認用にbranchリポジトリーを作ってclone。

ワーキングディレクトリーに移動してログを確認。

mainブランチでイニシャルコミットが実行された状態。これを図にすると以下のような状態。

新たなブランチの作成

以下のコマンドで、新たなブランチtopicを作成する。

git branch ブランチ名

また以下のコマンドでブランチの状態を表示させて、作成結果を確認。

git brranch

新たにtopicブランチが作成されているが、現在はmainブランチにいることが確認できる(main*が付いている)。

ブランチ作成直後のログは以下の通り。

内容は変わっていないが、HEADmainなどに加えて新たにtopicも指している。

ブランチの移動

作成したtopicブランチに移動する。指定したブランチに移動するには以下のコマンドを使う。

git checkout ブランチ名

get branchtopicブランチに移動したことがわかる。

topicブランチでログを見ると、mainの内容が引き継がれていることがわかる。

ブランチ内での変更と独立性

ブランチ内での変更

現在いるtopicブランチで、topic.txtファイルを新規作成してコミットする。

ログを確認。

作成したファイルに、さらに変更を加えてコミット。

ログを確認すると、2つのコミットが反映されている。

topic.txtの内容も2つのコミットの内容が反映されている。

ブランチの変更の独立性

ここでmainブランチに戻ってみると、まだtopicブランチで作成・更新したtopic.txtは反映されていない。

mainブランチのログも初期状態のまま。

ここまでの状態は以下のようになる。mainブランチの状態は変わらず、topicブランチでコミットされてHEADが移っている。

mainブランチでのマージ

以下のコマンドは、現在いるブランチに指定したブランチの作業内容をマージする。

git merge ブランチ名

mainブランチにいる状態で、topicブランチでのコミットをmainブランチにマージする。

1つのファイルが更新され(新規作成を含む)、挿入が2件あることが示されている。

mainブランチでtopic.txtを見てみると、topicブランチでの新規作成・更新の作業が反映されている。

ログは以下の通り。なお、この内容はtopicブランチで確認しても全く同じになっている。

  • topicブランチでの作業がそのままmainブランチに適用されている
  • HEADmaintopicの両方のブランチの最後尾を指している

ここまでの状態は以下のようになる。mainブランチにtopicブランチのコミットが吸収されて、HEADの位置が最後尾に移っている。

fast-forward

上記のマージでは、topicブランチでの作業結果がそのままmainブランチに取り込まれ、HEADがその最後尾に進んでいる。

このようなマージをfast-forward (早送り)と呼ぶ。

マージの取り消し

ここで、mainでマージしたtopicの内容を取り消すことを考える。

取り消しできないコマンド例

git merge --abortは競合が発生したときのみ機能するが、今回は競合が発生していないので取り消しできない。

get reset --hard HEADは、マージが競合なく進んでHEADがマージ後の最新の位置に移動しているのでマージを取り消しできない。

コミット番号を指定したマージの取り消し

git reset --hard コミット番号で1つ前のtopic-1のコミット番号を指定すると、そのtopic-1の適用直後まで戻すことができる。作業結果も巻き戻されている。

ログの確認。HEADが1つ前のtopic-1の終了時点となっている。

ここでtopicブランチに移ってログを確認すると、その内容は変わっておらず2つのコミット結果が残っている。

ここでの状態は以下のようになる。マージされた1つのコミットが2つに分かれている。

さらにmainブランチで、イニシャルコミットの直後までリセットする。ファイルの作成前まで巻き戻されている。

ログもマージ前に戻る。

ここでもtopicブランチでのコミット結果は変化しておらず、状態は以下のようになる。

再マージ

topicブランチのマージを再度実行。この場合はtopicブランチでの2回のコミット結果が一挙に反映される。

mainブランチのログにも2度のコミットの記録が残る。

以下の状態に戻る。

ブランチの削除

ブランチでの作業履歴が不要になった場合は、以下のコマンドでブランチを削除できる。

git branch --delete ブランチ名
git branch -d ブランチ名

 

Git – マージ・競合

リモートリポジトリーに対する変更の競合とマージ

リモートリポジトリーの作成とクローン

リモート(GitHub)にリポジトリーを作成し、README.mdの内容を編集。

README.md : Test for conflict and merge

ローカルのuser1、user2ディレクトリーにリモートの内容をクローン(2人のユーザーが並行して作業するイメージ)。

競合がないファイル追加

ユーザーによるファイルの追加

user1によるファイル追加・コミット・プッシュ

この結果、GitHub上でsample1.txtの追加が確認できる。

別ユーザーによる別ファイルの追加

user1によりファイルが追加された後、user2によりファイルを追加・コミットし、プッシュしようとするとエラーになる。

リモートで他の作業が行われためと通知され、プルすることが提案されている。

ローカルでのマージ

user2でリモートからプルすると、エディター画面が開いて以下の様に表示される。

エディターを抜けてコマンドラインに戻り、プルの実行過程を確認。

ワーキングディレクトリーを確認すると、user1が追加したsample1.txtが追加されている。

マージ後のステータス

マージ後のステータスは、2つのコミット(sample2.txtの作成とマージ)がされていて、プッシュが提案されている。

ログで確認した結果。

コミットのプッシュ

2つのコミットをプッシュ。この結果、GitHub上でもsample1.txtsample2.txtが反映される。

同一ファイルへの変更の競合

ユーザーによるファイル編集

ワーキングディレクトリーuser1でプル。

user1としてREADME.mdの内容を編集。

編集結果をステージング、コミット、プッシュ。

この結果、GitHub上でREADME.mdの内容が変更されているのを確認。

別ユーザーによる同じファイルの編集

user1によりREADME.mdが編集された後、user2により同じファイル編集し、コミット、プッシュしようとすると、ファイル追加の時と同じようにエラーになる。

ローカルでのマージに競合

user2で編集した内容はそのままでリモートリポジトリーからプル。README.mdをマージしようとして、競合が発生したため、競合を解消してコミットするよう示唆している。

README.mdの内容を確認すると、user2の変更内容の反映を試み、その下に競合内容も追加されている。

手動で競合を修正してプッシュ

ファイルを修正し、コミット・プッシュ

README.mdをマージした結果はGitHub上で確認できる。

 

GitHub – SSH接続

概要

GitHubにローカル(Vagrant/CentOS7)からSSH接続を設定するのに、けっこう躓いてしまったので整理。GitHubに公開鍵をセットするのは当然として、ローカル側でいろいろ設定しないといけない。

流れは最後の「まとめ」に整理したが、概ね以下のような留意点あり。

  • ssh-addで秘密鍵を登録する必要がある
  • ssh-addに先立ってssh-agentを実行する必要がある
    • eval `ssh-agent’で実行する必要がある
  • SSHで扱うリポジトリーは、SSHでcloneする必要がある
    • SSH接続用のURLの書き方がある

鍵の生成

ssh-keygenで秘密鍵・公開鍵を生成する。

GitHubへの公開鍵の登録

  1. ヘッダーメニューのドロップダウンからSettingsを選択
  2. 左メニューからSSH and GPG keysをクリック
  3. SSH keysの”New SSH key”ボタンをクリック
  4. 公開鍵を貼り付け

SSH接続までのトライ・アンド・エラー

ターミナルでのアクセス~エラー

ssh -T コマンドでアクセスしようとしたところエラーになった。

ssh-addしてもエラー

参考サイトGitHubに接続できないときの対処法より、ssh-addするがエラー

ssh-agentが必要

参考サイトssh-addできなかったときへの対処よりssh-agentを実行するがうまくいかない。

直接実行しても内容が表示されているだけらしいので、同サイトにあるとおり、eval `ssh-agent'を実行してキーが追加された。

ターミナルでアクセス

ssh -Tを改めて実行し、(GitHubはシェルでのアクセスができないが)正しく認証されたことを確認。

既存リポジトリーのcloneができない

ここでGitHub上に既に存在するリポジトリーをcloneしようとしたが、パーミッションで拒否される。

クローン段階からSSHでもエラー

先の参考サイトGitHubに接続できないときの対処法の後ろの方を読むと、httpsでcloneしたリポジトリーはsshでは扱えないらしい。

そこでhttps認証に倣って以下のコマンドを打ってみるがうまくいかない。

SSH接続用のURLで接続成功

参考サイトベビーサンになりたいに倣ってURLを書いてみると、やっと接続できた。

別のマシンへの鍵の複製

これまでの流れで導入した鍵を別のマシンへ複製し、GitHubへ接続。

~/.ssh/下にあるid_rsaid_rsa.pubの2つのキーファイルをもう1つのマシンの~/.ssh/下にコピー。この状態でssh -Tで認証が確認できた。

ただし、cloneやpull/pushなどのコマンドを実行するたびにパスフレーズの入力を求められる。

そこで、ssh-agentssh-addを実行する。

これで毎回パスフレーズを入力する必要がなくなった。

まとめ

ひとまず、以下の流れでSSH接続を整理。

  1. ローカルに秘密鍵と公開鍵を生成
  2. GitHubに公開鍵を設定
  3. eval `ssh-agent`を実行
  4. ssh-add ~/.ssh/id_rsaで秘密鍵登録
  5. ssh -T git@github.comで認証成功を確認
  6. 既存リポジトリーをSSHでclone
    • git clone git@github.com:ユーザー名/リポジトリー名.git
  7. 以後、ワーキングディレクトリー内でSSHでpull/push

鍵のペアーを他のマシンに複製して同じアカウントにアクセスする場合、

  1. id_rsaid_rsa.pubを他のマシンの~/.ssh/ディレクトリーにコピー
  2. eval `ssh-agent`を実行
  3. ssh-add ~/.ssh/id_rsaで秘密鍵登録

 

Linux – ssh-keygen – 鍵の生成

キーペアの生成

ssh-keygen -t rsa -b ビット数 -C "コメント"

生成されたキーは、デフォルトでは以下のファイルに記録されている。パーミッションは秘密鍵が600、公開鍵が644。

  • 秘密鍵:~/.ssh/id_rsa
  • 公開鍵:~/.ssh/id_rsa.pub

秘密鍵の内容

公開鍵の内容

オプション

ssh-keygen --help

参考サイト:

 

Git/GitHub – 基本的な操作

概要

GitからGitHubにプッシュ・プルする手順。最初にリポジトリーを作成する場合、GitHub上にあらかじめリモートリポジトリーを作成しておいて、これをローカルにgit cloneで取り込む。

パスワード認証について

パスワード認証が2段階になり、Personal Access Token (PAT)を用いるようになったため、リモートでGitHubに接続する際のパスワード認証ではPATを入力することとなっている。

Gitのデフォルトブランチの変更

Gitのデフォルトブランチ名はmasterだが、GitHubがデフォルトブランチ名をmainとしたことから、Gitでもmasterからmainに変更するよう設定。

手順

  1. GitHubで共有するクローンを空の状態で作成
  2. GitでGitHubのリポジトリーをクローン
  3. Gitでローカルの開発過程をコミット
  4. GitからGitHubにコミット結果をプッシュ
  5. 以後、リモートリポジトリーからローカルにプル

GitHubで新しいリポジトリーを準備

GitHub上に新しいリポジトリーを作成。

  • リポジトリー名:test
  • Add a README fileを選択
  • 内容は1行で"My very first repository"

リモートリポジトリーのクローン

ローカルのワーキングディレクトリーにGitHubのリポジトリーをクローン。

GitHubで作成したREADMI.mdファイルの内容が確認できる。

ローカルでの変更とコミット

ワーキングディレクトリーに新たにsample.txtファイルを追加する。

そして追加したファイルをステージング、コミット。

Laravelなどのフレームワークの場合、.gitignoreで指定されたファイルも併せて環境ごとpushするには、ステージングで以下のオプションを指定する。

git add -f .

GitからGitHubへのpush

git pushでコミットされた内容をプッシュ。

git push -u [URL] [branch]

[URL]はGitHubのリポジトリーのURLで、[branch]はリモートリポジトリーのブランチ。GitHubからcloneで複製したディレクトリー内の場合、git pushのみで実行可能。

コマンドを入力するとユーザー名とパスワードを聞かれるので、GitHubのユーザー名とパスワードを入力する。

これでローカルでの変更結果がGitHubのリポジトリーに反映され、GitHub上で変更結果を確認できる。

GitHubからGitへのpull

他で変更された可能性のあるリポジトリーで作業を開始する場合、リモートリポジトリーからプルする。

以下はGitHub側でREADME.mdの内容を編集した後に、ローカルでプルしている例。

 

Git – ローカル操作 – v2.24

概要

Gitのv2.2は1.8とデフォルトの挙動などが違ってくるので、v2.2.4について改めて整理。

  • ワーキングディレクトリーの作成は、対象ディレクトリー直下でgit initを実行
  • ファイル・ディレクトリーの作成・変更・削除後のコミットの前に、git addでステージングが必要
  • 削除まで含めたステージングのコマンドは、git add --all .
    • v1.8と違って--allオプションは不要
  • ステージングエリアの状態をコミットするには、git commit -m "コメント"でコメントを付して実行

v2.24のインストール

Vagrant-bento/CentOS7の場合Gitがインストール済みだがバージョンが古い。

また、yumで普通にインストールする場合も、バージョンが1.8のものしか提供されていない。

そこで、最新バージョンのv2.24をインストールする。

Gitの初期設定

git configコマンドでユーザー名とメールアドレスを設定。この結果カレントディレクトリーに.gitconfigファイルが作成され、内容が記述される。

必要に応じてGit実行時のカラー設定。

Gitのデフォルトブランチ名はmasterだが、GitHubでリモートリポジトリーを作成する場合、デフォルトブランチの名前がmasterからmainに変更されている。必要に応じてデフォルトブランチの名前を変更しておく。

ワーキングディレクトリー

ワーキングディレクトリーの作成

~/git/testディレクトリーを作成し、そこに移動する。このディレクトリーをワーキングディレクトリーとする。

ワーキングディレクトリーの初期化

~/git/testディレクトリーでgit initを実行する。

この結果、リポジトリーのスケルトンとして.gitディレクトリーが作成される。

ステータス確認

ワーキングディレクトリー内でgit statusコマンドを実行してみる。

この段階でステージングエリアにファイルがあれば、それがコミット可能として表示される。しかし現時点ではワーキングディレクトリーの初期化直後なので、ステージングエリアにはコミット可能なファイルはない。ファイルを作成またはコピーして、git addするよう示唆されている。

また、ブランチはmasterとなっている。

v1.8と内容は同じだが、各行の頭に'#'がついておらず、一部表現が"Initial commit""No commits yet"に変更されたている。

ファイルの新規作成とコミット

初期化したリポジトリーに、新たにファイルを作成してコミットする。手順は以下のとおり。

  1. ワーキングディレクトリーにファイルを新規作成・コピーする
  2. ファイルをステージング(ステージングエリアに登録)
  3. ステージングエリアのファイルをコミット

ファイルの新規作成

“初めてのGit”という内容のテキストファイルsample.txtを作成する。まだステージングされていないことがgit statusで確認できる。

新規ファイルのステージング

作成したファイルをコミットする前に、そのファイルをステージングエリアに登録する必要がある。git add ファイル名でファイルをステージングエリアに登録する。

ワーキングディレクトリー下の対象ファイルを再帰的に全てステージングするにはgit add .とする。

git statusで確認すると、新たにsample.txtが登録されて、変更結果がコミット可能となっている。また、ステージングエリアからファイルを取り除くコマンドも示されている。

コミット

ステージングエリアのファイルをコミットするには、以下のコマンドでコメントを付けて実行。

git commit -m "コメント"

以下の例では、sample.txt"First file"というコメントを付けてコミットしている。コミット後のステータスは、コミットすべきファイルがない状態になっている。

コミットの結果はログに記録され、git logで確認できる。

ファイル編集とコミット

既作成のファイルを修正した場合のコミットの手順も新規作成と同じで、ステージング→コミットとなる。

ファイルの修正

先に作成したファイルに1行追加している。このままではステージングエリアに登録されていないことがget statusで確認できる。

ステージング

git addで変更後のファイルをステージング。アンステージのコマンドがgit resetからgit restoreに変わっている。

コミット

ファイルを変更した旨のコメントを付けてコミット。

ログには最初のコミット以降の一連の操作が記録されている。

ファイル削除とコミット

ファイル削除

まずrmコマンドでファイルを削除する。

ステージング

v1.8ではgit addのデフォルトオプションが--ignore-removalで、削除の時には--allオプションを明示的に指定する必要があったが、v2.24ではその必要はない。

削除済みファイルを対象とするので"."を指定。

この結果、sample.txtが削除されたことがステージングされている。

この結果をコミットすると、無事sample.txtが削除される。

ログの内容は以下の通り。

 

Git – CentOS7への最新版のインストール

概要

CentOS7にはGitがインストールされているが、バージョンが1.8と少し古い。

また、yumで普通にインストールする場合も、バージョンが1.8のものしか提供されていない。

最新版のインストール方法はネット上でいろいろな方法が紹介されているが、IUSのリポジトリーを使うのが簡明なようだ。

参考サイト:CentOS7にgitをインストールする

ところがこれに従ってIUSのリポジトリーをインストールしようとしたところエラーとなった。

以下のサイトによると、IUSのURLが変わっているとのこと。

参考サイト:iusの最新リンクが変更になったので注意

改めてIUSの最新のURLでリポジトリーをインストールして、最新版のGit(v2.2.4)をインストールすることができた。

IUSリポジトリーのインストール

IUSのサイトからリポジトリーをインストールする。

IUSリポジトリーはデフォルトでオプションとするため、以下の設定ファイルのenable = 1enbale = 0に修正する。

vi等で5行目のenabled = 10に修正。

インストール可能なGitの確認

IUSリポジトリーをenableにしてインストール可能なGitをチェックしたところ、v2.22とv2.24がインストール可能。

旧バージョンのGitのアンインストール

Vagrantのbento/CentOS7には、v1.8.3のGitがインストール済みなので、まずこれを削除する。

最新版のGitのインストール

最新版のGit(v2.24)をインストール。

バージョン確認

バージョン確認。

 

Git – ローカル操作 – v1.8

概要

  • ワーキングディレクトリーの作成は、対象ディレクトリー直下でgit initを実行
  • ファイル・ディレクトリーの作成・変更・削除後のコミットの前に、git addでステージングが必要
  • ステージングのコマンドは、git add --all .
    • ただし削除の場合は--allオプションが必要
  • ステージングエリアの状態をコミットするには、git commit -m "コメント"でコメントを付して実行

Gitの初期設定

バージョン確認

Vagrant-bento/CentOS7の場合、少し古いがGitがインストール済み。

初期設定

git configコマンドでユーザー名とメールアドレスを設定。この結果カレントディレクトリーに.gitconfigファイルが作成され、内容が記述される。

必要に応じてGit実行時のカラー設定。

ワーキングディレクトリー

ワーキングディレクトリーの作成

~/git/testディレクトリーを作成し、そこに移動する。このディレクトリーをワーキングディレクトリーとする。

ワーキングディレクトリーの初期化

~/git/testディレクトリーでgit initを実行する。

この結果、リポジトリーのスケルトンとして.gitディレクトリーが作成される。

ステータス確認

ワーキングディレクトリー内でgit statusコマンドを実行してみる。

この段階でステージングエリアにファイルがあれば、それがコミット可能として表示される。しかし現時点ではワーキングディレクトリーの初期化直後なので、ステージングエリアにはコミット可能なファイルはない。ファイルを作成またはコピーして、git addするよう示唆されている。

また、ブランチはmasterとなっている。

ファイルの新規作成とコミット

初期化したリポジトリーに、新たにファイルを作成してコミットする。手順は以下のとおり。

  1. ワーキングディレクトリーにファイルを新規作成・コピーする
  2. ファイルをステージング(ステージングエリアに登録)
  3. ステージングエリアのファイルをコミット

ファイルの新規作成

“初めてのGit”という内容のテキストファイルsample.txtを作成する。まだステージングされていないことがgit statusで確認できる。

新規ファイルのステージング

作成したファイルをコミットする前に、そのファイルをステージングエリアに登録する必要がある。git add ファイル名でファイルをステージングエリアに登録する。

ワーキングディレクトリー下の対象ファイルを再帰的に全てステージングするにはgit add .とする。

git statusで確認すると、新たにsample.txtが登録されて、変更結果がコミット可能となっている。また、ステージングエリアからファイルを取り除くコマンドも示されている。

コミット

ステージングエリアのファイルをコミットするには、以下のコマンドでコメントを付けて実行。

git commit -m "コメント"

以下の例では、sample.txt"First file"というコメントを付けてコミットしている。コミット後のステータスは、コミットすべきファイルがない状態になっている。

コミットの結果はログに記録され、git logで確認できる。

ファイル編集とコミット

既作成のファイルを修正した場合のコミットの手順も新規作成と同じで、ステージング→コミットとなる。

ファイルの修正

先に作成したファイルに1行追加している。このままではステージングエリアに登録されていないことがget statusで確認できる。

ステージング

git addで変更後のファイルをステージング。

コミット

ファイルを変更した旨のコメントを付けてコミット。

ログには最初のコミット以降の一連の操作が記録されている。

ファイル削除とコミット

バージョン1.8のGitの場合、ファイルを削除した時のステージング/コミットに注意が必要。

ファイル削除

まずrmコマンドでファイルを削除する。

警告状態での流れ

新規作成・変更の時と同じgit addコマンドでステージングしてみると、以下のような警告が出る。

このバージョンでは--ignore-removalオプションがデフォルトで、ファイルを削除してもその内容は反映されない。

git statusで確認してみると、コミットの対象となる操作はステージングされていないことがわかる。

削除も反映/–allオプション

警告時のメッセージに従って、git add--allオプションを付加する。削除済みファイルを対象とするので"."を指定。

この結果、sample.txtが削除されたことがステージングされている。

この結果をコミットすると、無事sample.txtが削除される。

 

GitHub – リモートパスワード認証の非推奨

パスワード認証の非推奨・停止

Gitでコミットした内容を、GitHubにpushするのにユーザー名とパスワードの入力したところ、問題なく内容は反映されたが以下のようなメールが届いた。

Hi @taustation,

You recently used a password to access the repository at taustation/hello-world with git using git/1.8.3.1.

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.

Thanks,
The GitHub Team

リモートでのパスワード認証が2021年8月13日以降できなくなるらしい。

さらに、GitHubへのサインインの認証を2要素認証に変更したところ、パスワード認証ができなくなった。

トークン認証

トークン認証への変更

  1. ヘッダーメニューのドロップダウンで”Settings”を選択
  2. 設定ページへ遷移
  3. 左メニューの”Developper settings”を選択
  4. 遷移後ページの左メニューで”Personal access tokens”を選択
  5. 右上の”Generate new token”ボタンをクリック
  6. New personal access tokenページへ遷移
  7. Noteのテキストボックスに、トークンの説明を入力
    • たとえば”For repository”など
  8. トークンの期限(Expiration)を設定
    • 無期限もあるが、有限にするのが望ましい
  9. scopeを設定
    • リポジトリーのpush/pull中心ならトップの”repo”にチェックで十分
  10. “Generate token”ボタンを押してトークンを生成

トークンを使った認証

改めてユーザ名とトークンを使ってGitの内容をpushする。

トークンの内容をコンソールに貼り付けても表示のフィードバックがないが、Enterキーを押して無事処理された。

SSH認証

SSH認証を設定すると、ユーザー名・パスワードの入力が必要なくなる。

  • ローカルで秘密鍵・公開鍵を生成
  • 公開鍵をGitHubに登録
  • ローカルで秘密鍵登録設定

 

GitHub – Hello worldガイド

スタートガイド~Hello world

ダッシュボードに表示されるHello worldガイドは、GitHub上でのリポジトリーの一連の操作を学習。

  1. リポジトリーの作成
  2. ブランチの作成
  3. コミット
  4. プルリクエスト
  5. プルリクエストのマージ

ダッシュボードページ

ダッシュボードページからHello worldガイドのページへ遷移する。

  1. “Read the guide”ボタンをクリック
  2. Hello worldページへ遷移

Step 1. Create a Repository

新しいリポジトリーを”hello-world”という名前で作成する。リポジトリーにはREADME.mdファイルのみが作成される。

ヘッダーメニュー

  1. 右上の”+”ドロップダウン
  2. New repositoryを選択
  3. Create a new repositoryページへ遷移

Create a new repositoryページ

  • Repository name: hello-world
  • Short description: 必要に応じて入力
  • Public: デフォルトでラジオボタン選択 (Privateは非選択)
  • Initialize this repository with: “Add a README file”をチェック
  • “Create repository”ボタンをクリック

Step 2. Create a Branch

mainに対してreadme-editsという名前でブランチを作成する。

  1. 新しく作成したhello-worldリポジトリーページ左上の”main”ドロップダウンをクリック
  2. “Find or create a branch …”のテキストボックスにreadme-editsと入力
  3. “Branches”タブの”Create branch: readme-edits from ‘main'”ボタンをクリック
  4. readme-editsブランチが作成され、左上のドロップダウンが”readme-edits”に変化
  5. その右のドロップダウンが”2 branches”に変化

Step 3. Make and commit changes

新しく作成したreadme-editsブランチのREADME.mdファイルの内容を変更し、変更内容をコミット。

  1. readme-editsブランチのREADME.mdファイルをクリック
  2. 右上のペンシルアイコンをクリック
  3. README.mdファイルの内容に行追加
  4. 下方の”Commit changes”にコミットの内容を追加
  5. “Commit changes”ボタンをクリック

Step 4. Open a Pull Request

ファイルを変更したreadme-editsブランチをプルリクエスト。

  1. readme-editsブランチ上方のPull requestsタブをクリック
  2. “New pull request”ボタンをクリック
  3. “readme-edits”をクリック
  4. 先ほどの修正内容であることを確認
  5. ブランチ作成時にコミット概要を書いていれば、それが反映されている
  6. Create pull requestボタンをクリック

Step 5. Merge your Pull Request

readme-editsブランチのプルリクエストをmainにマージ。

  1. “Merge pull request”ボタンをクリック
  2. “Confirm merge”をクリック

mainのREADME.mdファイルの内容が変更されているのが確認できる。