Python学習の7日目は、これまで作成してきた「リアルタイム時計サービス」のプロジェクトを、開発者にとって必須のツールであるGitHubを使って管理する方法を学びます。
GitHubのメリットを理解するところから、実際にリポジトリを作成し、ローカルのプロジェクトをGitHubにアップロード（プッシュ）するまでを学習していきます。
なぜGitHubを使うの？ 6つの大きなメリット
「GitHubが便利らしい」ということは何となく知っていても、具体的にどんな良いことがあるのでしょうか？
Gemini先生に聞いてみると、GitHubは単なる「ソースコードの置き場所」ではなく、開発を強力にサポートしてくれる、以下のようなメリットがあると教えてくれました。
- 【バックアップと同期】どこでも同じ環境で開発できる
- 【強力なバージョン管理】コードの変更履歴がすべて残る
- 【共同作業の効率化】チームでの開発が劇的にスムーズになる
- 【ポートフォリオ】エンジニアとしての「名刺」になる
- 【スキルアップ】世界中のオープンソースプロジェクトに参加できる
- 【豊富な連携機能】開発プロセスを自動化できる
GitHubに安全なバックアップがある状態になるので、PCが壊れてもソースコードは失われず、インターネットに接続できれば世界中どこからでもソースコードアクセスできます。
また、複数のPCで開発する際も、常に最新に同期することができます。
「いつ」「誰が」「何を」変更したかが記録され、「昨日までは動いていたのに…」という時に簡単に過去の状態に戻せます。
GitHubでバージョン管理を行ってくれるので、ファイル名に「_最終版」と付ける悪夢から卒業できます！
複数人での開発において、誰がどんな作業をしているかが明確になり、コードレビューなどを通じて品質も向上します。
GitHubアカウントは、自分がどんなコードを書き、どんな活動をしているかを示す「技術的な名刺」にもなります。
有名なライブラリやフレームワークもGitHubで開発されています。
世界中のエンジニアのコードを読んだり、貢献したりすることで、スキルを磨けます。
コードが更新されたら自動でテストを実行したり、サーバーに公開（デプロイ）したりする「CI/CD」といった高度な機能も利用できます。
色々なことができて便利そうな反面学習コストが高そうで不安でもありますが、まずは手を動かしながら慣れていくことにします。
GitHubのアカウントとリポジトリを作成する
GitHubにアカウントを作成し、コードを保管する場所である「リポジトリ」を用意します。
- アカウントの作成：GitHub公式サイト にアクセスし、画面の指示に従ってアカウントを作成します。
- リポジトリ作成：サインイン後、画面右上の「+」から「New repository」を選択します。
- リポジトリ設定:
- Repository name: リポジトリの名前を入力します。（今回はtime_appとしています）
- Description (optional): リポジトリの説明を任意で入力します。
- Public / Private: リポジトリを公開（Public）するか、非公開（Private）にするかを選択します。（今回はPrivateとしています）
- Add a README file: チェックを入れることを強くおすすめします。READMEファイルは、そのプロジェクトの「顔」となる説明書です。ここにプロジェクトの概要や使い方を記述します。
- Create repository: 「Create repository」ボタンをクリックしてリポジトリを作成します
UbuntuにGitをインストール・初期設定（ローカル環境の準備）
開発を行っているVPS (Ubuntu) からGitHubを操作するために、以下のコマンドでGitをインストールして初期設定を行います。
Gitインストール
aptを使ってGitをインストールします。
$ sudo apt update $ sudo apt install git
インストールが正常に完了したか、バージョン情報を表示して確認します。
$ git --version git version 2.43.0
git version 2.x.x のようにバージョンが表示されれば、インストールは成功です。
Gitの初期設定（ユーザ情報）
Gitをインストールしたら、誰が使っているのかのユーザ情報登録するための初期設定を行います。
この設定は、コードをコミット（変更の記録）する際に「誰が変更したのか」を記録するための非常に重要な設定です。
$ git config --global user.name "ユーザ名" $ git config --global user.email "メールアドレス"
SSHキーの設定（推奨）
GitHubへ接続するたびにパスワードを入力するのは面倒ですよね。
そんな手間を省き、さらに安全に通信できるのが「SSHキー認証」です。
この設定を行えば、パスワードが不要になり、より安全・スムーズにGitHubを利用できるようになります。
SSHキーの生成
ssh-keygenコマンドを使ってSSHキーを作成します。
途中で保存場所やパスフレーズを聞かれますが、特にこだわりがなければ全てEnterキーを押して進めてOKです。
ssh-keygen -t ed25519 -C "GitHub登録メールアドレス"
- t ed25519 は、現在推奨されている安全な暗号化方式「ed25519」を指定するオプションです。
- -C "コメント"の部分は、このSSHキーに付ける「ラベル」の役割を果たします。
一般的には識別のためにGitHubの登録メールアドレスを設定しますが、必須ではありません。
例えば "vps-for-timeapp" のように、自分が見て何の鍵か分かるような説明を自由に記述できます。
実際に鍵を作成した際のログが以下になります。
今回は「Enter passphrase (empty for no passphrase):」と「Enter same passphrase again:」でそのまま「Enter」キーを押下することで、パスフレーズの設定されていないSSHの鍵を作成しています。
$ ssh-keygen -t ed25519 -C "tamohiko@server-memo.net" Generating public/private ed25519 key pair. Enter file in which to save the key (/home/tamohiko/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again:
今回の場合、鍵はそれぞれ以下の名前で作成されます。
- 秘密鍵：~/.ssh/id_ed25519
- 公開鍵：~/.ssh/id_ed25519.pub
「~」は、ユーザのホームディレクトリを表します。
ですので、「~/.ssh/id_ed25519」と「/home/tamohiko/.ssh/id_ed25519」は、同じファイルを表していることになります。
鍵の名前や作成場所を変更したい場合は、「Enter file in which to save the key(...):」の項目で変更できます。
公開鍵のコピー
生成された公開鍵（~/.ssh/id_ed25519.pub）の中身をクリップボードにコピーします。
$ cat ~/.ssh/id_ed25519.pub
表示された内容をマウスで選択してコピーします。
GitHubに公開鍵を登録
以下の手順で作成した公開鍵の内容をGitHubに登録します。
- GitHubにアクセスし、右上のプロフィールアイコンから「Settings」を選択
- 左のメニューから「SSH and GPG keys」をクリック
- SSH Keysの部分に表示されている「New SSH key」ボタンを押下
- 「Title」に、鍵の用途が分かるように名前を設定
- 「Key type」でAuthentication Keyを選択
- 「Key」の欄に、先ほどコピーした公開鍵を貼り付ける
- 「Add SSH key」をクリックして登録
より詳しい情報は、GitHubの公式ドキュメントへのリンクを参照してみてください。
接続テスト
SSH鍵が登録できたら、以下のコマンドを実行して正しくGitHubに接続できるか確認します。
$ ssh -T git@github.com
Are you sure you want to continue connecting (yes/no/[fingerprint])?と聞かれたら「yes」と入力します。
Hi [Githubユーザ名]! You've successfully authenticated... というメッセージが表示されれば成功です！
以下は実際にコマンドを実行した際のログです。（鍵のフィンガープリントはマスクしています）
$ ssh -T git@github.com
The authenticity of host 'github.com (20.27.177.113)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Hi servermemo! You've successfully authenticated, but GitHub does not provide shell access.
ローカルのプロジェクトをGitHubにアップロードする
開発用のUbutnuにあるローカルのプロジェクトとGitHub上のリポジトリを連携させ、コードやデータ等をアップロード（プッシュ）します。
現在は、「/srv/time_app」ディレクトリにプログラム等のファイルや画像データなどを格納しています。
今回はここのデータを、先ほどGitHubに作成したリポジトリ（time_app）にアップロード（プッシュ）して、今後バージョン管理を行って行きたいと思います。
連携させる方法として、以下の手順をGemini先生に教えてもらいました。
- Gitリポジトリの初期化： git init
- ステージング： git add データ
- コミット： git commit -m "コミットメッセージ"
- リモートリポジトリを登録： git remote add origin URL
- ブランチ名を変更： git branch -M main
- GitHubにデータをプッシュ： git push -u origin main
Gitリポジトリの初期化： git init
まず、プロジェクトのディレクトリに移動し、git init コマンドでGitの管理を開始しましょう。
これにより、このフォルダはGitがバージョン管理できる「リポジトリ」に変わります。
$ cd /srv/time_app $ git init
git init を実行すると、プロジェクトフォルダ内に .git という隠しディレクトリが作成されます。
このディレクトリ内に、変更履歴や設定など、バージョン管理に必要なすべてのデータが今後ここに格納されていきます。
ステージング git add データ
「ステージング」とは、次のコミット（変更の記録）に含めるファイルを「選ぶ」作業です。
git addコマンドを使って、記録したい変更を「ステージングエリア」と呼ばれる待機場所に追加します。
これにより、複数のファイルにまたがる修正（例：ある機能の追加）を一つの意味のあるまとまりとしてコミットできるため、後から変更履歴が見やすくなるという大きなメリットがあります。
今回は最初のコミットなので、ディレクトリ内のすべてのファイルをステージングの対象にします。
$ git add .
「.」(ドット) は、カレントディレクトリ（現在のディレクトリ）のすべてのデータを指定する記号です。
コミット： git commit -m "コミットメッセージ"
ステージングが完了したら、git commitコマンドで変更内容を正式な履歴として記録します。
これは、いつでも戻ってこられるセーブポイントを作る作業です。
コミットには、以下の情報も記録されます。
- データ：ステージングされたデータ
- 理由：なぜこの変更を行ったのかを説明するメッセージ
- ユーザと日時：コミットを行ったユーザと時間の情報
- ユニークなID：40文字の英数字からなるID（ハッシュ値）が自動的に割り振られる
-mオプションで、コミットメッセージを指定します。
今回は最初のコミットなので、以下のように入力しています。
$ git commit -m "Initial commit"
コミットの重要性
コミットは単なる「セーブ」ではありません。
こまめに、そして意味のある単位でコミットを行うことで、未来の自分やチームメンバーを助ける、たくさんのメリットが生まれます。
- 過去への「タイムトラベル」が可能になる
- 変更の「なぜ？」が分かるようになる
コミットは、コードの歴史そのものです。
「昨日までは動いていたのに！」という絶望的な状況でも、問題がなかった過去のコミットに一瞬で戻ることができます。
また、変更点を見比べて、バグの原因を特定する強力な手がかりにもなります。
半年後に自分のコードを見返した時、「なぜこの一行を追加したんだっけ…？」と悩むことはよくあります。
変更の意図や背景を書き残すことで、コードの可読性とメンテナンス性が劇的に向上します。
リモートリポジトリを登録： git remote add origin URL
「git init」で作成したローカルのGitリポジトリに、データの送り先となるGitHub上のリモートリポジトリの「住所」を教えてあげることで、ローカルとリモートが繋がり、データのやり取りができるようになります。
GitHubでSSHのURLをコピーする
まず、GitHub上のリポジトリの「住所」となるURLをコピーします。
SSHキーを使って安全に通信するために、SSH形式のURLを選びましょう。
- ブラウザで、作成したGitHubの空のリポジトリページを開く
- 画面の上部にある「Code」タブを選択
- 緑色の「Code」ボタンを押下
- 表示されたウィンドウの上にある「local」タブを選択
- SSHを選択してURLを表示
リモートリポジトリを登録する
SSHで接続するためのURLをコピーできたら、以下のコマンドでリモートリポジトリを登録します。
$ git remote add origin git@github.com:servermemo/time_app.git
ここで使われている origin とは、リモートリポジトリに付ける一般的な別名（エイリアス）です。
毎回長いURLを打ち込む代わりに、今後は origin という短い名前でこのリモートリポジトリを指し示すことができます。
登録された内容は以下のコマンドで確認できます。
$ git remote -v origin git@github.com:servermemo/time_app.git (fetch) origin git@github.com:servermemo/time_app.git (push)
ブランチ名を変更： git branch -M main
GitHubのデフォルトブランチ名は「main」ですが、古いGitは「master」という名前でブランチを作成します。
この名前のズレを解消するため、以下のコマンドでローカルのブランチ名をGitHubの標準に合わせて「main」に変更します。
$ git branch -M main
GitHubにデータをプッシュ： git push -u origin main
ローカルリポジトリに記録したコミットを、git pushコマンドを使ってGitHubにアップロードします。
git push -u origin main
最初のプッシュでは、「-u」オプションを付けて実行するのが一般的です。
この「-u」オプションは、ローカルのmainブランチとリモートの「origin/main」ブランチを紐づけるためのオプションで、一度実行しておけば、次回以降は単に「git push」だけで同じ場所にプッシュしてくれるようになります。
エラーが発生
実際にgit pushを実行すると、エラーが発生してしまいました…
これは多くの初心者が経験する「最初の関門」らしいので、慌てずに対処しましょう。
$ git push -u origin main To github.com:servermemo/time_app.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'github.com:servermemo/time_app.git' hint: Updates were rejected because the remote contains work that you do not hint: have locally. This is usually caused by another repository pushing to hint: the same ref. If you want to integrate the remote changes, use hint: 'git pull' before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
エラーの原因
表示されたメッセージを確認すると「リモートリポジトリに、あなたのローカル環境に無い変更が含まれているためpushできません。
まず、git pullで最新の状態にしてから、pushしてください。」といった内容が表示されています。
ですが、自分でGitHubに空のリポジトリを作成して、なにも更新していないのにすでに何らかの更新があるとは？？
とりあえず、こんなときはGemini先生に聞いてみることにします。
そうすると、以下のようなことを教えてくれました。
これは、特に以下のような場合に発生します。
- GitHubでリポジトリを作成する際に、「Add a README file」や「Add .gitignore」にチェックを入れた場合。
この操作を行うと、GitHub上に最初のコミット（README.mdファイルなどを含むコミット）が自動的に作成されます。
一方で、あなたのPC上のリポジトリは git init しただけの、まだコミットが何もない状態です。
この「リモートにだけコミットが存在する」というズレが原因で、Gitはあなたのローカルのコミットを単純に上書きして良いか判断できず、プッシュを拒否（reject）します。
GitHubにリポジトリを作成した際の内容を確認すると、GitHubでリポジトリを作成する際に「Add a README file」にチェックを入れていました。
なので、これが原因なのでしょう。
解決方法
Gemini先生は、対応法についてもいっしょに教えてくれました！
メッセージに書かれている通り、git pullを行ってリモートの変更内容をローカルに取り込んで、一つに統合してから、改めてプッシュすることです。
最も安全で推奨される方法は、git pull --rebase を使うことです
なぜ「git pull」だけではなく「--rebase」をつけるのか？
Gemini先生に、なぜ「git pull」を行う際にメッセージには表示されていない「--rebase」を推奨してくるのかを聞いてみました。
単に git pull origin main を実行すると、リモートの変更とローカルの変更を統合するために「マージコミット」という新しいコミットが自動的に作成されます。
小規模な個人のプロジェクトではそれでも問題ありませんが、コミット履歴が分岐して少し複雑になります。
「--rebase」を使うと、「マージコミット」を作らずに、あたかも最初からリモートの変更の上に自分の作業を積み重ねたかのような、一本のきれいなコミット履歴を保つことができます。チーム開発などではこちらの方法が好まれることが多いです。
このエラーは最初の関門のようなものです。この解決策を覚えておけば、今後の開発がスムーズになりますので、ぜひ試してみてください。
コミットの履歴がきれいになるということは理解できましたが、いまいちピンときません。
ですが、せっかく教えてくれたので、とりあえずは教えてもらった通りに作業を行って行くことにします。
$ git pull origin main --rebase remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) Unpacking objects: 100% (3/3), 896 bytes | 149.00 KiB/s, done. From github.com:servermemo/time_app * branch main -> FETCH_HEAD * [new branch] main -> origin/main Successfully rebased and updated refs/heads/main.
git pullで最新の状態にしたので、あらためてgit pushしてみます。
$ git push -u origin main Enumerating objects: 65, done. Counting objects: 100% (65/65), done. Delta compression using up to 2 threads Compressing objects: 100% (37/37), done. Writing objects: 100% (64/64), 8.59 MiB | 3.75 MiB/s, done. Total 64 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:servermemo/time_app.git fdf089d..682fdf0 main -> main branch 'main' set up to track 'origin/main'.
今度は無事アップロードできました！
WebブラウザでGitHubのリポジトリを確認すると、データがアップロードされていることが確認できます。
とりあえず、今日の目標としていたGitHubに今まで開発してきたデータをアップロードするところまでは完了しました！
まとめ：安全な開発の第一歩と、これからの課題
GitHubとローカルのプロジェクトを連携させる作業については理解することができました。
これで、ローカルプロジェクトとGitHub上のリポジトリが繋がり、安全にコードを管理していくための基盤が整いました。
今後はコードを変更するたびに以下の流れを繰り返すことで、作業履歴をしっかりと記録していくことができるので、より安全に開発ができるようになりました！
- git add 変更データ: 変更したファイルをステージング（記録の準備）
- git commit -m "コミットメッセージ": 変更内容をセーブポイントとして記録
- git push: ローカルの変更データをGitHubにアップロード
今回はGitHubを使う上で、本当に基本的な作業内容を学んだだけなので、より便利な使い方を学んで行きたいと思います。
コメント