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ファイルの内容が変更されているのが確認できる。

 

GitHub – サインアップ

サインアップの流れ

サインアップの流れは以下のとおり。

  1. GitHubサイトでサインアップを選択
  2. アカウント作成ページで必要情報を登録
  3. 職業などのバックグラウンド情報を登録
  4. 起動コードをメールで受け取って最終登録

GitHubサイト

https://github.co.jp/にアクセス

  1. 右上の”サインアップ”リンクをクリック
  2. Create your accountページへ遷移

アカウント作成

Create your accountページ

  1. 登録情報の入力
    • Username
    • Email address
  2. ロボットでないことの認証
  3. “Create account”ボタンでWelcome to GitHubページへ遷移

バックグラウンド登録

Welcome to GitHubページ

  1. 職業関係、プログラミング経験などのバックグラウンドに関する質問に回答
  2. “Complete setup”ボタン
  3. 起動コードが登録したメールアドレスに届く

起動コード入力・サインアップ完了

  1. メール本文の”Open GitHub”ボタンでコード入力ページへ
  2. 起動コードを入力してサインイン
  3. ダッシュボードページへ遷移

2要素認証の推奨

GitHubサインイン時、ユーザー名とパスワードに加えて6桁のコードの入力が求められる。

登録したアドレスに送られるメールでコードを得られるが、平文で危険あり、毎回メールが送信されるのも面倒。

GitHubでは2要素認証(two-factor authentication: 2FA)を推奨しており、スマートフォンのアプリと紐づけることでアプリからコードを得られる。

SMSも選択できるが、日本のキャリアには対応していないらしい。

2要素認証の設定はこちらに整理。

 

GitHub – 2要素認証

2要素認証の推奨

GitHub登録後にサインインしようとすると、”Device verification”を求めらるページに遷移した。6桁の端末認証コードの入力が必要で、登録したEmailに認証コードを送ったとのこと(20210803時点)。

Hey taustation!

A sign in attempt requires further verification because we did not recognize your device. To complete the sign in, enter the verification code on the unrecognized device.

Device: Chrome on Windows
Verification code: ******

この6桁のコード(Verification code)をブラウザーで入力すると、すぐにサインインした。

このメールでは以下のメッセージが続いている。

If you did not attempt to sign in to your account, your password may be compromised. Visit https://github.com/settings/security to create a new, strong password for your GitHub account.

If you’d like to automatically verify devices in the future, consider enabling two-factor authentication on your account. Visit https://docs.github.com/articles/configuring-two-factor-authentication to learn about two-factor authentication.

If you decide to enable two-factor authentication, ensure you retain access to one or more account recovery methods. See https://docs.github.com/articles/configuring-two-factor-authentication-recovery-methods in the GitHub Help.

1段落目は、もしサインインしようとしていないのにこのメールが届いた場合、パスワードが盗まれている可能性があることを示唆している。リンクをクリックすると、サインイン中ならパスワード変更のページに遷移する。

2段落目は、デバイスの認証を自動化したい場合には2段階認証とするよう示唆している。

3段落目は、2段階認証にする場合のリカバリー手順を保存しておくことを示唆している。

2要素認証の流れ

  1. スマートフォンに認証アプリをインストールする

設定

スマートフォンへの認証アプリのインストール

スマートフォンのGoogle Playで”認証システム”で検索してヒットするGoogle認証システムをインストール。URLは以下のとおり。

https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=ja

インストール後のアプリケーション名が日本語の「認証システム」なのでちょっと見つけにくかった。

GitHubの設定

  1. ヘッダーメニューのドロップダウンで”Settings”を選択
  2. 設定ページの左メニューで”Account security”をクリック
  3. 下方Two-factor authenticationセクションにある”Enable two-factor authentication”ボタンをクリック
  4. 遷移後のページで”Setup using an app”と”Set up using SMS”のラジオボタン表示
  5. appの方を選択し(デフォルト)、”Continue”ボタンをクリック
  6. Authentication verificationのステップになり、QRコード表示

認証アプリへのGitHubの登録

  1. 認証アプリを起動してQRコードをスキャン
  2. 6桁のコードが表示されるので、それをGitHubのブラウザーに入力
  3. リカバリーコードが表示されるのでダウンロードして保存
  4. “Done”ボタンを押して完了

設定後の認証

  1. GitHabにサインイン
  2. ユーザー名とパスワードを入力
  3. 6桁のコードを問われるので、アプリに表示されるコードを入力