Gitの初期設定方法【初心者向け】

By /

Gitの初期設定方法【初心者向け】 – バージョン管理の第一歩

はじめに

プログラミング学習やWeb制作、チームでの開発において、「バージョン管理」は避けて通れない重要な技術です。そして、そのバージョン管理システムのデファクトスタンダードとなっているのが Git です。

Gitを使うことで、あなたのプロジェクトの歴史を記録し、いつでも過去の状態に戻したり、複数人で同時に作業を進めたりすることが可能になります。しかし、Gitを使い始める前に、いくつかの初期設定を行う必要があります。この初期設定は、Gitをスムーズに、そして効果的に使うために非常に重要です。

「Gitって何？」「バージョン管理って難しそう…」「設定って言われると尻込みしちゃうな」と感じている初心者の方、ご安心ください。この記事は、あなたがGitを使い始めるための第一歩を踏み出せるよう、Gitのインストールから、初期設定の各項目について、なぜその設定が必要なのか、どのように設定すれば良いのかを、どこよりも詳しく、丁寧に解説することを目的としています。

この記事を読めば、

  • Gitがなぜ必要なのか、その重要性が理解できます。
  • お使いのOSにGitを正しくインストールできます。
  • Gitを使う上で必須となるユーザー情報の登録ができます。
  • コミットメッセージなどを入力するためのエディタを設定できます。
  • 初心者の方がつまずきやすい「改行コード」の問題に対処できます。
  • その他、Gitをより快適に使うための便利な初期設定を知ることができます。
  • 設定内容を確認・管理する方法が分かります。
  • リモートリポジトリ（GitHubなど）との連携に必要な認証設定の基本が理解できます。

Gitの初期設定は、一度きちんと行えば、その後の開発効率が格段に向上します。この記事が、あなたのGitマスターへの第一歩となることを願っています。さあ、一緒にGitの世界へ踏み出しましょう！

Gitとは？ なぜGitを使うのか？ バージョン管理の重要性

Gitは、分散型バージョン管理システムです。バージョン管理とは、ファイルやディレクトリの状態を記録し、管理することです。プログラムのコード、ドキュメント、設定ファイルなど、様々なファイルの変更履歴を管理するのに役立ちます。

なぜバージョン管理が必要なのでしょうか？ 例を挙げてみましょう。

あなたがレポートを作成しているとします。

  • 「レポート_最終版.docx」
  • 「レポート_最終版_修正.docx」
  • 「レポート_最終版_先生チェック後.docx」
  • 「レポート_最終版_本当にこれでおしまい.docx」

このように、ファイルをコピーして名前を変えながら作業を進めた経験はありませんか？ これでは、どのファイルが最新なのか分からなくなったり、過去の変更内容を確認するのが難しくなったりします。また、間違って重要な変更を削除してしまったり、元の状態に戻したくても戻せなくなったりするリスクもあります。

Gitを使えば、このような問題を解決できます。Gitはプロジェクト全体の変更履歴を管理し、「いつ」「誰が」「どのような変更を」行ったかを正確に記録します。これにより、

  • 変更履歴を追跡できる: 過去のどの時点の状態にも簡単に戻れます。
  • 間違った変更を取り消せる: うまくいかなかった変更を簡単に破棄できます。
  • 複数人での共同作業が容易になる: 各自が独立して作業を進め、後で変更内容を統合できます。
  • バックアップになる: リモートリポジトリ（GitHubなどのオンラインストレージ）に履歴を保存すれば、ローカル環境に何かあってもデータを復旧できます。

つまり、Gitはあなたの作業を安全かつ効率的に進めるための強力なツールなのです。

Gitのバージョン管理は、スナップショット（ある時点でのプロジェクト全体のコピー）を記録していくイメージです。変更があったファイルだけを効率的に保存するため、容量も抑えられます。そして、分散型であるため、リモートリポジトリだけでなく、ローカル環境にも完全な履歴が保存されます。これにより、オフラインでも作業が進められますし、リモートリポジトリに問題が発生しても、ローカルの履歴から復旧が可能です。

Gitのインストール

Gitを使うためには、まずお使いのコンピュータにGitをインストールする必要があります。インストール方法はOSによって異なりますが、ここでは主要な3つのOS（Windows, macOS, Linux）について、それぞれ詳しく解説します。

WindowsでのGitインストール

Windowsには、Gitの公式ディストリビューションである「Git for Windows」をインストールするのが最も一般的で簡単です。

  1. インストーラーのダウンロード:

    • Git公式サイト（https://git-scm.com/）にアクセスします。
    • トップページにあるダウンロードボタンをクリックすると、お使いのOSに合ったインストーラーが自動的に検出されてダウンロードが始まります。手動でダウンロードしたい場合は、「Downloads」ページからWindows用の最新版インストーラー（.exeファイル）を選択してください。
    • ダウンロードが完了したら、ダウンロードしたファイルを実行します。

  2. インストーラーの実行と設定:

    • インストーラーを起動すると、いくつかの設定画面が表示されます。初心者の方は、基本的には推奨設定のまま進めて問題ありませんが、いくつかの重要なオプションについて説明します。
    • Information: ライセンス情報が表示されます。「Next」をクリックします。
    • Select Destination Location: Gitをインストールする場所を指定します。特にこだわりがなければ、デフォルトのパス（C:\Program Files\Git など）のままで良いでしょう。「Next」をクリックします。
    • Select Components: インストールするコンポーネントを選択します。
      • Git Bash Here: エクスプローラーの右クリックメニューに「Git Bash Here」を追加します。非常に便利なのでチェックを入れたままにしておきましょう。
      • Git GUI Here: エクスプローラーの右クリックメニューにGitのGUIツールを追加します。これも便利なのでチェックを入れたままにしておきましょう。
      • Git LFS (Large File Support): 大容量ファイルを扱う場合に必要になります。通常はチェックを外しておいても構いません。
      • Associate .git* configuration files with the default text editor: Gitの設定ファイルをデフォルトのエディタで開くように関連付けます。チェックを入れたままで良いでしょう。
      • Associate .sh files with Bash: .shファイルをGit Bashで開くように関連付けます。チェックを入れたままで良いでしょう。
      • 他のオプションは通常デフォルトのままで構いません。特に「Windows Explorer integration」の部分は重要で、GUIオプションと共に右クリックメニューへの追加が選択されます。
      • 「Next」をクリックします。
    • Select Start Menu Folder: スタートメニューのフォルダー名を指定します。デフォルトのままで良いでしょう。「Next」をクリックします。
    • Choosing the default editor used by Git: Gitがコミットメッセージなどを入力する際に使用するデフォルトのエディタを選択します。ここでは、後から設定で変更することを前提に、好きなものを選んで構いません。 もしコマンド操作に慣れていない場合は、Vim以外のエディタ（例えば NanoやNotepad++、または後からVS Codeなどを設定する前提でデフォルトのVimでも良い）を選ぶと良いかもしれません。この設定は後で簡単に変更できますので、深く考えすぎず進めましょう。「Next」をクリックします。
    • Adjusting the name of the initial branch: Git 2.28から、新しいリポジトリを作成する際のデフォルトのブランチ名を指定できるようになりました。従来のmasterから、より中立的なmainに変更することが推奨されています。
      • Let Git decide: デフォルトのブランチ名をGitが決定します（通常はmasterですが、将来的にmainに変更される可能性があります）。
      • Override the default branch name for new repositories: 新しいリポジトリのデフォルトブランチ名を自分で指定します。ここでmainと入力しておくのがおすすめです。
      • 特に理由がなければ、ここでmainを選択するのが現代的なプラクティスに沿っています。「Next」をクリックします。
    • Adjusting your PATH environment: GitのコマンドをコマンドプロンプトやPowerShellなど、どのシェルから実行できるようにするかを設定します。
      • Use Git from Git Bash only: Git BashからのみGitコマンドを実行できます。非推奨。
      • Git from the command line and 3rd-party software (推奨): これを選択すると、コマンドプロンプト、PowerShell、Git Bashなど、どのシェルからもGitコマンドを実行できるようになります。多くのツールとの連携を考えると、このオプションが最も便利です。PATH環境変数にGitのディレクトリが追加されます。
      • Use Git and optional Unix tools from the Command Prompt: 上記に加え、find, sortなどのUnixコマンドもWindows環境で使えるようにします。Windowsのコマンドと名前が重複して問題が発生する可能性があるため、通常は推奨されません。
      • 推奨の「Git from the command line…」を選択し、「Next」をクリックします。
    • Choosing the HTTPS transport backend: リモートリポジトリとの通信に使われるHTTPSバックエンドを選択します。
      • Use the OpenSSL library (推奨): 多くの環境で問題なく動作します。
      • Use the native Windows Secure Channel library: Windows標準の証明書ストアを使用します。
      • 特に理由がなければ推奨のOpenSSLで良いでしょう。「Next」をクリックします。
    • Configuring the line ending conversions: 改行コードの自動変換に関する設定です。これは非常に重要な設定で、後ほど「改行コードの設定」のセクションで詳しく解説しますが、インストーラーの選択肢も理解しておきましょう。
      • Checkout Windows-style, commit Unix-style line endings (推奨 for Windows): リポジトリからファイルを取得する際にLF（Unix形式）をCRLF（Windows形式）に自動変換し、コミットする際にCRLFをLFに自動変換します。Windowsユーザーで、テキストファイルをWindows標準のテキストエディタで編集する場合に最も無難な設定です。
      • Checkout as-is, commit Unix-style line endings: リポジトリからファイルを取得する際の改行コードはそのまま（LF）にし、コミットする際にCRLFをLFに自動変換します。LF形式を保持したい場合や、LFを正しく扱えるエディタ（VS Code, Sublime Text, Atomなど）を使う場合に選択肢となります。
      • Checkout as-is, commit as-is: チェックアウト時もコミット時も、一切改行コードの変換を行いません。改行コードの問題を完全に自分で管理したい場合に選択します。初心者には推奨されません。
      • 特に理由がなければ、推奨設定の「Checkout Windows-style…」を選択し、「Next」をクリックします。
    • Configuring the terminal emulator to use with Git Bash: Git Bashで使うターミナルエミュレーターを選択します。
      • Use MinTTY (the default terminal of MSYS2) (推奨): 高機能でカスタマイズ性が高いターミナルです。
      • Use Windows' default console window: Windows標準のコマンドプロンプトのようなターミナルです。機能がMinTTYに比べて限定されます。
      • 推奨のMinTTYを選択し、「Next」をクリックします。
    • Choose the default behavior of git pull: git pullコマンドのデフォルトの挙動を選択します。これはリモートの変更を取り込む際に関わる設定です。
      • Default (fast-forward or merge): リモートの変更がローカルの履歴に一方的に追加できる場合（fast-forward）、それを行います。そうでない場合はマージコミットを作成します。
      • Rebase: リモートの変更をローカルのコミットの手前に適用し、コミット履歴を一直線にします。履歴がきれいになりますが、慣れていないと競合解消が少し複雑に感じられる場合があります。
      • Only ever fast-forward: fast-forwardできる場合のみプルします。それ以外の場合は失敗します。
      • 初心者の方は、デフォルト（Fast-forward or merge）のままで良いでしょう。後から設定で変更可能です。「Next」をクリックします。
    • Choose a credential helper: Gitがリモートリポジトリにアクセスする際の認証情報をどのように扱うか設定します。
      • Git Credential Manager (推奨): 認証情報を安全に保存し、パスワードなどを毎回入力する手間を省いてくれます。
      • その他のオプションは通常選択しません。
      • 推奨の「Git Credential Manager」を選択し、「Next」をクリックします。
    • Configuring extra options: その他の追加オプションです。
      • Enable file system caching: ファイルシステムの情報をキャッシュしてパフォーマンスを向上させます。チェックを入れておいて良いでしょう。
      • Enable symbolic links: シンボリックリンクの使用を有効にします。開発で必要になる場合があるため、チェックを入れておくと良いでしょう。
      • 「Install」をクリックしてインストールを開始します。

  3. インストール完了:

    • インストールが完了するまで待ちます。
    • 完了画面が表示されたら、「Finish」をクリックしてインストーラーを閉じます。必要であれば、「Launch Git Bash」や「View Release Notes」のチェックを外してください。

これでWindowsへのGitのインストールは完了です。

macOSでのGitインストール

macOSの場合、Gitをインストールする方法はいくつかあります。

  1. Xcode Command Line Toolsを使う (推奨・最も簡単):

    • macOSには、開発者向けのツール群であるXcode Command Line ToolsにGitが含まれています。多くの場合、Gitをインストールする必要はありません。
    • ターミナルを開きます（Spotlight検索で「ターミナル」と入力するか、アプリケーション > ユーティリティ > ターミナル）。
    • 以下のコマンドを実行して、Gitが既にインストールされているか確認します。
      bash
      git --version
    • もしGitがインストールされていない場合や、バージョンが古い場合は、Gitコマンドを実行しようとすると「The “git” command requires the command line developer tools. Would you like to install the tools now?」といったメッセージが表示され、インストールを促されることがあります。画面の指示に従ってインストールしてください。
    • 手動でインストールしたい場合は、ターミナルで以下のコマンドを実行します。
      bash
      xcode-select --install
      これにより、Command Line Toolsがインストールされ、その中に含まれるGitも利用できるようになります。

  2. Homebrewを使う (推奨):

    • HomebrewはmacOS向けのパッケージマネージャーで、様々なソフトウェアを簡単にインストールできます。GitもHomebrewを使ってインストールするのが一般的です。
    • まず、Homebrewがインストールされているか確認します。ターミナルで以下のコマンドを実行します。
      bash
      brew --version
      Homebrewがインストールされていない場合は、公式サイト（https://brew.sh/index_ja）の指示に従ってインストールしてください（通常、ターミナルで指定されたコマンドを実行するだけです）。
    • Homebrewを使ってGitをインストールするには、ターミナルで以下のコマンドを実行します。
      bash
      brew install git
    • インストールが完了したら、Gitが正しくインストールされたか確認します（後述）。

  3. 公式インストーラーを使う:

    • Git公式サイト（https://git-scm.com/）からmacOS用のインストーラー（.dmgファイル）をダウンロードして実行することもできます。
    • ダウンロードしたファイルをダブルクリックし、表示されるパッケージインストーラーの指示に従ってインストールを進めます。
    • 基本的にはデフォルト設定で問題ありません。

推奨はCommand Line Toolsを使うか、Homebrewを使う方法です。どちらを使っても機能に大きな違いはありません。

LinuxでのGitインストール

Linuxの場合、各ディストリビューションのパッケージマネージャーを使ってGitをインストールするのが最も一般的です。

  1. Debian/Ubuntu系 (apt):

    • ターミナルを開きます。
    • パッケージリストを最新の状態に更新します。
      bash
      sudo apt update
    • Gitをインストールします。
      bash
      sudo apt install git
    • パスワードの入力を求められたら入力します。

  2. Fedora系 (dnf – Fedora 22以降) または Red Hat/CentOS系 (yum – Fedora 21以前, CentOS/RHEL):

    • ターミナルを開きます。
    • Gitをインストールします。
      • Fedora:
        bash
        sudo dnf install git
      • CentOS/RHEL:
        bash
        sudo yum install git
    • パスワードの入力を求められたら入力します。

  3. Arch Linux系 (pacman):

    • ターミナルを開きます。
    • Gitをインストールします。
      bash
      sudo pacman -S git
    • パスワードの入力を求められたら入力します。

インストール確認

Gitのインストールが完了したら、正しくインストールされているか確認しましょう。ターミナル（Windowsの場合はGit Bashやコマンドプロンプト/PowerShell、macOS/Linuxの場合は通常のターミナル）を開き、以下のコマンドを実行します。

bash
git --version

もしGitが正しくインストールされていれば、インストールされたGitのバージョン情報が表示されます。

git version 2.40.1 # バージョン番号は異なる場合があります

バージョン情報が表示されず、「command not found」のようなエラーが表示される場合は、インストールがうまくいっていないか、PATH環境変数の設定が正しくない可能性があります。特にWindowsでインストーラーの「Adjusting your PATH environment」の設定を間違えた場合や、macOS/Linuxで手動でインストールした場合に発生しやすいです。その場合は、再度インストールを試みるか、Gitの実行ファイルがあるディレクトリを環境変数PATHに追加してみてください。

Gitの初期設定（本題）

Gitのインストールが完了したら、いよいよ初期設定を行います。この設定は、あなたが誰であるか、どのようなエディタを使いたいかなど、Gitの基本的な動作に関わるものです。

Gitの設定は、git config コマンドを使って行います。設定には適用範囲が3つあります。

  1. システム全体 (--system): コンピュータの全てのユーザーに適用される設定です。通常は管理者権限が必要です。設定ファイルはシステム全体の構成ディレクトリ（例: /etc/gitconfig）に保存されます。
  2. ユーザー全体 (--global): 現在のユーザーに適用される設定です。この設定が最もよく使われます。一度設定すれば、そのユーザーが操作する全てのリポジトリに適用されます。設定ファイルはユーザーのホームディレクトリ（例: ~/.gitconfig または ~/.config/git/config）に保存されます。
  3. リポジトリ個別 (--local またはオプションなし): 現在作業している特定のリポジトリだけに適用される設定です。設定ファイルは、そのリポジトリ内の .git/config に保存されます。

初期設定のほとんどは、あなたのユーザー全体に適用されるべき設定なので、通常は --global オプションを使用します。

bash
git config --global <設定項目> <設定値>

このコマンド形式を覚えておきましょう。

1. ユーザー情報の設定

Gitでコミット（変更内容の記録）を行う際には、「誰が」その変更を行ったのかを記録する必要があります。このため、あなたの名前とメールアドレスをGitに登録する必要があります。これは必須の設定です。

なぜユーザー情報が必要か

Gitのコミットには、コミットを行ったユーザーの名前とメールアドレスが記録されます。これは、プロジェクトの変更履歴を見たときに、「この変更は誰が行ったものなのか」を明確にするためです。特にチームで開発を行う場合、誰がどのコードを変更したのかを追跡するために非常に重要になります。

設定方法

以下のコマンドを、あなたの名前とメールアドレスに置き換えて実行します。

  1. ユーザー名の設定:
    bash
    git config --global user.name "あなたの名前"
    例：
    bash
    git config --global user.name "Taro Yamada"
    ユーザー名は、コミットログやGitHubなどのWeb UIに表示される名前になります。好きな名前を設定できますが、通常は本名や開発者名など、あなただと識別できる名前を使用します。

  2. メールアドレスの設定:
    bash
    git config --global user.email "あなたのメールアドレス"
    例：
    bash
    git config --global user.email "[email protected]"
    メールアドレスもコミットログに記録されます。GitHubなどのサービスと連携する場合、GitHubに登録しているメールアドレスと同じものを設定するのが推奨されます。これにより、GitHub上であなたのコミットとして正しく紐付けられます。公開したくないメールアドレスの場合は、GitHubが提供する「noreply」メールアドレスを使用することも可能です。GitHubの設定画面で確認できます（例: [username]@[ID].noreply.github.com）。

これらの設定は、Git Bashやターミナルから一度実行すれば、その後あなたがそのユーザーとして行う全てのGit操作（コミット）に適用されます。

設定内容の確認

設定したユーザー情報が正しく登録されたか確認するには、以下のコマンドを実行します。

bash
git config --global user.name

bash
git config --global user.email

それぞれ設定した名前とメールアドレスが表示されれば成功です。

ユーザー全体の全ての設定一覧を確認したい場合は、以下のコマンドを実行します。

bash
git config --global --list

あるいは、全ての適用範囲（システム、ユーザー、リポジトリ）の設定をまとめて確認するには、以下のコマンドを実行します。

bash
git config --list

この場合、同じ設定項目が複数表示されることがありますが、リポジトリ個別の設定があればそれが最優先され、次にユーザー全体の設定、最後にシステム全体の設定が適用されます。git config --listは、最終的にGitがどのような設定を適用しているかを確認するのに便利です。

2. テキストエディタの設定

Gitは、コミットメッセージの入力や、マージの競合解消、リベースの指示など、いくつかの操作でテキストエディタを起動します。デフォルトでは、多くの環境でVimというエディタが起動しますが、Vimは独特な操作性を持つため、慣れていない初心者の方にとっては使いにくいかもしれません。

そこで、使い慣れたエディタ（VS Code, Atom, Sublime Textなど）をGitのデフォルトエディタとして設定することをおすすめします。

なぜテキストエディタの設定が必要か

  • コミットメッセージ: git commit を実行した際に、-m オプションでメッセージを指定しない場合、または複数行のメッセージを入力する場合に、設定されたエディタが起動し、コミットメッセージを入力することになります。
  • マージ/リベース: 競合が発生した場合や、インタラクティブなリベースを行う際に、Gitは設定されたエディタを起動してユーザーに指示を求めたり、競合箇所を編集させたりします。

これらの操作をスムーズに行うためには、使い慣れたエディタを設定しておくことが重要です。

設定方法

デフォルトエディタを設定するには、core.editorという設定項目を使用します。設定するエディタの起動コマンドと、Gitがエディタの終了を待つためのオプション（多くの場合 --wait や -w）を指定します。

以下に代表的なエディタの設定例を示します。お使いのエディタに合わせてコマンドを選択してください。

Visual Studio Code (VS Code):

VS Codeをデフォルトエディタとして設定する場合。VS Codeをインストール済みで、コマンドラインから code コマンドが実行できることが前提です。（VS Codeインストール時に「Add “Open with Code” action to Windows Explorer file context menu」や「Add “Open with Code” action to Windows Explorer directory context menu」といったPATHに追加するオプションを有効にしているか、VS Codeのインストール後に手動でPATHに追加することで code コマンドが使えるようになります。）

bash
git config --global core.editor "code --wait"

--wait オプションは、エディタを閉じ、保存するまでGitが次の処理に進まないようにするために必要です。

Atom:

Atomをデフォルトエディタとして設定する場合。Atomをインストール済みで、コマンドラインから atom コマンドが実行できることが前提です。

bash
git config --global core.editor "atom --wait"

Sublime Text:

Sublime Textをデフォルトエディタとして設定する場合。Sublime Textをインストール済みで、コマンドラインから subl コマンドが実行できることが前提です。

bash
git config --global core.editor "subl -w"

-w オプションは --wait と同じ役割です。

Notepad++ (Windows):

Notepad++をデフォルトエディタとして設定する場合。インストールパスは環境によって異なる場合があります。

bash
git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

パスにスペースが含まれるため、シングルクォーテーション ' で囲む必要があります。また、オプション (-multiInst, -notabbar, -nosession, -noPlugin) は、Gitから起動した際に新しいインスタンスで開き、タブバーなどを表示しないためのものです。-wait に相当するオプションがないため、Gitの公式ドキュメントではNotepad++はあまり推奨されていませんが、簡単な編集には使えます。

Vim:

デフォルトで設定されていることが多いですが、改めて設定する場合。

bash
git config --global core.editor "vim"

Nano:

Vimより簡単な操作性のコマンドラインエディタ。

bash
git config --global core.editor "nano"

設定の確認

設定したエディタが正しく登録されたか確認するには、以下のコマンドを実行します。

bash
git config --global core.editor

設定したコマンドが表示されれば成功です。

また、実際にエディタが起動するか試す簡単な方法として、メッセージを付けずにコミットする操作をキャンセルしてみる方法があります。

  1. 適当なテキストファイルを作成します（例: test.txt）。
  2. ファイルをGitの管理対象に追加します。
    bash
    git add test.txt
  3. メッセージを付けずにコミットコマンドを実行します。
    bash
    git commit
  4. 設定したエディタが起動するはずです。エディタが起動したら、何もせずにファイルを閉じ（保存は不要です）、エディタを終了してください。
  5. Gitのコマンドラインに戻り、コミットがキャンセルされたことを確認します（通常、エディタを空のまま閉じるとコミットはキャンセルされます）。

3. 改行コードの設定 (CRLF vs LF)

改行コードの問題は、Git初心者だけでなく、経験者でもたまに頭を悩ませる問題です。OSによってテキストファイルの改行を表す文字が異なることが原因です。

  • Windows: キャリッジリターンとラインフィードの組み合わせ（CRLF, \r\n）
  • macOS (Unix由来), Linux: ラインフィードのみ（LF, \n）

Gitでバージョン管理するテキストファイルには、どちらの改行コードを使うべきでしょうか？ そして、異なるOSのユーザーが同じリポジトリを共有する場合、どのようにこの問題を扱うべきでしょうか？

なぜ改行コードの問題が発生するのか

Gitリポジトリ内でLF形式で保存されているファイルをWindows環境でクローンすると、Windows標準のテキストエディタによってはLFを正しく扱えず、改行が表示されない場合があります。逆に、WindowsでCRLF形式で作成・編集したファイルをLF形式を期待する環境（Linuxサーバーなど）にプッシュすると、想定外の改行コードが混ざってしまい、スクリプトの実行エラーなどを引き起こす可能性があります。

Gitは、この改行コードの違いを自動的に調整する機能を持っています。それが core.autocrlf という設定です。この設定により、Gitは「チェックアウト時（リポジトリからファイルを取得する際）」と「コミット時（変更をリポジトリに記録する際）」に、改行コードを自動で変換するかどうかを制御できます。

core.autocrlf の設定オプション

core.autocrlf には主に3つの設定値があります。

  1. true (Windowsユーザーに推奨):

    • チェックアウト時: リポジトリ内のLFをCRLFに変換します。
    • コミット時: 作業ディレクトリ内のCRLFをLFに変換します。
    • これにより、Windowsユーザーは自分の環境でCRLF形式のファイルとして自然に編集できますが、リポジトリ内には統一されたLF形式で保存されます。

  2. input (macOS/Linuxユーザーに推奨):

    • チェックアウト時: 変換を行いません（リポジトリ内のLFのまま）。
    • コミット時: 作業ディレクトリ内のCRLFをLFに変換します。
    • macOSやLinuxはデフォルトでLF形式を使用するため、チェックアウト時の変換は不要です。コミット時にCRLFが混入するのを防ぐために、CRLFを見つけたらLFに変換します。

  3. false (非推奨 unless you know what you’re doing):

    • チェックアウト時: 変換を行いません。
    • コミット時: 変換を行いません。
    • Gitは一切改行コードの変換を行いません。これにより、リポジトリ内にはCRLFとLFが混在する可能性があり、クロスプラットフォームでの開発では問題が発生しやすくなります。特定の理由がない限り、この設定は避けるべきです。

推奨設定

クロスプラットフォームでの開発をスムーズに進めるためには、リポジトリ内では改行コードをLFに統一する という方針が一般的です。そして、各ユーザーのOSに合わせてGitがチェックアウト/コミット時に自動変換を行うように設定します。

  • Windowsユーザー:
    bash
    git config --global core.autocrlf true

  • macOS/Linuxユーザー:
    bash
    git config --global core.autocrlf input

この設定により、WindowsユーザーはCRLFで編集し、GitがLFに変換してコミット。macOS/LinuxユーザーはLFで編集し、GitはそのままLFとしてコミット（誤ってCRLFが含まれていればLFに変換）します。そして、チェックアウト時にはWindowsユーザーにはCRLFで、macOS/LinuxユーザーにはLFでファイルが渡されます。

ただし、バイナリファイル（画像ファイル、実行可能ファイルなど）に対してこの変換が誤って適用されないように注意が必要です。Gitはファイルの内容を見てテキストファイルかどうかを判断しますが、確実を期すためには .gitattributes ファイルを使用してファイルごとの改行コードの扱いを明示的に指定するのが最善です。しかし、これは初期設定としては高度な内容なので、まずは上記の core.autocrlf の設定だけを行っておけば、多くの場合は問題なく作業できます。

.gitattributes について簡単に触れておくと、プロジェクトのルートディレクトリに .gitattributes という名前のファイルを作成し、以下のように記述することで、特定の拡張子のファイルに対して改行コードの扱いを指定できます。

“`gitattributes

全てのテキストファイルはLFで保存する（Windowsユーザー向けの設定 core.autocrlf=true と組み合わせる）

  • text=auto

特定の拡張子は常にLFで保存する

.sh text eol=lf
.py text eol=lf

バイナリファイルは改行コード変換を行わない

.jpg binary
.png binary
*.exe binary
“`

core.autocrlf の設定は、新しいリポジトリで作業を開始する前に一度行っておくのがベストです。既存のリポジトリでこの設定を変更した場合、再度ファイルをチェックアウトし直すなど、調整が必要になる場合があります。

設定の確認

設定した改行コードの扱いが正しく登録されたか確認するには、以下のコマンドを実行します。

bash
git config --global core.autocrlf

設定した値 (true または input) が表示されれば成功です。

4. 差分ツール/マージツールの設定 (diff/merge tool)

Gitでは、ファイルの変更内容の差分を確認したり（git diff）、複数のブランチの変更を統合する際に発生した競合を解消したりする際に、外部のツール（GUIツール）を利用することができます。これらのツールを設定しておくと、視覚的に差分を確認したり、競合箇所を効率的に編集したりできるようになります。

なぜ差分ツール/マージツールの設定が必要か

  • 差分ツール: git diff コマンドで表示されるテキストベースの差分は、複雑な変更の場合に見にくいことがあります。GUIの差分ツールを使うと、変更箇所が色分けされたり、サイドバイサイドで比較できたりするため、差分をより分かりやすく確認できます。
  • マージツール: 複数のブランチで同じファイルの同じ箇所に変更が加えられていた場合、「競合 (conflict)」が発生します。Gitは自動的にマージできず、ユーザーが手動で競合を解消する必要があります。GUIのマージツールは、オリジナル、自分の変更、相手の変更、そしてマージ結果のファイルなどを同時に表示し、どちらの変更を採用するか、あるいは手動で編集するかをサポートしてくれます。競合解消はGitを使う上で避けて通れない作業の一つであり、マージツールはこれを大幅に効率化してくれます。

Gitは様々な外部ツールと連携できるようになっています。よく使われるツールには、KDiff3, Meld, Beyond Compare, P4Mergeなどがあります。また、多くの統合開発環境（IDE）や高機能なテキストエディタ（VS Code, Atomなど）も、Gitの差分・マージツールとして設定・利用できます。

設定方法

差分ツールとマージツールは、それぞれ diff.tool と merge.tool の設定項目で指定します。ツールごとに設定方法が異なる場合がありますが、基本的な流れは同じです。

  1. 使用したいツールをインストールする: まず、使用したい差分/マージツールをお使いのシステムにインストールしておきます。
  2. Gitにツールを設定する: git config コマンドでツール名を指定します。
    bash
    git config --global diff.tool <toolname>
    git config --global merge.tool <toolname>
    ここで指定する <toolname> は、Gitが認識するツールのエイリアスです（例: kdiff3, meld, vscode, atomdff, sublimemerge など）。Gitが認識するツール名の一覧は、git difftool --tool-help や git mergetool --tool-help コマンドで確認できます。
  3. （必要であれば）ツールの起動コマンドを設定する: Gitがデフォルトで認識しないツールや、特別なオプションを付けて起動したい場合は、ツールの起動コマンドを別途設定する必要があります。
    bash
    git config --global mergetool.<toolname>.cmd '<command>'
    git config --global difftool.<toolname>.cmd '<command>'
    <command> には、Gitがマージ/差分実行時に呼び出すコマンドを記述します。このコマンドは、マージの場合は LOCAL, REMOTE, BASE, MERGED といった特別な変数（ファイルのパスに置換される）を受け取れる必要があります。差分の場合は LOCAL と REMOTE です。
    例：VS Codeをマージツールとして設定する場合（Gitが vscode というエイリアスを認識する場合）。
    bash
    git config --global merge.tool vscode
    git config --global mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED'
    git config --global mergetool.trustExitCode false
    mergetool.trustExitCode false は、マージツールが正常終了したかどうかを、ツールの終了コードではなく、マージ結果のファイルが変更されたかどうかで判断させる設定です。多くのツールでこの設定を推奨します。
    VS Codeを差分ツールとして設定する場合。
    bash
    git config --global diff.tool vscode
    git config --global difftool.vscode.cmd 'code --wait --diff $LOCAL $REMOTE'

設定例 (VS Codeをdiff/mergeツールにする)

VS Codeをインストール済みで、コマンドラインから code コマンドが実行できることを前提とします。

  1. 差分ツールの設定:
    bash
    git config --global diff.tool vscode
    git config --global difftool.vscode.cmd 'code --wait --diff $LOCAL $REMOTE'
  2. マージツールの設定:
    bash
    git config --global merge.tool vscode
    git config --global mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED'
    git config --global mergetool.trustExitCode false

これらの設定を行うと、git difftool コマンドや、マージ競合が発生した際に git mergetool コマンドを実行することで、設定したVS Codeが起動し、GUIで差分確認や競合解消を行えるようになります。

設定の確認

設定した差分ツールとマージツールが正しく登録されたか確認するには、以下のコマンドを実行します。

bash
git config --global diff.tool
git config --global merge.tool

設定したツール名（例: vscode）が表示されれば成功です。

5. エイリアスの設定 (alias)

Gitコマンドはしばしば長くなったり、オプションが多くなったりします。よく使うコマンドに短い「エイリアス（別名）」を設定することで、コマンド入力を効率化できます。これは必須の設定ではありませんが、Gitを快適に使うための非常に便利な機能です。

なぜエイリアスの設定が便利か

例えば、現在のリポジトリの状態を確認するコマンドは git status です。これを毎回入力するのは少し手間です。もし st というエイリアスを設定すれば、git st と入力するだけで git status を実行できるようになります。

設定方法

エイリアスを設定するには、alias.<エイリアス名> という設定項目を使用します。

bash
git config --global alias.<エイリアス名> '<元のコマンド>'

<元のコマンド> の部分には、エイリアスで実行したいGitコマンド（git の後の部分）を記述します。

よく使われるエイリアスの例

以下は、多くのGitユーザーが設定している便利なエイリアスの例です。好みに応じて設定してみてください。

  • st for status: ステータス確認を短く。
    bash
    git config --global alias.st status
  • co for checkout: ブランチの切り替えやファイルの復元を短く。
    bash
    git config --global alias.co checkout
  • br for branch: ブランチ一覧の表示や新規作成を短く。
    bash
    git config --global alias.br branch
  • ci for commit: コミットを短く。
    bash
    git config --global alias.ci commit
  • di for diff: 差分表示を短く。
    bash
    git config --global alias.di diff
  • ad for add: ファイルの追加を短く。
    bash
    git config --global alias.ad add
  • lg for log (graphical log): コミット履歴を分かりやすくグラフ表示。これは少し長いですが、非常に便利です。
    bash
    git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"
    このエイリアスを設定すると、git lg で以下のような整形されたグラフ付きのログが表示されます。
    “`

    • c4a3a0b (HEAD -> main) Fix typo in README (2 hours ago)
    • 8b1b5a1 Add feature X (3 hours ago)
      | * 7d2c1b4 (feature/y) Implement Y (1 day ago)
      |/
    • a1f2b3c Initial commit (2 days ago)
      “`
  • unstage for reset HEAD: git add でステージングしたファイルを取り消す。
    bash
    git config --global alias.unstage 'reset HEAD --'
    使い方は git unstage <ファイル名>
  • last for log -1 HEAD: 最新のコミットを確認する。
    bash
    git config --global alias.last 'log -1 HEAD'

これらのエイリアスを設定することで、Gitの操作がより快適になるでしょう。

設定の確認

設定したエイリアスの一覧を確認するには、以下のコマンドを実行します。

bash
git config --global --list

または、特定のエイリアスの設定を確認するには、以下のコマンドを実行します。

bash
git config --global alias.<エイリアス名>

6. その他の推奨設定（任意）

必須ではありませんが、Gitの使いやすさを向上させるための便利な設定がいくつかあります。

カラフルな出力 (color.ui)

Gitのコマンド出力（status, diff, log など）を色分けすることで、情報が視覚的に分かりやすくなります。

  • 設定方法:
    bash
    git config --global color.ui auto
    auto を設定すると、ターミナルが色をサポートしている場合に色付きで表示されます。always にすると、常に色付きで表示されますが、ファイルにリダイレクトするなど、意図しない場面でもエスケープシーケンスが出力される可能性があるため、auto が推奨されます。

プッシュ時のデフォルト挙動 (push.default)

git push コマンドを実行する際に、ローカルのどのブランチをリモートのどのブランチにプッシュするかを省略した場合のデフォルトの挙動を設定します。この設定をしていないと、Gitから警告が表示されることがあります。

いくつかのオプションがありますが、simple が最も推奨される設定です。

  • simple (推奨): 現在のブランチと同じ名前のリモートブランチが存在する場合に、そのブランチにプッシュします。リモートブランチが存在しない場合や、現在のブランチと名前が異なる場合はエラーになります。これにより、意図しないブランチにプッシュしてしまうミスを防げます。
  • upstream: 現在のブランチが追跡している（トラッキング設定されている）リモートブランチにプッシュします。追跡ブランチが設定されていない場合はエラーになります。
  • current: 現在のブランチと同じ名前のリモートブランチにプッシュします。リモートブランチが存在しない場合は新規作成されます。

  • matching: ローカルとリモートで同じ名前の全てのブランチをプッシュします。非推奨。

  • 設定方法:
    bash
    git config --global push.default simple

プル時のデフォルト挙動 (pull.rebase)

git pull コマンドは、デフォルトではリモートの変更を取り込んだ後、ローカルの変更とマージします。しかし、代わりにリベースを行うように設定することもできます。リベースは、ローカルの変更をリモートの変更の上に「移し替える」ことで、コミット履歴を一直線に保つ方法です。

  • false (デフォルト): git pull はフェッチ後、マージを実行します。履歴にマージコミットが残ります。
  • true: git pull はフェッチ後、リベースを実行します。履歴が一直線になり、よりきれいに保たれますが、リベース中の競合解消はマージよりも少し複雑に感じられる場合があります。

どちらが良いかは開発チームの方針や個人の好みによります。初心者の方はデフォルトの false のままでも問題ありません。リベースに慣れてきたら true を試してみるのも良いでしょう。

  • 設定方法 (リベースをデフォルトにする場合):
    bash
    git config --global pull.rebase true

7. 設定内容の確認と管理

これまでに設定した内容を確認し、必要に応じて変更・削除する方法を知っておきましょう。

全ての設定内容を確認する

ユーザー全体の全ての設定は、以下のコマンドで確認できます。

bash
git config --global --list

システム全体、ユーザー全体、現在のリポジトリ個別の全ての設定（Gitが最終的に適用する設定）を確認する場合は、以下のコマンドを使います。

bash
git config --list

このリストでは、同じ設定項目が複数のスコープ（system, global, local）で表示されることがありますが、最もローカルなスコープ（local > global > system の順）の設定が優先されます。

設定ファイル

git config コマンドで設定した内容は、プレーンテキストの設定ファイルに保存されます。これらのファイルを直接編集することも可能ですが、コマンドを使う方がタイプミスなどを防げるため推奨されます。

  • ユーザー全体の設定ファイル:

    • macOS/Linux: ~/.gitconfig または ~/.config/git/config
    • Windows: C:\Users\<ユーザー名>\.gitconfig または %USERPROFILE%\.gitconfig
    • これらのファイルは、お使いのテキストエディタで開くことができます。例：
      bash
      # macOS/Linux
      code ~/.gitconfig
      # Windows (VS Codeの場合)
      code %USERPROFILE%\.gitconfig
    • ファイルの中身は、INIファイルのような形式で記述されています。
      ini
      [user]
      name = Taro Yamada
      email = [email protected]
      [core]
      editor = code --wait
      autocrlf = true
      [alias]
      st = status
      ci = commit
      lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
    • 直接編集した場合でも、git config --list コマンドで内容が反映されているか確認できます。

  • リポジトリ個別の設定ファイル:

    • 各リポジトリのルートディレクトリにある .git ディレクトリ内の config ファイルです。
    • 例：現在のリポジトリの設定ファイルを開く
      bash
      code .git/config
    • このファイルに設定を追加すると、そのリポジトリ内でのみ有効な設定になります。これは、特定のプロジェクトでだけ異なるユーザー名を使いたい場合や、特定のプロジェクトだけ改行コードの扱いを変えたい場合などに利用できます。

設定の変更・削除

設定値を変更するには、同じ git config --global コマンドで新しい値を指定して上書きします。

例：ユーザー名を変更する
bash
git config --global user.name "Ichiro Suzuki"

設定を削除したい場合は、--unset オプションを使用します。

例：設定したエイリアス st を削除する
bash
git config --global --unset alias.st

改行コードの設定 core.autocrlf を削除してデフォルトに戻す（Gitのインストール時の設定に戻る）
bash
git config --global --unset core.autocrlf

最初のローカルリポジトリ作成とコミット（簡単な流れ）

初期設定が完了したところで、設定が正しく機能するか確認するため、簡単なローカルリポジトリを作成して最初のコミットをしてみましょう。

  1. プロジェクト用のディレクトリを作成し、移動する:
    任意の場所に、新しいプロジェクト用のディレクトリを作成します。
    bash
    # ディレクトリを作成
    mkdir my-first-git-repo
    # 作成したディレクトリに移動
    cd my-first-git-repo

  2. Gitリポジトリとして初期化する:
    現在のディレクトリをGitで管理するためのリポジトリとして初期化します。これにより、ディレクトリ内に .git という隠しディレクトリが作成され、Gitがバージョン管理を開始する準備が整います。
    bash
    git init
    成功すると Initialized empty Git repository in /path/to/my-first-git-repo/.git/ のようなメッセージが表示されます。

  3. ファイルをいくつか作成する:
    管理対象としたいファイルをいくつか作成します。例えば、簡単なREADMEファイルなど。
    “`bash
    # macOS/Linux
    echo “# My First Git Repository” > README.md
    echo “This is a test file.” > test.txt

    Windows (PowerShell)

    “## My First Git Repository” | Out-File -Path README.md -Encoding utf8
    “This is a test file.” | Out-File -Path test.txt -Encoding utf8

    Windows (コマンドプロンプト)

    echo # My First Git Repository > README.md
    echo This is a test file. > test.txt
    “`

  4. ファイルのステータスを確認する:
    どのファイルがGitに認識されているか、どのような状態かを確認します。
    bash
    git status
    ここでは、作成した README.md と test.txt が「Untracked files」（追跡されていないファイル）として表示されるはずです。これは、Gitはファイルの存在を知っているが、まだバージョン管理の対象として追跡していない状態です。

  5. ファイルをステージングエリアに追加する:
    Gitにこれらのファイルをバージョン管理の対象に含めることを指示し、次のコミットに含める準備をします。この一時的な領域を「ステージングエリア（またはインデックス）」と呼びます。
    “`bash
    # 個別にファイルを追加
    git add README.md
    git add test.txt

    または、全ての変更されたファイルをまとめて追加 (非推奨の場合もあるが、初回コミットなら問題なし)

    git add .
    ``git status` を再度実行すると、ファイルが「Changes to be committed」（コミットされる変更）のリストに移っていることが確認できます。

  6. 変更をコミットする:
    ステージングエリアに追加された変更内容を、一つのまとまりとしてリポジトリに記録します。この際にコミットメッセージを記述します。コミットメッセージは、そのコミットでどのような変更を行ったのかを簡潔に説明するものです。
    bash
    git commit -m "Initial commit: Add README and test file"
    -m オプションを使うと、コマンドラインで直接メッセージを記述できます。複数行のメッセージを書きたい場合や、より詳細なメッセージを残したい場合は、-m オプションを付けずに git commit だけを実行します。この場合、設定したデフォルトエディタが起動しますので、そこでメッセージを記述して保存・終了します。

    コミットに成功すると、コミットハッシュ（一意の識別子）、ブランチ名、コミットメッセージなどが表示されます。ここで、初期設定で登録したあなたのユーザー名とメールアドレスが、このコミットの作者として記録されていることを確認できます。

  7. コミット履歴を確認する:
    これまでのコミット履歴を確認します。
    bash
    git log
    または、エイリアスを設定していれば git lg など。
    最初のコミットが表示され、Author欄に設定したユーザー名とメールアドレスが表示されているはずです。

これで、Gitの初期設定が正しく行われ、ローカルでのバージョン管理を開始できる状態になりました。

リモートリポジトリとの連携（GitHubなど）

Gitの大きな利点の一つは、リモートリポジトリとの連携による共同作業やバックアップ機能です。GitHub, GitLab, Bitbucketなどのサービスを利用して、ローカルリポジトリのクローンをインターネット上に保存したり、他の人と共有したりできます。

リモートリポジトリと連携するためには、通常、認証設定が必要です。Gitはリモートリポジトリへのアクセスに、主にSSHまたはHTTPSという2つの方法をサポートしています。

認証方法: SSH vs HTTPS

  • HTTPS:
    • メリット: 設定が比較的簡単で、ファイアウォールを越えやすい。Webブラウザでアクセスする際と同じプロトコルを使うため、特別なポートを開ける必要がないことが多い。
    • デメリット: アクセスするたびにユーザー名とパスワード（またはパーソナルアクセストークン）の入力を求められる可能性がある（Credential Managerを使わない場合）。大規模なファイル転送でパフォーマンスが劣る場合がある。
  • SSH:
    • メリット: 公開鍵認証方式を使うため、一度設定すればパスワード入力なしで安全にアクセスできる。大規模なファイル転送でパフォーマンスが良い場合がある。
    • デメリット: SSHキーペアの生成と公開鍵のリモートサービスへの登録が必要。SSHポートがファイアウォールで制限されている場合がある。

長期的にGitを使うことを考えると、SSHによる公開鍵認証 が推奨されます。一度設定すれば、その後の操作がスムーズになるからです。しかし、初心者の方にはHTTPSの方が手軽かもしれません。ここでは両方の認証方法について簡単に触れ、特に推奨されるSSHの設定方法を解説します。

SSHキーの設定 (推奨)

SSH公開鍵認証では、「秘密鍵」と「公開鍵」のペアを作成します。秘密鍵はあなたのコンピュータに厳重に保管し、誰にも公開してはいけません。公開鍵はリモートリポジトリを提供するサービス（GitHubなど）に登録します。

リモートにアクセスする際、Gitクライアントは秘密鍵を使って接続を試みます。リモートサービスは、送られてきた情報と登録されている公開鍵を照合し、一致すれば認証成功と判断します。これにより、パスワードをネットワーク上に流すことなく安全に認証が行えます。

SSHキーペアの生成

まだSSHキーペアを持っていない場合は、以下の手順で生成します。

  1. ターミナルまたはGit Bashを開く:
    Windowsの場合はGit Bash、macOS/Linuxの場合は通常のターミナルを開きます。

  2. キー生成コマンドを実行する:
    以下のコマンドを実行します。メールアドレスの部分は、GitHubなどに登録しているメールアドレスを指定するのが一般的です。
    bash
    ssh-keygen -t ed25519 -C "[email protected]"
    （-t ed25519 は比較的新しい、より安全な暗号方式です。互換性のために -t rsa -b 4096 を使う場合もありますが、特段の理由がなければed25519で良いでしょう。）

  3. 保存場所とファイル名の指定:
    「Enter a file in which to save the key (…):」と表示されます。特にこだわりがなければ、デフォルトの場所（~/.ssh/id_ed25519 など）で良いので、何も入力せずにEnterキーを押します。

  4. パスフレーズの設定:
    「Enter passphrase (empty for no passphrase):」と表示されます。ここでパスフレーズ（秘密鍵を保護するためのパスワード）を設定することを強く推奨します。パスフレーズを設定すると、秘密鍵を使うたびに（通常は最初のアクセス時やコンピュータ起動時などに一度）パスフレーズの入力が必要になりますが、秘密鍵が漏洩した場合のリスクを軽減できます。パスフレーズを設定しない場合は何も入力せずにEnterを2回押します。セキュリティを高めるため、パスフレーズを設定し、後述のSSHエージェントを活用するのが良いでしょう。パスフレーズを入力した場合も、確認のためにもう一度入力します。

    Enter passphrase (empty for no passphrase): # ここでパスフレーズを入力（入力内容は表示されません）
    Enter same passphrase again: # 確認のため再度入力

  5. キーペア生成完了:
    以下のような出力が表示され、秘密鍵 (id_ed25519) と公開鍵 (id_ed25519.pub) が指定したディレクトリ（デフォルトでは ~/.ssh/）に生成されます。

    Your identification has been saved in /home/youruser/.ssh/id_ed25519
    Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
    The key fingerprint is:
    SHA256:... [email protected]
    The key's randomart image is:
    +--[ED25519 256]--+
    | ... |
    +----[SHA256]-----+

公開鍵をGitHubなどに登録する

生成された公開鍵 (id_ed25519.pub ファイルの中身) を、利用したいリモートリポジトリサービス（GitHub, GitLab, Bitbucketなど）に登録します。

  1. 公開鍵ファイルの内容をコピーする:
    公開鍵ファイル (~/.ssh/id_ed25519.pub) をテキストエディタで開くか、以下のコマンドで内容を表示し、全てコピーします。
    “`bash
    # macOS/Linux
    cat ~/.ssh/id_ed25519.pub

    Windows (Git Bash)

    cat ~/.ssh/id_ed25519.pub

    Windows (PowerShell)

    Get-Content $HOME/.ssh/id_ed25519.pub
    ``
    出力されるのは    ssh-ed25519 [長い文字列] [email protected]` のような文字列です。この文字列全体をコピーします。

  2. GitHubに公開鍵を登録する:

    • GitHubにログインします。
    • アカウント設定を開きます（右上アイコン > Settings）。
    • 左側のメニューから「SSH and GPG keys」を選択します。
    • 「New SSH key」または「Add SSH key」ボタンをクリックします。
    • Title（キーの名前）に、このキーを識別しやすい名前（例: 「My Laptop」、「Work Computer」など）を入力します。
    • Key Typeは「Authentication Key」を選択します。
    • 「Key」のテキストエリアに、先ほどコピーした公開鍵の内容を貼り付けます。
    • 「Add SSH key」ボタンをクリックして保存します。GitHubのパスワード入力を求められる場合があります。

これで、この公開鍵を登録したサービス（GitHub）に対して、対応する秘密鍵を持つあなたのコンピュータからSSHでアクセスできるようになります。

SSHエージェントの使用

SSHキーにパスフレーズを設定した場合、通常は秘密鍵を使用するたびにパスフレーズの入力が必要です。これを省略するために、SSHエージェントを利用します。SSHエージェントは、秘密鍵とパスフレーズをメモリに保持しておき、必要に応じて認証を行ってくれます。コンピュータの起動時や、エージェントに秘密鍵を登録する最初の1回だけパスフレーズを入力すれば、その後は入力が不要になります。

SSHエージェントの起動方法はOSや環境によって異なります。

  • Git Bash (Windows): Git Bashは起動時に自動的にSSHエージェントを起動し、ssh-add コマンドで秘密鍵を追加するように促される場合があります。指示に従うか、以下のコマンドで秘密鍵を追加できます。
    bash
    ssh-add ~/.ssh/id_ed25519
    （秘密鍵のファイル名は生成時に指定したものに合わせてください）。パスフレーズの入力を求められたら入力します。
  • macOS: macOSのログインキーチェーンがSSHエージェントの役割を果たします。SSHキーを初めて使用する際にパスフレーズを求められ、「Remember password in my keychain」を選択すると、以降は入力が不要になります。
  • Linux: ディストリビューションによって設定方法が異なりますが、多くのデスクトップ環境ではセッション開始時にSSHエージェントが起動します。ssh-add コマンドで秘密鍵を追加します。

SSH接続のテスト

SSHキーとリモートサービスへの登録が正しく行われたか確認するために、以下のコマンドを実行します。

  • GitHub:
    bash
    ssh -T [email protected]
    初回接続時にはホストの真正性についての質問が表示される場合があります（Are you sure you want to continue connecting (yes/no)?）。yes と入力してEnterを押します。
    認証に成功すると、「Hi [ユーザー名]! You’ve successfully authenticated, but GitHub does not provide shell access.」のようなメッセージが表示されます。これは、SSH接続による認証は成功したが、SSHでサーバーにログインする権限はない（Gitの操作のみ許可されている）という意味です。

HTTPS認証（Credential Manager）

HTTPSでリモートリポジトリにアクセスする場合、通常はユーザー名とパスワードが必要になります。GitHubなどのサービスでは、セキュリティ上の理由からパスワードの代わりに「パーソナルアクセストークン（PAT）」の使用が推奨されています。PATは、GitHubの設定画面で生成できる、あなたのアカウントに対するアクセス権限を持つ使い捨て可能なパスワードのようなものです。

しかし、PATやパスワードを操作のたびに入力するのは非常に手間です。そこで、Git Credential Managerのような「認証情報を保存・管理してくれるツール」を利用します。これは、Git for Windowsのインストール時に推奨されていたオプションです。

  • Git Credential Manager (Windows): Windows資格情報マネージャーを利用して、認証情報を安全に暗号化して保存します。一度認証に成功すれば、以降は資格情報マネージャーが自動的にユーザー名とパスワード（またはPAT）を提供してくれるため、入力が不要になります。Git for Windowsを推奨設定でインストールしていれば、自動的に有効になっています。
  • macOS Keychain access: macOSでは、キーチェーンアクセスが認証情報を管理できます。Gitの操作時にパスワードを求められた際に「Remember password in my keychain」を選択することで、次回以降の入力を省略できます。
  • Git Credential Manager Core (macOS/Linux): Git Credential Manager Core は、Windows版だけでなく、macOSやLinuxでも利用できる認証情報マネージャーです。Homebrewなどでインストールし、Gitに設定することで、各OSの認証情報管理機能や専用の安全なストアを使って認証情報を管理できます。

これらの認証情報マネージャーを利用することで、HTTPSでのアクセスでもSSHと同様にスムーズな操作が可能になります。ただし、HTTPS認証では、二要素認証が有効になっている場合にPATが必須になるなど、サービスごとの追加設定が必要になる場合があります。

初心者の方が手軽に始めるならHTTPS + Credential Manager、長期的にスムーズかつ安全に利用するならSSH公開鍵認証がおすすめです。

リモートリポジトリの追加とプッシュ

最後に、ローカルで作成したリポジトリをリモートリポジトリ（例えばGitHubに作成した空のリポジトリ）と連携させる方法の基本を説明します。

  1. GitHubなどのサービスで空のリポジトリを作成する:
    GitHubにログインし、「New repository」などで新しいリポジトリを作成します。この際、READMEファイルや.gitignore、ライセンスファイルなどは追加せず、完全に空のリポジトリとして作成してください。リポジトリが作成されると、Gitで連携するためのコマンド例が表示されます。表示されるSSHまたはHTTPSのURL（例: [email protected]:your_username/my-first-git-repo.git または https://github.com/your_username/my-first-git-repo.git）を控えておきます。

  2. ローカルリポジトリにリモートを追加する:
    ローカルで作成したリポジトリのディレクトリに移動し、以下のコマンドを実行します。
    bash
    git remote add origin <リモートリポジトリのURL>

    • origin: リモートリポジトリにつける慣習的な名前です。通常は origin を使います。
    • <リモートリポジトリのURL>: GitHubで控えたURLに置き換えます。SSHを使うならSSHのURL、HTTPSを使うならHTTPSのURLを指定します。
      例 (SSHの場合):
      bash
      git remote add origin [email protected]:your_username/my-first-git-repo.git
      例 (HTTPSの場合):
      bash
      git remote add origin https://github.com/your_username/my-first-git-repo.git

  3. リモートが正しく追加されたか確認する:
    bash
    git remote -v
    設定したリモート名（origin）とURLが表示されれば成功です。

  4. ローカルのコミットをリモートにプッシュする:
    ローカルのブランチ（初回であれば通常 main または master）の変更履歴をリモートリポジトリに送信します。
    bash
    git push -u origin main

    • -u: このローカルブランチ（main）とリモートの origin リポジトリの main ブランチを関連付け（トラッキング設定）します。次回以降は git push だけでプッシュできるようになります。初回のみ -u オプションを付けるのが一般的です。
    • origin: プッシュ先のリモートリポジトリ名。
    • main: プッシュするローカルブランチ名（Gitの初期設定でmainにしていればmain、デフォルトのままならmasterの場合があります）。

    SSHを使用している場合は、パスフレーズの入力を求められる場合があります（SSHエージェントを使用していれば不要な場合もあります）。HTTPSを使用している場合は、ユーザー名とパスワード/PATの入力を求められる場合があります（Credential Managerを使用していれば不要な場合もあります）。

    プッシュが成功すると、リモートリポジトリ（GitHubのWebページなど）にアクセスして、ローカルでコミットしたファイルや履歴が表示されていることが確認できます。

これで、ローカルリポジトリとリモートリポジトリの連携、および最初のプッシュが完了しました。

トラブルシューティングとよくある質問

設定コマンドを実行しても何も表示されない/エラーになる

  • git config --global user.name "..." などのコマンドを実行しても何も表示されないのは正常です。コマンドが成功した場合、通常は特にメッセージは表示されません。
  • もしエラーメッセージが表示される場合は、コマンドの入力ミスや、Gitが正しくインストールされていない（git コマンド自体が認識されない）などが考えられます。コマンドをよく確認するか、Gitのインストール状況を確認してください。

コミットしてもユーザー情報が表示されない

  • git config --global user.name と git config --global user.email で設定したユーザー情報は、その設定を行った後に作成されたコミットから反映されます。設定を行う前に作成されたコミットのユーザー情報は変更されません。
  • リポジトリ個別の設定（.git/config）で異なるユーザー情報が設定されている場合、そちらが優先されます。git config --list コマンドを実行して、現在のリポジトリでどのユーザー情報が適用されているか確認してください。もしリポジトリ個別の設定が意図せず存在する場合は、そのリポジトリの .git/config ファイルを編集・削除するか、リポジトリ内で git config user.name --unset などと --local オプション付きで設定を削除してください（--local はデフォルトなので省略可能）。

改行コードの問題が解決しない

  • core.autocrlf の設定は、設定を行った後にチェックアウトされたファイルや、新しく編集・作成されたファイルに対して効果を発揮します。設定変更前に既にローカルで編集していたファイルには、自動変換が適用されていない場合があります。
  • 改行コードの問題を根本的に解決するには、プロジェクト全体で .gitattributes ファイルを使って改行コードの扱いを明示的に指定するのが最も確実です。特に複数のOSユーザーが共同で開発する場合に重要になります。
  • Windowsで core.autocrlf true を設定しているにも関わらず改行がLFのまま表示される場合、お使いのテキストエディタがLFを正しく扱えていない可能性があります。LFを正しく扱えるエディタ（VS Code, Sublime Text, Atom, Notepad++など）を使用することを推奨します。

リモートリポジトリにプッシュできない（認証エラー）

  • git push の際に認証エラーが発生する場合、リモートリポジトリへのアクセス権限がないか、認証設定が間違っている可能性があります。
  • SSHの場合:
    • SSHキーペアが正しく生成されているか (~/.ssh/id_ed25519 と ~/.ssh/id_ed25519.pub が存在するか)。
    • 公開鍵 (id_ed25519.pub の内容) がリモートサービス（GitHubなど）に正しく登録されているか。
    • 秘密鍵にパスフレーズを設定した場合、SSHエージェントが正しく設定されているか、またはパスフレーズを正しく入力しているか。
    • ssh -T [email protected] などでSSH接続のテストが成功するか確認してください。
  • HTTPSの場合:
    • ユーザー名とパスワード（またはPAT）を正しく入力しているか。
    • GitHubなどで二要素認証が有効になっている場合、パスワード認証は使えず、PATが必須になります。PATを生成し、パスワードの代わりに入力するか、Credential Managerに登録してください。
    • Credential Managerが正しく機能しているか。Windows資格情報マネージャーなどに認証情報が登録されているか確認してください。
  • ローカルリポジトリに追加したリモートリポジトリのURLが正しいか（SSHとHTTPSのURLを間違えていないかなど）、git remote -v で確認してください。

.gitconfig ファイルを直接編集しても良いか？

  • はい、.gitconfig ファイルはプレーンテキストファイルなので、テキストエディタで直接編集しても構いません。git config コマンドは、このファイルを編集するためのツールです。
  • ただし、タイプミスやフォーマットの間違い（特に複雑なエイリアスなど）があるとGitが設定を正しく読み込めなくなる可能性があります。自信がない場合は git config コマンドを使う方が安全です。
  • エイリアスなど、長いコマンドを記述する場合は、.gitconfig ファイルを直接編集する方が便利な場合もあります。変更後は git config --list などで設定が正しく反映されているか確認しましょう。

まとめ

この記事では、Gitを使い始めるにあたって必要な初期設定について、インストールからユーザー情報、エディタ、改行コード、認証設定、そして便利なエイリアス設定まで、初心者向けに詳しく解説しました。

Gitの初期設定は、一度行えば、その後のあなたのGitを使った開発作業をずっと快適にしてくれる重要なステップです。特に、

  • user.name と user.email: あなたのコミットを識別するために必須です。
  • core.editor: コミットメッセージなどの入力をスムーズに行うために重要です。
  • core.autocrlf: 異なるOS間での開発で改行コードの問題を防ぐために必要です。
  • SSHキーまたはCredential Manager: リモートリポジトリへのアクセスをパスワード入力なしでスムーズにするために有効です。

これらの設定をあなたの環境や好みに合わせて行うことで、Gitの強力なバージョン管理機能を最大限に活用するための準備が整いました。

Gitの学習はこれで終わりではありません。初期設定はあくまで第一歩です。今後は、ブランチの作成・切り替え、変更の追跡、過去の状態への復元、チームメンバーとの共同作業、競合の解消など、Gitの様々な機能を学び、実践していくことになります。

Gitの公式ドキュメントや、インターネット上の多くのチュートリアル、書籍などを活用して、継続的に学習を進めていきましょう。最初は難しく感じるかもしれませんが、使っていくうちに必ず慣れてきます。

この記事が、あなたのGitを使った開発の旅の良いスタート地点となることを願っています。Gitを使いこなして、より効率的で安全な開発ライフを送りましょう！

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール