1 概要・連絡
1.1 概要
今回の講義では git (ギット) のインストール、VSCodeを使った GitHub リポジトリ (=リモートリポジトリ) の作成、変更内容のコミット操作・プッシュ操作、GitHubによるソースコードの公開について取り上げます (チーム開発を支援する機能や任意の過去バージョンに戻す機能などは、次回以降に段階的に学んでいきます)。
git とはローカルPCにインストールして利用する バージョン管理システム で、ソースコードの変更履歴を管理することができるアプリ (ソフト) です。また、GitHub は、1年の総合工学実験実習の知能情報コースの実験実習テーマ でも体験利用した「ウェブサービス」です。GitHub は (git と連携して) 主にチーム開発の支援や、ソースコードの公開などの機能を提供してくれます。
git/GitHub は、就職・進学してからは無論、高専在学中にも「各種セミナー」や「ハッカソン」「インターンシップ」「ポートフォリオづくり」「就職のエントリ」などの場面で利用します。ある程度の仕組みを分かって git/GitHub を使えるようになっておかないと、非常に困ること (場合によっては開発チームのメンバーに迷惑をかけること) になるので、しっかりと学ぶようにしてください。
なお、git/GitHub では「リポジトリ」「コミット」「ステージング」などの専門用語が頻出することにくわえ、仕組みも初学者にとっては難解なものになります。これらは、git/GitHub を実際に利活用していくなかで段階的に理解を深めていってください。特に、学び始めてからしばらくの間は、専門用語について調べて意味が完全理解できなくとも「呼称」「名前」として、そのまま受け入れるように努めてください (調べること自体はは大切です!)。
git/GitHub 関連の専門用語について
野球にも「イニング」「タイムリーエラー」「セーフティバント」「チェンジアップ」など単語を聞いただけでは内容が理解も想像もできない専門用語が多数存在します。野球を経験したことがない人は、これら専門用語について丁寧に説明を受けても、イメージを掴んだり、理解したりすることはなかなかできません。しかし、用語の意味が分からなくても (拙いながらも) 実際に野球をプレーすることは可能で、それを通じて専門用語のイメージをつかみ、理解を深めることができます。
これは git/GitHub においても同様です。学習初期では、専門用語の意味を理解しようとするよりも、まずは、それをひとつの概念や操作・処理として受け入れて、実際の経験や利用のなかで (ある程度の時間をかけながら) イメージや理解を深めていくことが求められます。
バージョン管理とは何か、何がうれしいのか
「バージョン管理とは何か」また「バージョン管理ができると何がうれしいのか」といったことについては、ウェブ記事やYouTubeなどを参照 してください。分かりやすい解説が掲載されています。
1.2 「課題6」に関する連絡
課題6 は、9月23日(土) 23:59 までに内容を整理し、仕上げておいてください。この期日以降は、各学生のアクセス設定を「閲覧のみ」に切り替えるので注意してください (学生の皆さんは内容を修正・変更できなくなります)。
- 課題6の詳細 (Classroom) ※ 2I学生のみアクセス可
2 gitのダウンロードとインストール・設定
以降、PC に Visual Studio Code (VSCode) がインストールされている前提での git のインストール作業になります。VSCode のインストール・初期設定については 第09回講義 を参照してください。
既に PC に git がインストールされている場合は「再インストール」は不要です (そのまま利用してください) 。ただし、テキストの解説には必ず目を通して、設定などは必要に応じて変更・修正してください。
2.1 gitがインストール済みであるかの確認方法
git が PC にインストールされているかどうかは
コマンドプロンプト から git -v
のコマンドを実行して確認できます。以下の例のように
バージョン情報の応答 があれば、git
がインストールされています。一方で、'git -v' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。
という応答があれば git はインストールされていません。
C:\Users\xxxx>git -v
git version 2.39.0.windows.2
gitのバージョンアップ
既に PC に git
がインストールされている場合、コマンドプロンプトから
git update-git-for-windows
を実行することでアップデートができます。
C:\Users\xxxx>git update-git-for-windows
Git for Windows 2.39.0.windows.2 (64-bit)
Update 2.42.0.windows.2 is available
Download and install Git for Windows v2.42.0.windows.2 [N/y]?
上記に対して y
を入力すると最新版へのアップデートが開始されます。基本的には最新版を利用するようにしてください。
gitを再インストールする場合の注意点
gitを再インストールする場合は、Windowsの「設定」-「アプリ」-「インストールされているアプリ」から Git 選択して「アンインストール」してから、再度、下記のインストール作業を行ってください。
また git
の旧設定を引き継がずに完全に新規インストールと同じ状態にしたい場合は、アンインストールした後に下記のファイルも手動削除してください
(あるいは .gitconfig.bak
のようにリネームして無効化してください)。
C:\Users\xxxx\.gitconfigここでxxxxは各自のアカウントに読み替えC:\Program Files\Git\etc\gitconfig- もしくは
C:\Program Files (x86)\Git\etc\gitconfig
- もしくは
2.2 GitHub の設定を確認
GitHub にログインしておきます。
GitHubにログインしている状態で、プロフィール設定のページ (https://github.com/settings/profile) にアクセスして、Public profile の「Name」の設定を確認しておきます。
これは gitインストール後の設定 で必要となる情報なのでテキストエディタなどにコピペしておいてください。なお、この Name は ユーザーネーム・表示名 (≠アカウント名) であり、アカウント名ではないことに注意 してください。
また、Nameに 日本語や絵文字を使用している場合 は、あとの作業におけるエラーの原因となるので修正・変更しておいてください。
つづいて、メール設定のページ(https://github.com/settings/emails)
にアクセスして「Keep my email addresses
private」と「Block command line pushes that
expose my email」の項目 (ページの下部)
にチェックを入れておきます。また、GitHub から付与される
コミット用のメールアドレス
(...@users.noreply.github.com)
を確認し、テキストエディタなどにコピペしておいてください。
上記の設定の意味は、以下のとおりです (十分に理解できなくてもいいので、読み飛ばさずに目を通してください)。
- We’ll remove your public profile email and use
12345678+GitHubAccountName@users.noreply.github.comwhen performing web-based Git operations (e.g. edits and merges) and sending email on your behalf. If you want command line Git operations to use your private email you must set your email in Git.Commits pushed to GitHub using this email will still be associated with your account.- ウェブ上でのGitの操作や、あなたの代わりにメールを送る際には、公開プロフィールのメールアドレスを「非表示」にし、代わりに
12345678+GitHubAccountName@users.noreply.github.comというアドレスを使用します。コマンドライン上での git 操作で個人のメールアドレスを使いたい場合は、git の設定からメールアドレスを設定してください。このアドレスで GitHub にデータをアップロードしても、それは正しくあなたのアカウントと紐づけられます。
- ウェブ上でのGitの操作や、あなたの代わりにメールを送る際には、公開プロフィールのメールアドレスを「非表示」にし、代わりに
- When you push to GitHub, we’ll check the most recent commit.
If the author email on that commit is a private email on your
GitHub account, we will block the push and warn you about exposing
your private email.
- GitHub にデータをアップロードする際、最新の変更点を確認します。もしその変更の著者のメールアドレスが GitHub アカウントの非公開メールだった場合、アップロードは停止され、私的なメールアドレスを公開してしまうリスクについてお知らせします。
2.3 git のダウンロード
Gitの公式サイト にアクセスして、Windows (64bit版・Standalone Installer) の 最新版の Gitインストーラ をダウンロードしてください。約60MB程度のファイルです。
PCにアプリをインストールするためのプログラムを「インストーラ (Installer)」といいます。
2.4 git のインストール
ここでは Git-2.41.0.3-64-bit.exe
を対象にインストール手順を説明します。Gitのバージョンが異なる場合は、適宜、内容を読み替えて作業を進めてください。
ダウンロードした Git-2.41.0.3-64-bit.exe
をダブルクリックしてインストーラを起動します。
2.4.1 git のライセンスの確認
- Please read the following important information before continuing. 先に進む前に以下の大切な情報を必ず確認してください。
- When you are ready to continue with Setup, click Next. セットアップを続行する準備ができたら「次へ」をクリックします。
ライセンス (GNU General Public License : GPL) について確認して次に進みます。GNU は「グヌー」や「グヌニュー」と発音します (牛的な動物の Gnu は「ヌー」と発音しますが、ここでは「グ」をつけて発音します)。
なお、GPLは コピーレフト型ライセンス であり、OSS (オープンソースソフトウェア) のなかでも利用に際して注意すべきライセンス (知らずにライブラリなどに組み込むと恐ろしいこと) になります。特に、ソフトウェアやウェブサービスでビジネスを考えている場合には注意してください。
- とほほのライセンス入門
- https://www.tohoho-web.com/ex/license.html#gpl-license
- GPLの解説:GNU General Public Licenseの基本概念と活用法
- https://the-simple.jp/gpl-commentary-basic-concepts-and-usage-of-the-gnu-general-public-license
GPLライセンス・コピーレフト
以下、とほほのライセンス入門 (https://www.tohoho-web.com/ex/license.html#gpl-license) からの引用です。
無償で利用・改造・再配布できますが、GPLのモジュールをライブラリとして呼び出すだけでも、呼び出したソースコード自体も GPL ライセンスとする必要があり、成果物の配布先に開発コードを公開する必要があります。これを コピーレフト とも呼びます。利用しただけでソース公開の義務が生じることから「GPLに感染する」ともいわれています。
2.4.2 インストール先の設定
- Where should Git be installed? Git をどこにインストールしますか?
Gitをインストールするフォルダを設定します。必要があれば変更して次に進みます。
2.4.3 インストールするコンポーネントの選択
- Which components should be installed? どのコンポーネント (機能) をインストールしますか?
- Select the components you want to install; clear the components you do not want to install. Click Next when you are ready to continue. インストールしたいコンポーネントを選択し、インストールしたくないコンポーネントを選択解除します。続行する準備ができたら「次へ」をクリックします。
要変更 スクリーンショットを参考にチェックする箇所を変更してください。
特に「(NEW!) Add a Git Bash Profile to Windows Terminal」は忘れずにチェックを入れてください。このオプションを設定すると、以下のように「ターミナル」に「Git Bash」を統合することができ、便利です。
2.4.4 スタートメニューのフォルダ名称の設定
- Setup will create the program’s shortcuts in the following Start Menu folder. セットアップにより、次のスタートメニューフォルダーにプログラムのショートカットが作成されます。
スタートメニューから「すべてのアプリ」に進んだときのフォルダ名称を設定します。必要に応じて変更し次に進みます。
2.4.5 git で使用する既定のテキストエディタの設定
- Choosing the default editor used by Git. Git で使用するデフォルト (既定) のテキストエディタの選択
- Which editor would you like Git to use? どのエディタを使用したいですか?
要変更 コンフリクト (編集内容の衝突) が発生した場合などに自動起動するデフォルトのテキストエディタを設定します。「Use Visual Studio Code as Git’s default editor」を選択してください。特に「Visual Studio Code」と「Visual Studio Code Insiders」の選び間違いに注意してください。なお、これらは事前に VSCode がインストールされていないと選択できません。
拘りがある場合は「Vim」などの別のエディタを設定しても問題ありません。
ここで設定したデフォルトテキストエディタはどこで使用されるのか
デフォルトエディタは、コマンドラインからコミットメッセージを付けずに
git commit
を実行したり、コンフリクトが生じた場合に、その解消のために git
によって自動起動されます。
2.4.6 初期ブランチ名称の設定
- Adjusting the name of the initial branch in new repositories 新規リポジトリにおける「初期ブランチ名」の変更
- What would you like Git to name the initial branch after “git init”? 「git init」の実行後、「初期ブランチ」に何という名前を付けますか?
要変更 「Override the default
branch name for new repositories
(リポジトリのデフォルトのブランチ名を main
でオーバーライドする)」を選択してください。2020年10月から GitHub
でのデフォルトブランチ名が master から
main
に変更になっており、ここではこれにあわせていきます (従来
master
という名称が使用されてきましたが、人権運動・人権問題の関係から最近では
main という名称の使用が推奨されています)。
- このほか、コンピュータ分野では Blaklist / Whitelist を Denylist / Allowlist に置き換えるような変化が起きています。
2.4.7 パス (環境変数) の設定
- How would you like to use Git from the command line? コマンドラインからGitをどのように使用しますか?
デフォルトの「Git from the command line and also from 3rd-party software (=コマンドラインおよびサードパーティソフトウェアからGitを使用する)」を選択します。
- (Recommended) This option adds only some minimal Git wrappers
to your PATH to avoid cluttering your environment with optional
Unix tools. You will be able to use Git from Git Bash, the Command
Prompt and the Windows PowerShell as well as any third-party
software looking for Git in PATH.
- (推奨) このオプションでは、余計な Unix ツールで環境が汚れるのを防ぐために、最小限の git の設定だけをシステムの PATH に追加します。これにより、Git Bash、コマンドプロンプト、Windows PowerShell、そして PATH 内で Git を検索するサードパーティソフトウェアで Git を利用できます。
2.4.8 デフォルト使用するSSHクライアントの選択
- Which Secure Shell client program would you like Git to use? git で使用する Secure Shell クライアントプログラムはどちらにしますか
- 「Use bundled OpenSSH (バンドルされている OpenSSH を使用する)」を選択してください。git とともにインストールされる ssh.exe を使用する設定になります。
2.4.9 デフォルト使用するSSL/TLSライブラリの選択
- Which SSL/TLS library would you like Git to use for HTTPS connections? Git において HTTPS 接続に使用する SSL/TLS ライブラリはどちらにしますか?
- 「Use the OpenSSL library (OpenSSLライブラリを使用する)」を選択してください。
2.4.10 改行コードに関する設定
- How should Git treat line endings in text files? git においてテキストファイルの行末をどのように処理しますか?
要変更 「Checkout as-is,
commit Unix-style line endings
(そのままチェックアウトし、Unix
スタイルの行末をコミットします)」を選択してください。将来的に
Docker で Linux
コンテナを立ち上げ、そこにリモート接続して開発・実行することを見越して、この設定を使用します
(VSCodeを使用すれば、改行コードが LF
でも画面表示は乱れないので、この設定で問題ありません) 。
- Git will not perform any conversion when checking out text
files. When committing text files, CRLF will be converted to LF.
For cross-platform projects, this is the recommended setting on
Unix (“core.autocrif” is set to “input”).
- Git はテキスト ファイルをチェックアウトするときに変換を実行しません。テキストファイルをコミットすると、CRLF は LF に変換されます。クロスプラットフォーム プロジェクトの場合、これは Unix での推奨設定です (「core.autocrif」は「input」に設定されます)。
2.4.11 ターミナルエミュレータの構成
- Which terminal emulator do you want to use with your Git Bash? Git Bash で使用するターミナルエミュレータはどちらにしますか?
「Use MinTTY (the default terminal of MSYS2)」を選択してください。
- Git Bash will use MinTTY as terminal emulator, which sports a
resizable window non-rectangular selections and a Unicode font.
Windows console programs (such as interactive Python) must be
launched via ’winpty to work in MinTTY.
- Git Bashは、ウィンドウのサイズを変更でき、非矩形の選択ができ、ユニコードフォントをサポートしている MinTTY というターミナルエミュレータを使用します。Windows のコンソールプログラム(例: 対話型Python)は、MinTTY で動作させるためには ‘winpty’ を介して起動する必要があります。
2.4.12 git pullのデフォルト動作設定
- What should
git pulldo by default? git pull にはデフォルトではどんな動作をさせますか?
「Default (fast-forward or merge)」を選択してください。
- This is the standard behavior of git pull: fast-forward the
current branch to the fetched branch when possible, otherwise
create a merge commit.
- これは git pull の標準的な動作です。可能であれば現在のブランチを、取得したブランチにファストフォワードさせます。それができない場合は新たにマージのコミットを作成します。
2.4.13 資格情報マネージャの選択
- Which credential helper should be configured? どの資格情報ヘルパーを構成する必要がありますか?
「Git Credential Manager」を選択してください。
2.4.14 追加オプションの設定
- Which features would you like to enable? どの機能を有効にしますか?
「Enable file system caching (システムのキャッシュを有効にする)」にチェックをいれてください。
- File system data will be read in bulk and cached in memory for
certain operations (“core.fscache” is set to “true”). This
provides a significant performance boost.
- ファイルシステムデータは一括で読み取られ、特定の操作のためにメモリにキャッシュされます (「core.fscache」が「true」に設定される)。これにより、パフォーマンスが大幅に向上します。
2.4.15 実験的オプションの構成
- These features are developed actively. Would you like to try them? これらの機能は積極的に開発されています。試してみませんか?
特にチェックを入れずに「Install」のボタンを押下してください。インストールが完了したら「Finish」のボタンを押下してインストールを完了させてください。
2.5 インストール後の git の設定
GitHub と連携させて利活用するための 重要設定 をします。
現在の git の「グローバル設定」と「システム設定」について確認します。スタートボタンを右クリックして「ターミナル (管理者)」を起動し、ターミナルのタブを「コマンドプロンプト」に切り替えます。
2.5.1 git 設定の確認
git の「グローバル設定」を確認するために
git config --global -l
を実行します。新規インストール直後であれば、次のような応答が返ってくると思います。なお、既に
git
をインストールして利用している場合は、その他の設定も表示されると思います。
C:\Users\xxxx>git config --global -l
core.editor="C:\Users\xxxx\AppData\Local\Programs\Microsoft VS Code\bin\code" --wait
インストール中に選択したようにデフォルトエディタ設定
(core.editor) として VSCode
が設定されていることを確認してください。
次に git の「システム設定」を確認するために
git config --system -l
を実行します。インストール直後であれば、次のような応答が返ってくると思います。
C:\Users\xxxx>git config --system -l
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt
core.autocrlf=input
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=main
ここで、必ず確認して欲しい項目が
core.autocrlf=input です。
もしも core.autocrlf=true や
core.autocrlf=false
となっている場合は、以下のようにコマンドを実行して設定を変更してください。この設定変更コマンドは「ターミナル
(管理者)」で実行しないと
Permission denied
で失敗するので注意してください。
git config --system core.autocrlf input
その他の項目 (インストール途中で設定した項目)
についても、上記ようなコマンドで変更することができます。例えば、初期ブランチの名前を
master
にしたい場合は、以下のコマンドを実行します。
git config --system init.defaultbranch master
なお、「グローバル設定」と「システム設定」に異なる設定があった場合は「グローバル設定」のほうが優先されます。さらに、必要に応じて「ローカル設定」も追加できます。詳しくは「git ローカル設定 グローバル設定 システム設定」などでウェブ検索してください。
設定ファイルのパス
ここで --global オプションをつけて設定した内容は
C:\Users\xxxx\.gitconfig
に保存されます。そのため、このファイルを直接編集することでも設定が可能です。
また --system オプションをつけて設定した内容は
C:\Program Files\Git\etc\gitconfig
に保存されます。OS環境によっては
C:\Program Files (x86)\Git\etc\gitconfig
となります。
2.5.2 GitHub と連携させるための設定の追加
重要設定 git と GitHub と連携させるために、次のコマンドを実行してグローバル設定に項目を追加します。
ここで K.Taro の部分は先に確認しておいたユーザーネーム・表示名
(≠アカウント名) に書き換えてください。
また、12345678+GitHubAccountName@users.noreply.github.com
の部分は先に確認しておいたコミット用のメールアドレスに書き換えてくだい。
git config --global user.name "K.Taro"
git config --global user.email "12345678+GitHubAccountName@users.noreply.github.com"
git config --global core.quotepath false
再び、git config --global -l
を実行して、上記の3つの設定がグローバル設定に追加されていることを確認してください。
以上で、git に関する最低限の設定は終了です。
core.quotepathについて
core.quotepath=false にすることで
git status
コマンドで「変更ファイル一覧」を表示させたときに日本語のファイル名が文字化けしないようになります。
3 リモートリポジトリの発行・変更内容のコミット
ここからは、VSCode を使ってプロジェクトフォルダの作成し、そのプロジェクトのリモートリポジトリを GitHub に発行、フォルダ内のファイルを変更して、それをコミット・プッシュするという操作・処理を体験します。このプロセスによって、ローカルに作成したプロジェクトフォルダのソースコードが GitHub を通じてウェブに公開されるようになります。
「リポジトリ」とは
リポジトリ (直訳すると収納庫) とは、プロジェクトを構成するファイルやフォルダ、その変更履歴を保管しておく場所を意味します。PCのローカルストレージに作成・配置するリポジトリを「ローカルリポジトリ」、GitHubなどのネットワークに作成・配置するリポジトリを「リモートリポジトリ」と言います。
なお、リモートリポジトリは中央リポジトリとよばれることもあります。
「コミット」とは
コミットとは、プロジェクトに含まれるファイルやフォルダの変更 (新規作成や削除を含む) を記録する行為、あるいは 記録そのもの を意味します。
「プッシュ」とは
プッシュとは、ローカルリポジトリの変更内容をリモートリポジトリにアップロードすることを意味します。
3.1 プロジェクトフォルダの作成
PC のドキュメントのフォルダ (
C:\Users\xxxx\Documents ) のなかに
GitHub-Test という名前のフォルダ
(プロジェクトフォルダ) を作成し VSCode
でオープンします。フォルダは、必ずこの名称にしてください
(異なる名称にすると、以下で読み替え作業が必要です)。
フォルダを VSCode でオープンする方法は 第09回講義のプロジェクトフォルダの作成 参照してください。
3.2 ファイルの追加
VSCode上から README.md
というマークダウン形式のファイルを新規作成し、以下の内容を記述して保存してください。マークダウン形式
(Markdown記法) は Google Colab. (Jupyter)
のテキストセルのフォーマットとして既に学習済みです、忘れてしまった場合はウェブ検索
して再学習ください。
# GitHub利用の練習
- VSCode から GitHub にリポジトリを発行
3.3 リモートリポジトリの発行
VSCodeのウィンドウの左側にならぶアイコンから「ソース管理」を選択し、パネルから GitHubに公開 のボタンを押下します。
次のダイアログが表示されるので「許可」を押下します。
ウェブブラウザが自動起動し GitHub へのログインが要求されるので GitHub の Username と Password を入力して「Sign in」のボタンを押下します。
ウェブブラウザに、次のようなダイアログが表示がされるので「Visual Studio Code を開く」のボタンを押下します。
VSCode に次のようなダイアログが表示されるので「開く」のボタンを押下します。
VSCode
のウィンドウの上部に以下のようなドロップボックスが表示されるので「Publish
to GitHub public repository
….」を選択します。これは、このプロジェクトフォルダを
GitHub-Test という名前のリポジトリとして GitHub
に発行 (Publish) する、という意味になります。
以下のように README.md
にチェックがついていることを確認して「OK」を押下します。この
README.md というファイルを GitHub に発行 (Publish)
するという意味になります。
次のダイアログが表示されるので「Sign in with your brower」を押下します。
ウェブブラウザの画面が自動的に次のように変わります。もし、GitHub への再ログインを求められたときは、あらためて Username と Password を入力してください。
Authentication Succeeded = 認証成功
3.4 GitHub に正常発行されていることを確認
プロジェクトフォルダの内容 (=README.md) が、各自の
GitHub アカウントの GitHub-Test
というリポジトリに正常に発行されたことを確認します。
ウェブブラウザから
https://github.com/XXXX/GitHub-Test つまり GitHub の
GitHub-Test リポジトリにアクセスして、次のように
README.md が表示されることを確認してください (GitHub
でマークダウンファイルはレンダリングされて画面表示されます)。URLの
XXXX には各自のアカウント名 (≠表示名)
が入ります。
3.5 ファイルを変更してコミット・プッシュ
プロジェクトフォルダに含まれる README.md
に変更をくわえて、その変更を コミット
(=変更を記録) して、さらに、それを プル
(=ローカルリポジトリの内容をリモートリポジトリにアップロード)
していきます。
以下のように README.md にテキストを追記して
保存 してください
(必ず保存処理をしてください)。
ソース管理のパネルで README.md
横の「+」をクリックします。この操作は
ステージング といって、そのファイルを「コミット
(変更履歴の記録) の対象」に含めるという意味があります。VScode
のソース管理パネル内で README.md
が「変更」グループから、「ステージされている変更」のグループに移動しました
(画面を確認してください) 。
「ステージング」とは
ステージングとは、変更したファイルを コミットの準備として選択 (ステージ) すること を意味します。git では、ファイルの変更を直接コミットするのではなく、まずその変更をステージングエリアに追加し、その後でコミットするという流れをとります。
コミットメッセージ (必須・空欄にできません)
を入力します。コミットメッセージには、変更内容を端的に表すような文章を書きます。ここでは
update README.md とします
(コミットメッセージには日本語を使用することもできます)。
コミットボタンの右側をクリックして「コミットして同期」を選択します。コミットして同期 とは、コミット、プッシュ、プル (フェッチとマージ) という一連の操作・処理を実行することを意味します。
- コミット: ファイルの変更内容をローカルリポジトリに変更履歴として記録すること。
- プッシュ: ローカルリポジトリにある変更履歴を、リモートリポジトリにアップロードすること。
- プル: リモートリポジトリの内容をローカルリポジトリにダウンロードして (この操作を フェッチ といいます) 、リモートリポジトリとローカルリポジトリの内容に差分があれば結合・統合すること (この操作を マージ といいまます)。フェッチとマージの処理をあわせてプルと表現します。
次のようなダイアログが表示されるので「OK」または「OK, Don’t Show Again」を選択します。
ウェブブラウザから、再度
https://github.com/XXXX/GitHub-Test にアクセスして
README.md が更新されていることを確認します。
4 リモートリポジトリでのファイル変更と同期
今度は、GitHub (リモートリポジトリ) 側で README.md
に変更をくわえてコミットして、それをローカル側で同期させてみます。
次のように GitHub で README.md
を編集モードに切り替えます。
次のように4行目に「GitHub(リモートリポジトリ)で
README.md
を直接編集してコミット」とテキストを追記して、右上の「Commit
changes」のボタンを押下します。
ダイアログが表示されるので、次のようにコミットメッセージを記入して「Commit changes」を押下し、変更をコミットします。
ブラウザをリロードすると、GitHub 上で変更が反映されていることが確認できます。
VSCode に戻ります。この時点では、リモートリポジトリで行なった
README.md
の変更はまだ反映されていません。この状態を「リモートリポジトリとローカルリポジトリが同期されていない」と表現します。同期させるためには
プル
という操作が必要で、これは画面下のアイコンをクリックすることで行ないます。
git/GitHub では、Googleドキュメントのようにリアルタイムの自動同期はされないこと に注意してください (プログラム開発では手動による同期のほうが何かと都合がよいのです)。
「プル」とは
プルとは、リモートリポジトリの内容をローカルリポジトリにダウンロードして、リモートリポジトリの内容 (コミット) と、ローカルリポジトリの内容 (コミット) を統合することを意味します。
同期が成功すると、以下のようにローカルリポジトリ側にも変更が反映されます。
ここでは、ローカルリポジトリとリモートリポジトリの両方から
README.md
に対して編集を加えて、変更の統合を行ないました。同様に、チーム開発でアリスとボブが
それぞれに同じファイルに対して編集を加えた際にも、GitHubを通じて変更の統合を行なうことができます
(このようなチーム開発支援に関する機能は次回以降に学びます)。
以上が確認できたら VSCode を閉じてください。
5 リポジトリの削除
ここまでに作成したリモートリポジトリとローカルリポジトリは、練習用のものなので削除します。
5.1 リモートリポジトリの削除
リモートリポジトリ (GitHubに発行したリポジトリ) を削除をしてください。削除の方法については「GitHub リポジトリ 削除」で検索して実行してください。
5.2 ローカルリポジトリの削除
PCのローカルストレージに作成したプロジェクトフォルダ
(=ローカルリポジトリ) を削除してください (この作業は VSCode
を閉じた状態で行なってください)。なお、削除する際にフォルダのなかに
.git
という隠しフォルダが作成されていることを確認しておいてください。
ローカルリポジトリにおいては、この .git
というフォルダのなかに変更の履歴が格納されていきます。そのため、リポジトリを削除するとき以外に
.git を削除しないようにしてください。
6 宿題
git/GitHub を使えるようになるには、プログラミング以上に「経験」や「慣れ」が求められます。授業で1度体験しただけでは、(実際のところ) 最低限のスキルも身に付かないです。
6.1 宿題①
再度、プロジェクトフォルダを新規作成し、リモートリポジトリを GitHub に発行、フォルダ内のファイルを変更・保存、変更内容のコミットとプッシュ、GitHub でのファイル変更とコミット、リポジトリの同期、リポジトリの削除という一連の操作・処理を、再度、実行してください (2回目以降は GitHub の認証などの一部操作は不要になります。実際に操作してそれを確認してください)。
この一連の作業を3回程度繰返すと、講義資料を見なくても操作ができるようになります (1回では身に付かないので、繰返し練習してください) 。
次回の授業では、ここまでの git/GitHub 操作が問題なくスムーズにできることを前提として進めます。問題・不具合がある場合は、次回授業の前日までに解決しておいてください (必要に応じて担当教員にアポをとって問題解決してください)。
6.2 宿題②
1年の総合工学実験実習で取り組んだ内容 (PG1_補足資料_ホームページをつくろう) について、改めて取り組み、リポジトリの内容をウェブページとして公開する方法について復習しておいてください。
特に「GitHub Pages として公開する手順」と「最低限のHTML」については十分に理解しておいてください (単に資料を読むだけではなく、実際にPCを操作して機能することを確認してください)。
次回以降、コンフリクトの解消、GitHub からのクローン、ウェブページの作成、GitHub Pages によるウェブページ公開などについて学びます。
- HTML/CSSについては Progate の「HTML & CSS 初級編」などで学んでおくと、以降の授業で役立ちます (情報系の学生として知っておいてください)。
6.3 宿題③
git/GitHub に関するウェブ記事やYouTube動画を閲覧して予習・復習に努め理解を深めてください。様々な資料を読む、見ることで理解が深まります。
git/GitHubの情報を探す場合の注意点
ウェブや書籍で git/GitHub の入門情報を探す場合、大きく次の3パターンが存在するので注意してください。
- コマンドラインを使った git/GitHub の操作を説明しているページ/書籍
- SourceTree というソフトを使った git/GitHub の操作を説明しているページ/書籍
- VSCode を使った git/GitHub の操作を説明しているページ/書籍
この授業では、主に3番目の方法で解説していきます。