GitHub（ギットハブ）の 使い方は？ インストールから基本操作まで初心者向けに解説！
GitやGitHubという言葉を聞いたことがあるけれど、詳しくはわからない、使い始めてみたけれど、わかりにくい、よくわからないまま使っている、という人も多いのではないでしょうか。
Gitはプログラムのソースコードを扱う仕事で、チーム開発する際の必須スキルです。
この記事では、GitとGitHubについてわかりやすく解説していますので、ぜひご覧ください。
Contents
Gitとは
Linuxの創始者リーナス・トーバルズ氏が開発した、ファイルのバージョンなどを管理するためのシステムです。
Gitは、ソースコードの更新履歴を時系列にそって記憶できます。そのため、複数の差分ファイルができることもなく、1つのファイルで管理できます。
常に最新のファイルとなっているため、どのファイルが最新ファイルかわからなくなる、といった問題は発生しません。
また、時系列にそってソースコードが記憶されているため、最新ファイルにバグが発生した際にも、バグが発生する前の状態に戻すことも可能です。
Gitはチーム開発時に効果を発揮します。チーム開発をおこなっていると、同時に複数人が作業することもあります。その際、うっかり他の人の書いたコードを上書きしてしまうことがあるかもしれません。Gitは誰が編集したか記憶しているため、万一他の人と編集が重なり、気付かずにデータを更新しようとした際も、先に更新されていれば、警告が表示されます。
このように、Gitを使用することで、チーム開発をスムーズにおこなうことができます。
GitHubとは
GitHub社の運営するサービスで、サーバーを借りることで、チーム全体でソースコードを共有し、編集が可能になります。
また、SNS機能なども備わっており、GitHub1つで開発を完結できる機能が備わっています。
Gitがバージョン管理するためのツールだとすれば、GitHubはそれをチーム全体で共有し、使用するためのプラットフォームです。
GitHubの用語解説
GitHubを使ううえで必須の用語を解説します。
ローカルリポジトリ/リモートリポジトリ
リポジトリという言葉は、あまり聞いたことがないかもしれませんが、GitHub特有の用語で、Gitのデータなどを保存する場所を意味します。
例えば、自分が使っているコンピューター内にあるデータなどであれば、HDD（ハードディスク）やSSD（ソリッド・ステート・ドライブ）に保存されます。クラウドサービスを利用していれば、オンライン上に保存することもあるでしょう。
それと同じように、GitHubでは、自分のパソコンとサーバーの両方にデータなどを保存しておくことができ、自分のパソコン内にあるデータ保存場所を「ローカルリポジトリ」、GitHubのサーバー上にあるデータ保存場所を「リモートリポジトリ」といいます。
コミットとプッシュ
ローカルリポジトリとは、自分のパソコン内にあるデータ保存場所、と説明しましたが、GitHubでは保存が自動的にはおこなわれません。必ず保存前に「コミット」という操作をおこないます。
いまいちイメージをつかみにくいと思いますので、流れのなかで説明します。
まず自分のパソコンでファイルなどを編集します。ちなみに、パソコンの作業環境のことを「ワークツリー」といいます。ワークツリーで編集したデータなどをリポジトリへ保存する際にコミットをおこないます。コミットはgit commitコマンドでおこない、その際、変更内容の説明（メッセージ）も入力します。
・コミット（エディタでメッセージを入力）
|
git commit |
・メッセージ付きのコミット
|
git commit -m “メッセージ” |
「プッシュ」はローカルリポジトリでコミットしたデータなどを、リモートリポジトリにアップロードし、保存する際におこなう依頼です。
チーム開発など、作業者が複数いる場合、各々が開発したデータなどをリモートリポジトリにどんどん保存していくと、予期せぬバグが発生したり、その際に何が原因になっているのかわからなくなったりします。そういったことがないように、保存前に、チームメンバーなどにソースコードを確認して貰い、保存依頼をします。それをプッシュといいます。
ブランチ
コミットがおこなわれると、Git上に履歴がラベリングされます。ラベリングされたコミットは通常一本道ですが、Gitはこれを分岐させることができます。この機能をブランチといいます。
例えば、Aという機能を開発している途中に、Bという機能の追加依頼が来たとします。そのどちらも開発しなければならない場合に、このブランチを使います。すると、ラベリングされたコミットはAを開発している履歴と、Bを開発している履歴に分岐するというわけです。ちなみに、このように機能追加時に新しく分岐したブランチを「featureブランチ」といいます。
分岐開発するメリットは、作りかけの機能の影響を受けずに、双方の開発をおこなえることです。
masterブランチ
masterブランチとは、Gitリポジトリで最初に作成されるデフォルトのブランチです。
デフォルトブランチは、プロジェクトにおける「本番環境に反映される正式なコード」を管理する中心的な役割を担います。開発者は通常、デフォルトブランチから新しい機能開発用のブランチを分岐させ、開発が完了したらデフォルトブランチにマージして統合します。リポジトリをクローンした際に自動的にチェックアウトされるのもこのデフォルトブランチです。
2020年以降、GitHubをはじめとする多くのGitホスティングサービスでは、デフォルトブランチの名称を「master」から「main」に変更する動きが広がりました。変更の背景には、技術業界全体で多様性と包括性を重視する流れがあります。現在、GitHubで新規作成されるリポジトリのデフォルトブランチ名は「main」となっています。
master/mainブランチは、いつでも本番環境へリリース可能な状態を保ちます。
マージ
分岐して機能追加や、修正などをおこなっていた内容を統合したい際におこないます。これをおこなうことで、ブランチによって分岐したソースコードを一方に取り込むことができます。その際、まれにコンフリクトという状態になることがあります。統合した内容がお互いに干渉していて、Gitがどちらが正しいか判断できない箇所があったことを示しています。この状態になった際は、コンフリクトの解消が必要です。なお、コンフリクトの解消は、Gitにより確認を求められた目印の記号を削除したうえで、正しいソースコードを入力します。
クローン
リモートリポジトリにすでにあるリポジトリを、ローカルリポジトリに複製することです。例えば、開発の途中から参画した際などに必要となります。
git cloneとコマンドし、該当リモートレポジトリのURLを指定します。
プルリクエスト
GitHubに備わっている機能です。プッシュで依頼された内容を確認したり、コードレビューしたりできます。
例えば、チーム開発であれば、作業者はチームメンバーなどからこの承認を得ることで、リモートリポジトリに編集内容を保存してもらえます。
なお、最終的に承認された内容をリモートリポジトリからローカルリポジトリに反映することをプルと言います。
インデックス
ワークツリーとリポジトリの間にあるデータ記憶領域で、ステージともいいます。
作業の流れでみると、ワークツリーで作業した内容を、一度インデックスに登録してから、リポジトリにプッシュし、プルリクエストをする、という流れです。
ちなみに、ワークツリーからインデックスに登録することを「add」といいます。
一見すると、インデックスを介さずに、プッシュすればよいのではないかと思うかもしれません。
たしかに、作業内容が少なければ、そうした運用も可能かもしれません。ですが、作業内容が増えると、プルリクエストで確認して貰う内容が多岐にわたってしまいます。
そのため、特定の開発内容ごとにプルリクエストがおこなえるように、インデックスにいったん保存し、適宜プルリクエストできる仕組みが用意されています。
GitHubの基本的な使い方6ステップ
本記事ではWindowsでのGitHubの設定・利用方法を解説します。
GitHubの使い方について実際にみていきましょう。
1.Gitをインストール
まずは公式サイトにアクセスし、Gitをダウンロードします。
下画像の右下にあるモニター画像から、赤丸部分を押下します。
次のページで自身の環境に合ったインストーラーを押下すると、ダウンロードが始まります。
ここでは、赤枠のGit for Windows/x64 Setupをダウンロードします。
ダウンロード完了後、インストーラーをダブルクリックし、インストールをおこないます。
- ライセンスへの同意
「GNU General Public License」は、フリーソフトウェアライセンスの内容が書かれています。内容を確認し、「Next」を押下します。
- ディレクトリの選択
「Select Destination Location」ではGitをインストールするディレクトリを選びます。そのまま「Next」を押下していただいて問題ありません。
- インストールの設定
「Select Components」では、インストール時の設定をここでおこなえます。チェックをいれた項目が、反映されます。以下、簡単に内容をみていきます。
|
選択肢 |
説明 |
|
「Additional Icon」 |
デスクトップにGitのショートカットアイコンを追加するかしないか設定できます。 |
|
「Git Bash Here」 「Git GUI Here」 |
それぞれエクスプローラーで表示できる右クリックメニューに追加するかしないか設定できます。 |
|
「Git LFS（Large File Suport）」 |
リポジトリ内に大容量ファイルがあった場合、負荷を軽減してローカルリポジトリにダウンロードできるGitの拡張モジュールです。 今はインストールせずに、必要になった際、「https://git-lfs.com/」からダウンロードし、インストールすることも可能です。 |
|
「Associate .git* configuration files with the default text editor」 |
「.git*」ファイルを使用しているテキストエディターに関連付けるか否かを設定できます。 |
|
「Associate .sh files to be run with Bash」 |
「.sh」ファイルをBashに関連付けるか否かを設定できます。 |
|
「Check daily for Git for Windows updates」 |
毎日Gitの自動アップデートをおこなうか否か設定できます。 |
|
「Add a Git Bash Profile to Windows Terminal」 |
Windows TerminalにGit Bashを追加するか否かを設定できます。 |
|
「Scalar（Git add-on to manage large-scale repositories）」 |
大規模リポジトリのためのGit拡張機能Scalarをインストールするか否かを設定できます。 ちなみに、Scalarはマイクロソフト社が開発したリポジトリ管理ツールです。 |
- スタートメニューへのGitの追加
「Select Start Menu Folder」はスタートメニューフォルダにGitを登録するか否かを設定できます。登録しない場合は「Don’t create Start Menu folder」にチェックを入れます。
いずれか決まったら「Next」を押下します。
- テキストエディタの選択
「Choosing the default editor used by Git」はGitでどのテキストエディターを使用するか設定します。
|
選択肢 |
説明 |
|
「Use the Nano Editor by default」 |
Nanoをエディターとして選択可能です。 |
|
「Use Vim（the ubiquitous text editor）as Git’s default editor」 |
Vimをエディターとして選択可能です。 |
|
「Use Notepad++ as Git’s default editor」 |
Notepad++をエディターとして選択可能です。 （※要Notepad++のインストール） |
|
「Use Visual Studio Code as Git’s default editor」 |
Visual Studio Codeをエディターとして選択可能です。 |
|
「Use Visual Studio Code Insiders as Git’s default editor」 |
Visual Studio Code Insidersをエディターとして選択可能です。 |
|
「Use Sublime Text As Git’s default editor」 |
Sublime Textをエディターとして選択可能です。 |
|
「Use Atom as Git’s default Editor」 |
Atomのエディタを選択可能です。 （※要Atomのインストール） |
|
「Use VSCodium as Git’s default editor」 |
VSCodiumをエディターとして選択可能です（※要Vscodiumのインストール）。 |
|
「Use Notepad as Git’s default editor」 |
メモ帳（Notepad）をエディターとして選択可能です。 |
|
「Use Wordpad as Git’s default editor」 |
Windowsに搭載されているWordpadをエディターとして選択可能です。 |
|
「Select Other editor as Git’s default Editor」 |
上記以外のエディターを選択可能です。 下画像の「Browse」よりパスを指定します。 |
以上の選択が終わったら、「Next」を押下します。
- ブランチ名の決定
「Adjusting the name of the initial branch in new repositories」は、「git init」後のブランチ名を決められます。
|
選択肢 |
説明 |
|
「Let Git decide」 |
Gitが名前を決めます。 既定では「master」というブランチ名になります |
|
「Override the default branch name for new repositories」 |
テキストボックスに入力したテキストが新規リポジトリの既定ブランチ名になります （例：main、trunk、development） |
以上が決まったら、「Next」を押下します。
- パス環境の調整
「Adjusting your PATH environment」では、パス環境の調整をおこないます。
|
選択肢 |
説明 |
|
「Use Git from Git Bash only」 |
Gitの操作をGit Bash上のみで行います。PATHを変更しないため最も安全です。 |
|
「Use Git from the Windows Command Prompt」 |
コマンドプロンプトでもGitを使用可能にします（推奨）。 |
|
「Use Git and included Unix tools from the Windows Command Prompt」 |
コマンドプロンプトでGitと同梱のUnix系ツールも使用できるようにします。 |
以上を選択後、「Next」を押下します。
- openSSHのコマンドを選択
「Choosing the SSH executable」では、使用するopenSSHのコマンドを選択します。
|
選択肢 |
説明 |
|
「Use bundled OpenSSH」 |
Gitに同梱された「ssh.exe」をインストールして使用します。 |
|
「Use external OpenSSH」 |
PC内の既存のOpenSSHを自動検出して使用します。 |
以上を選択後、「Next」を押下します。
- HTTPS接続時のSSL/TLSライブラリ設定
「Choosing HTTPS transport backend」はHTTPS接続時のSSL/TLSライブラリ設定をいずれか選択します。
|
選択肢 |
説明 |
|
「Use the OpenSSL library」 |
OpenSSLを利用した通信をおこないます （通常はこちらで問題ありません）。 |
|
「Use the native Windows Secure Channel library」 |
WindowsのネイティブなSecure Channel（ストア証明書）を利用した通信をおこないます。 |
以上を選択後、「Next」を押下します。
- テキストファイルの改行の設定
「Configuring the line ending conversions」はGitにおいて、テキストファイルの改行コードを自動的に変換するか否かを下記のパターンで設定できます。
|
選択肢 |
説明 |
|
「Checkout Windows-style, commit Unix-style line endings」 |
チェックアウト時にLF→CR-LFへ変換、コミット時にCR-LF→LFへ変換します。 |
|
「Checkout as-is, commit Unix-style line endings」 |
チェックアウト時は変換せず、コミット時にCR-LF→LFへ変換します。 |
|
「Checkout as-is, commit as-is」 |
チェックアウト時・コミット時ともに行末の変換を行いません。 |
以上を選択後、「Next」を押下します。
- ターミナルエミュレータの設定
「Configuring the terminal emulator to use with Git Bash」は、Git Bashで使用するターミナルエミュレータの設定ができます。
|
選択肢 |
説明 |
|
「Use MinTTY（the default terminal of MSYS2）」 |
MSYS2の既定ターミナルのMinTTYを使用します。 |
|
「Use Windows’ default console window」 |
Windowsに標準搭載されているコンソールウィンドウを使用します。 |
以上を選択後、「Next」を押下します。
- 「git pull」コマンドに対する設定
「Choose the default behavior of ‘git pull’」では、「git pull」コマンドに対するデフォルトの挙動を設定できます。
|
選択肢 |
説明 |
|
「Default（fast-forward or merge）」 |
標準的な挙動。fast‑forwardマージが可能な場合はそれを行い、不可の場合はmergeを行います。 （実行コマンド：git pull –ff） |
|
「Rebase」 |
現在のブランチを取得したブランチに対してrebaseで結合します。 rebaseできない場合はfast‑forwardマージを試みます。 （実行コマンド：git pull –rebase） |
|
「Only ever fast-forward」 |
fast‑forwardマージが可能な場合のみ実行し、不可の場合はエラーにします。 （実行コマンド：git pull –ff-only） |
以上を選択後、「Next」を押下します。
- ログイン情報の管理設定
「Choose a credential helper」はユーザーIDとパスワードを保存・管理するための設定です。
|
選択肢 |
説明 |
|
「Git Credential Manager」 |
Git Credential Managerを使用し、ユーザーIDとパスワードを保存・管理します。 |
|
「None」 |
Git Credential Managerを使用せず、ユーザーIDとパスワードは保存・管理しません。 （毎回手動入力が必要） |
以上を選択後、「Next」を押下します。
- オプション設定
「Configuring extra options」では追加オプション設定をおこないます。
|
選択肢 |
説明 |
|
「Enable file system caching」 |
ファイルシステムのキャッシュを有効にしてパフォーマンスを向上させる機能です。 |
|
「Enable symbolic links」 |
シンボリックリンクの使用を許可する機能です。 シンボリックリンクはUnix用語で、Windowsのショートカットに似ています。 |
以上を選択後、「Next」を押下します。
- 試験運用中のオプション設定
「Configuring experimental options」はGitにてまだ試験運用中のオプションです。気になる人はチェックを入れてみてください。
|
選択肢 |
説明 |
|
「Enable experimental support for pseudo consoles.」 |
「Git Bash Window」でNodeまたはPythonのコンソールプログラムを使用できる実験的機能を有効にします。 |
|
「Enable experimental built-in file system monitor」 |
ワークツリーに多数のファイルがある場合に「git status」「git add」「git commit」などを高速化する組み込みの実験的ファイルシステム監視機能（FS Monitor）を有効にします。 |
以上を選択後、「Install」を押下します。
「Comleting the Git Serup Wizard」にて「Finish」を押下すればインストール完了です。
2.GitHubでアカウント 登録
公式サイトにアクセスし、「GitHubに登録する」をクリックします。
github.comに飛びます。下記の項目を入力します。
|
項目 |
説明 |
|
「Username」 |
ユーザー名を入力します。 |
|
「Email address」 |
自身のメールアドレスを入力します。 |
|
「Password」 |
任意のパスワードを入力します（15文字以上、または数字と小文字を含めて8文字以上）。 |
|
「Email preferences」 |
設定したメールアドレスでアップデート情報などを受け取りたい場合はチェックを入れます。 |
|
「Verify your account」 |
画像または音声によるロボット検証が行われるので、指示にしたがって進めます。 |
以上で入力事項は完了です。入力が完了すると、「Create account」ボタンを押せるようになっているので、ボタンを押下します。
下記のページに移動します。
上記で登録したメールアドレス宛にcodeが届いているので、メールを確認し、そのcodeを入力します。
「Welcome to GitHub」と表示され、アンケートが始まる（飛ばすことはできません）ので、順番に回答します。
「How many team members will be working with you?」……チームメンバーの数についてのアンケートです（個人開発の場合は「Just me」のみを選びます）。回答し終えたら、「Continue」を押下します。
「What specific features are you interested in using?」……優先的に使用したい機能についてのアンケートです（回答しなくても問題ありません）。
回答し終えたら、「Continue」を押下します。
最後に、プランを選びます。無料で利用する場合はFREEの下部にある「Continue for free」ボタンを押下します。
以上で、GitHubのユーザー登録完了です。
このあと、リモートリポジトリの設定をおこないますが、その前に、Gitの初期設定をおこなってしまいます。GitHubの画面はそのままにしておいてください。
3.Gitの初期設定
続いて、Gitの初期設定をおこないます。
Windowsメニューの「すべてのアプリ」から「Git Bash」を起動します。
下記のコードを入力し、user.nameの右に半角スペースを入れ、GitHubで登録したユーザー名を入力します。
|
git config –global user.name 登録ユーザー名 |
下記のコードを入力し、emailの右に半角スペースを入れ、GitHubで登録したメールアドレスを入力します。
|
git config –global user.email 登録メールアドレス |
以上で設定は完了です。
念のため、設定が正常におこなわれているか確認します。
「Git Bash」に以下のコードを入力します。
・ユーザーIDの確認
|
git config user.name |
・メールアドレスの確認
|
git config user.email |
先ほど登録したユーザーIDとメールアドレスが表示されていれば、成功です。
4.リモートリポジトリを作成
さきほどそのままにしていたGitHubの画面から「Create repository」ボタンを押下します。
「Create a new repository」のページで設定をおこないます。
|
入力項目 |
説明 |
|
「Repository name」 |
リポジトリの名前を入力します（短くて覚えやすいものが望ましい）。 |
|
「Description」 |
リポジトリの説明を入力します（任意）。 |
|
「Public・Private」 |
公開・非公開を設定します。 公開にすると誰でもソースコードを閲覧できます。 |
|
「Add a README file」 |
READMEを添付する場合はチェックを入れます。 |
|
「Add .gitignore」 |
.gitignoreのテンプレートを選択します。 プロジェクト内でGitが追跡しなくてよいファイルを指定します。 |
|
「Choose a license」 |
ライセンスを選択します。 ソースコードに対して他ユーザーが何をできるかを定めます。 |
以上、設定が完了したら、「Create repository」ボタンを押下します。リモートリポジトリの作成はこれで完了です。
5.ローカルリポジトリを作成
リモートリポジトリを作成後、下画像のようなメッセージが表示されます。こちらには、いくつかの場合におけるマニュアルが記載されています。まずは、表示内容を確認してみましょう。
|
選択肢 |
説明 |
|
「Set up in Desktop」 |
デスクトップ版アプリのGitHub Desktopを使用します。 |
|
「create a new repository on the command line」 |
ターミナルやGit Bashでローカルリポジトリを作成する際のコマンドが記載されています。 |
|
「push an existing repository from the command line」 |
すでにローカルリポジトリがある場合にリモートへプッシュするためのコマンドです。 |
|
「import code from another repository」 |
Subversion、Mercurial、TFSなど別のバージョン管理ツールからコードをインポートする際に使用します。 |
この項では、初めてローカルリポジトリを作成する際のマニュアル「create a new repository on the command line」を参照します。
ここにあるコマンドを実行することでローカルリポジトリの作成から、リモートリポジトリへのプッシュを一通り実行できます。
実際に実行していきたいと思いますが、その前に「Git Bash」より「cd “パス”」を打ち込み、プロジェクトのあるディレクトリに移動します。
|
cd “C:\test” |
「create a new repository on the command line」の内容をコピーします（下記の内容です）。このコードをペーストし、実行します。
|
echo “# test” >> README.md git init git add README.md git commit -m “first commit” git branch -M main git remote add origin https://github.com/〇〇〇/test.git git push -u origin main |
ちなみに、上記コードは下記のとおりの内容です。
|
コマンド |
内容 |
|
echo “# test” >> README.md |
READMEファイルを作成します。 |
|
git init |
ローカルリポジトリを作成します。 |
|
git add README.md |
READMEをインデックスに追加します。 |
|
git commit -m “first commit” |
ローカルリポジトリに「first commit」というメッセージ付きのコミットをします。 |
|
git branch -M main |
ブランチの名前を「main」に変更します。 |
|
git remote add origin https://github.com/〇〇〇/test.git |
ローカルリポジトリに、これからpushをおこなうリモートリポジトリを登録します （originはリモートの初期名）。 |
|
git push -u origin main |
ローカルリポジトリからリモートリポジトリにプッシュします。 |
実行すると、「Connect to GitHub」が立ち上がるので、「Sign in with your browser」を押下します。
WEBブラウザが立ち上がり、下画像のようなページに飛びます。
「Username or email adress」……GitHubのユーザーIDまたはメールアドレスを入力します。
「Password」……GitHubで設定したパスワードを入力します。
「Authorize Git Credential Manager」が立ち上がり、GitからGitHubへの認証がおこなわれるので、「Authorize GitCredentialManage」を押下し
「Authentication Succeeded」と表示されれば、認証成功です。
6.通常操作まとめ
ローカルリポジトリの作成後は、ワークツリーの内容をインデックスに追加し、ローカルリポジトリにコミットし、リモートリポジトリへプッシュする流れになります。以下の操作を簡単に振り返ります。
インデックスに追加
ワークツリーの内容をインデックスに追加するコマンドは「git add」です。ワークツリーで作業をおこなったあとに、必ず実施するコマンドです。
|
# 特定のファイルをインデックスに追加 git add example.txt # すべての変更をインデックスに追加 git add . # 変更と削除をインデックスに追加（新規ファイルは除く） git add -u |
ローカルリポジトリにコミット
インデックスからローカルリポジトリにコミットする際のコマンドは「git commit」または「git commit -m」です。「-m」はコメントを直接指定する際に利用するコマンドです。
|
# 変更をコミット（エディタでコメントを入力） git commit # メッセージ付きでコミット git commit -m “機能Aを追加” |
リモートリポジトリにプッシュ
ローカルリポジトリからリモートリポジトリにプッシュする際のコマンドは「git push origin 〇〇」です。「〇〇」はブランチ名です。
|
# mainブランチへプッシュ git push origin main # 現在のブランチをプッシュ git push origin HEAD |
ブランチの使い方
ブランチの使い方を簡単に解説します。
リモートリポジトリの複製
「Git Bash」を立ち上げ、プロジェクトをおこなうディレクトリに移動します（あるいはプロジェクトをおこなうフォルダで「Git Bash Here」を選びます）。
|
git clone リモートリポジトリのURL |
を入力し、実行します。URLには、複製するリモートリポジトリのURLを入れます。「Cloning into～」と処理が始まり、「100% done」と表示されれば、複製は完了です。
ブランチを作成ブランチ内での開発作業
新たなブランチを作成し、そのブランチに切り替えます。
|
git checkout -b 新規ブランチ名 |
と入力し、実行します。
「Switched to a new branch 新規ブランチ名」と表示されれば成功です。
masterブランチ（main）からたった今作成したブランチ（ブランチ名）に変わっているはずです。
ブランチの確認と切り替え
現在のブランチを確認したり、別のブランチに切り替えたりするにはgit checkoutコマンドを使用します。
|
# ブランチを一覧（「*」付きは現在のブランチ） git branch # 既存のブランチに切り替え git checkout ブランチ名 |
例えば機能追加用のブランチを作成する場合
|
# feature/add-loginという名前のブランチを作成して切り替え git checkout -b feature/add-login # 作業後、masterブランチに戻る git checkout main |
ブランチにコミット
ファイルの更新後は、通常通り「git add ファイル名」でステージングをおこない、「git commit -m」でコミットします。
|
# ステージングエリアにファイルを追加 git add example.txt # コミットを実行（メッセージ付き） git commit -m “サービス名を更新” |
リモートリポジトリへプッシュ
リモートリポジトリへのプッシュは「git push origin ブランチ名」でおこないます。
|
# ブランチの変更をリモートにプッシュ git push origin feature/update-service |
開発内容をマージ
「git checkout main」でmasterブランチに移動し、更新をおこなったブランチの内容とマージします。「git merge ブランチ名」と打ち込めば完了です。
|
# masterブランチに移動 git checkout main # ブランチの内容をマージ git merge feature/update-service |
1つのファイルを同時に変更するなど、自動マージに失敗する状況を「コンフリクト」と呼びます。
|
$ git merge feature/update-service Auto-merging updater.js CONFLICT (content): Merge conflict in updater.js Automatic merge failed; fix conflicts and then commit the result. |
上記の例ではupdater.jsでコンフリクトが発生しています。
|
<<<<<<< HEAD:updater.js const url = ‘https://example.com/settings.json’; ======= const base = ‘https://example.com’; const url = base + ‘/settings.json’; >>>>>>> feature/update-service:updater.js |
コンフリクトしたファイルを開くと、2つのブランチの相違点が「======」で区切られ、各所に挿入されています。
正しいコードになるよう書き換えて保存してください。
リモートリポジトリからプル
マージされたファイルを、リモートリポジトリからローカルリポジトリに反映させることをプルといいます。
|
git pull origin main |
上記コマンドは、リモートリポジトリのmainブランチから最新の変更を取得し、ローカルリポジトリにマージします。
GitHubを導入するメリット
GitHubを導入するメリットをみていきます。
- バージョン管理に向いている
Gitはバージョン管理に向いています。Gitを使用すれば、最新ファイルかわからなくなる、といった問題はなくなり、またバグが発生した際も、動いていた状態に戻すことも簡単です。
- チーム開発に有利
チーム開発にも有利で、同時に開発をおこなっていた際に、コードを上書いてしまう、といった心配もありません。
- 開発の業務効率を上げる
また、GitHubにはプッシュ、プルリクエストの機能があり、承認者は申請されたソースコードだけを確認すればよく、また、そのコードに問題があればコードレビューをし、問題なければ取り込みをする、といった運用ができるので、開発の業務効率をあげることができます。
- ノウハウが豊富
知名度が高いGitHubは、GitHubのことや、使い方などを取り扱った教材や、本、動画などが多い点がメリットとしてあげられます。
GitHubを導入するデメリット
GitHubを導入するデメリットについてもみていきます。
- お金や時間のコストがかかる
GitHubは、2019年1月、プライベートリポジトリが無料で使用できるようになり、2020年4月には、コア機能を無料で使用できるようになりました。しかしながら、小規模プロジェクトを想定した「Team」プランでも、導入コストが発生します。
また、GitやGitHubの学習コストが高いこともあげられます。GitやGitHubはその性質からチームメンバー全員が扱えるようにならなければ意味がないため、その分学習コストが高くなります。
- 個人のITリテラシーに左右される
GitやGitHubを扱えるようになるには、それなりの知識が求められます。知識が不十分なことで、デメリットが発生する可能性もあります。例えば、GitHubには、非公開・公開の設定があるため、非公開にすべき情報を公開にしてしまう、といった事例が考えられます。
実際にそうした事例が起こっており、個人のITリテラシーに左右されるでしょう。
エンジニア転職にGitHubが活用できることも
GitHubアカウントを活用し、ITエンジニアの転職活動で、自身のスキルや経験を効果的にアピールできる可能性があります。
GitHubを公開すると、採用担当者は応募者が実際にGitHubを使用できることを確認できます。多くの開発現場でGitHubが導入されているため、実務で必要とされる基本的なツールの習熟度を示す材料となります。また、公開されているリポジトリから使用可能なプログラミング言語を具体的に把握してもらえるため、複数の言語を扱える場合は、それぞれ異なる言語の成果物を公開することで技術の幅広さをアピールできるでしょう。
さらに、制作した成果物を時系列で公開すれば、エンジニアとしての成長過程やキャリアの積み重ねを視覚的に示すことが可能です。これは採用担当者が技量を判断する重要な指標となります。
ただし、GitHubアカウントの重要性は応募先企業によって異なります。特に中小企業やベンチャー企業、WEB系企業では即戦力が求められる傾向があるため、GitHubアカウントの所有が選考において有利に働くケースが多いと考えられます。
転職を検討する際は、応募先企業の規模や事業内容を考慮しながら、GitHubアカウントの準備を進めることをおすすめします。
まとめ
GitとGitHubは、チーム開発でソースコードを扱う仕事では必須のスキルです。
習得にはそれなりの学習コストがかかりますが、この記事を参考に、ぜひ習得してください。
