GitHubでつまずかない!プロジェクト公開のためのコマンドとエラー解決ガイド
この記事では、Git初心者がつまずきやすいポイントに焦点を当て、GitHubにプロジェクトを公開するまでの基本的なコマンドと、よくあるエラーの解決策を解説します。
これだけおさえれば大丈夫
まずは、プロジェクトを公開するまでに使う基本的なコマンドをまとめました。それぞれのコマンドの詳しい内容は後述します。
git init
git config --global の設定
git add .
git commit -m "コミットメッセージ"
git remote add origin [リポジトリのURL]
git push -u origin main
.gitignoreについて
Gitに「このファイルは追跡しないでほしい」と教えるためのリストが**.gitignore**です。プロジェクトのルートディレクトリに、以下のような内容で自分で作成します。
# Pythonのキャッシュ
__pycache__/
*.py[cod]
*$py.class
# 仮想環境(venv, pipenvなど)
venv/
env/
ENV/
*.env
# IDEやエディタ
.vscode/
.idea/
*.swp
このように、一時ファイルや環境変数、機密情報などを除外するために .gitignore を作成します。特にAPIキーのような機密情報を誤ってGitHubにアップロードしてしまうミスは、今でもよく見かけますので注意が必要です。万が一アップロードしてしまった場合、巡回ボットに見つかり悪用される被害に遭う可能性があります。キーの管理、アクセス制御、コスト上限設定などでしっかり対策しておきましょう。
Gitの初期設定
まずはGitHubのアカウントと、新規リポジトリを作成しておきます。
端末にはgitをインストールしておきます。
私はscoopでインストールしました。
scoop install git
git initでローカルリポジトリを作成する。
git init
フォルダーをGitリポジトリとして初期化します。
.gitという隠しフォルダーが作られ、ここに履歴や設定が保存されます。
git config --globalでユーザー名とメールアドレスを設定する。
git config --global user.name "ユーザー名"
- user.name はGitHubのユーザー名と一致してなくてもOK
→ ただし、GitHub上で表示される「作者名」として使われるので、一致させるとわかりやすい。
git config --global user.email "メールアドレス"
- GitHubと連携するには、user.email が重要
→ GitHubのアカウントに登録されているメールアドレスと一致していれば、コミットが自分のものとして認識されます。
基本的なGitコマンド
git statusで現在の状態を確認する
git status
今の作業ディレクトリとステージ(インデックス)の状態を教えてくれるコマンドです。
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: index.html
実行するとこのように今のファイルの状態を教えてくれます。
Changes not staged for commit:変更はあるけど、まだステージに上げてない
(use "git add <file>..." to update what will be committed):git addを使ってコミットしてねって言っています。
ちなみに、gitのファイルの段階は下記のように分かれます。
[作業ディレクトリ] → git add → [ステージ] → git commit → git push → [リポジトリ]
git add、git commit、git pushの基本的な流れ
git add .
全てのファイルの変更をステージに上げます。
git commit -m "コミットメッセージ"
git remote add origin [リポジトリのURL]
GitにリモートリポジトリのURLを設定します。
GitHubのリポジトリページにある「<>Code」(緑色のボタン)をクリックし、HTTPSタブの中に表示されているURLをコピーしてきます。
originはこのリモートリポジトリにつける名前で、慣用的に使われるものです。
git push -u origin main
GitHubにコミットを送り込みます。
-uコマンドをつけることでローカルのmainブランチが、リモートのorigin mainブランチに紐づくという設定が保存されるので、次回からは
git push
だけでpushできるようになります。
アカウント認証
Git Credential Managerのポップアップが表示されるので、指示の通りに認証するとファイルが送られます。
つまずいたポイントと解決策
-
Not a git repository と言われたときの対処法
Gitの管理下にないフォルダーでGitコマンドを実行したときに表示されるエラーです。
git initコマンドを実行していないのなら実行します。git statusでファイルが正しく認識されているか確認してください。 -
mainとmasterブランチの食い違い
src refspec master does not match any
ローカルのブランチ名とリモートのブランチ名が一致していないことが主な原因です。
最近のGitではデフォルトのブランチ名がmasterからmainに変わった影響で食い違いが発生することがある。
git branch
コマンドを実行して
*master
と出る場合、以下のコマンドでローカルのブランチ名を変更させる必要があります。
git branch -M main
- git pull を使うべきタイミング
Updates were rejected because the remote contains work that you do not have locally.
This is usually caused by another repository pushing to the same ref.
If you want to integrate the remote changes, use 'git pull' before pushing again.
リモートにローカルに存在しない作業が含まれているため、更新が拒否されました。
これは通常、別のリポジトリが同じ参照にプッシュしたことが原因です。
リモートの変更を統合したい場合は、再度プッシュする前に「git pull」を使用してください。
GitHub上にローカルにない変更があるからプッシュを拒否します、というメッセージです。
私の場合はLisenceを自動作成していたために履歴に違いが出ました。README.mdを自動作成した場合にも取り込み作業が必要です。
git pull origin main
このコマンドで変更を取り込むことで履歴が一致します。
* branch
main
-> FETCH_HEAD
* [new branch]
main
-> origin/main
You have divergent branches and need to specify how to reconcile them.
You can do so by running one of the following commands sometime before your next pull
このエラーは、ローカルの main ブランチと、リモート(GitHub)の main ブランチの間に、お互いに存在しないコミット(変更)がそれぞれある場合に発生します。
git pull は、リモートの変更をローカルに取り込むコマンドですが、その際、どのように変更をまとめるかを指定する必要があります。
git pull --rebase origin main
このコマンドは、以下のことを行います。
- リモートの変更を先にローカルに取り込む。
- その上に、ローカルでの変更を適用する。
競合が解消されればpushすることができます。
まとめ
コマンドラインでのGit操作と、つまずきやすいエラーメッセージを中心に解説しました。Gitのメッセージは丁寧ですが、英語なので少し分かりにくく感じますね。なれない間はGUIで操作するのもいいかもしれません。
Discussion