🚀

GitとGitHub

2023/09/20に公開

Git と GitHub を用いた個人開発の流れ

ゼロからプロダクトを作り始める場合(まだ一切コードを書いていない場合)

  1. GitHub 上にプロダクト用のリモートリポジトリを作成
  2. 作成したリポジトリをクローンする.
git clone YOUR_REPOSITORY_URL
  1. エディタでクローンしたディレクトリを開き,コードを記述(作業は全てローカルリポジトリで実行している状態)
  2. 個別の機能ができたタイミングなどでバージョンを決定
git add .
git commit -m "commit message"
  1. GitHub のリモートリポジトリに push
git push origin main
  1. 以降は上記 3-5 の繰り返し

リポジトリを作成する前にコードを書いていた場合

  1. GitHub 上にプロダクト用のリモートリポジトリを作成。作成すると URL が表示される
  2. 手元のプロダクトのディレクトリでローカルリポジトリを作成
git init
  1. リモートリポジトリとローカルリポジトリを連携
git remote add origin YOUR_REPOSITORY_URL
  1. 以降はadd,commit,pushの繰り返し

GitHub にプロダクトを push

リポジトリを作成する

  • ブラウザで GitHub にアクセスし,新しいリポジトリを作成する
  • 作成するとURLが表示されるのでそのままにしておく
  • SSHのタブを選択しておく(後でURLを使用するため)

【超重要】ディレクトリを変更する

まず,ターミナルの作業ディレクトリをプロダクトのディレクトリを配置したい場所へ移動するcd ディレクトリ

開発用のディレクトリがあればそこでも良いし,特にない場合はデスクトップなどがわかりやすい.下の例では作業ディレクトリをデスクトップにしている.

cd ~/Desktop/

リポジトリをクローンする

GitHub 上で作成したリポジトリを手元で操作できるようクローンする.下記コマンドを入力する.

(URL は上の手順で作成したリポジトリのものを使用する.)

git clone YOUR_REPOSITORY_URL

# 実行結果
Cloning into 'YOUR_REPOSITORY'...
warning: You appear to have cloned an empty repository.

クローンができたら,エディタで該当フォルダを開く

ファイルを add

ファイルの内容を記述したら,commit して GitHub に push してみよう.ここでは「add」「commit」「push」の 3 手順が必要となる.

【重要】まずは作業ディレクトリを確認する.いない場合は cd で移動しておく.

git add コマンドは Git で管理するファイルを指定

git add .

ファイルを commit

commit はファイルのバージョンを作成するイメージ.
-m のあとの「""」内にコミットメッセージを追加する.(変更内容などが把握できるコメント)

git commit -m "コミットメッセージ"

ファイルを push

push は実際にファイルをアップロードするイメージ.この段階ではじめて GitHub にコードが追加される.

下記コマンドを入力する.

git push origin main

実行結果

Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 385 bytes | 385.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To github.com:******/******.git
   9ae72be..eb700ec  main -> main

ブラウザで GitHub のページを確認し,ファイルがアップされていれば成功!

以降は「コード書く」「add」「commit」「push」の繰り返し

branch を用いた開発

Git を用いて開発を行う際には「branch」を活用

branch を用いると履歴の流れを分岐して管理することができる.分岐させた branch は他の branch の影響を受けないため,同じリポジトリ中で複数の変更を同時に進めていくことができる.

参考:https://backlog.com/ja/git-tutorial/stepup/01/

各 branch の役割

厳密に決まっているわけではないが,主に以下のような役割で branch を作成することが多い.

branch名 役割
main 本番用のソースコードを管理
develop 開発用のソースコードを管理
feature 各追加機能やバグ修正などを行うための branch

実際にはプロジェクトによって運用方法が決められる
今回は main branch と develop branch を用いた開発の手順

branch を用いた開発の流れ

  1. まず main branch を用意する(リポジトリ作成時に自動で作成される).
  2. develop branch を作成し,main branch から切り替える.
  3. develop branch でコードを書き,開発を進める.
  4. 区切りがついたら、add,commit,push
  5. main branch に対して「プルリクエスト」を作成
  6. 作成されたプルリクエストを「マージ」し,develop branch で開発した内容を「main」branch に反映させる.

branch の作成・切り替え

リポジトリに移動

まずは develop branch を作成

git branch develop

はじめは main branch を操作する状態となっている.作成したら branch を切り替える.

git switch develop

現在操作している branch は下記のコマンドで確認できる.現在の branch の前に * が表示される.

git branch

#実行結果
* develop
  main

コードの push

develop branch になっていることを確認し,コードを追記する

develop branch でコードを追記編集したら,GitHub にプッシュする.GitHub にプッシュする際にも branch ごとにプッシュを行う.今回は develop branch に対してプッシュする

git add .
git commit -m "update"
git push origin develop

develop branch でコードをプッシュすると GitHub 上でそれぞれの branch のコードを確認できる.

プルリクエストとマージ

プッシュできたら develop branch の内容を main branch に反映させる.以下の手順でプルリクエストを作成

  1. GitHub のリポジトリのページを開き「Pull requests」タブをクリック
  2. New pull request ボタンをクリック
  3. branch を選択する部分が「main <- develop」と設定する.画面上で切り替えるとファイルの差分が表示される
  4. branch の設定ができていることを確認したら Create pull request ボタンをクリックする
  5. メッセージを入力する画面に切り替わるので,任意の内容を入力して Create pull request を再度クリックする
  6. プルリクエストを管理する画面に切り替わる.プルリクエストした内容に問題がなければ Merge pull request → Confirm merge の順にボタンをクリックする
  7. プルリクエストとマージが完了したら Code タブをクリックして,develop branch で記述したコードが main branch でも反映されていることを確認
  1. 手元で main branch のコードを反映させる.branch を develop から main に切り替え,pull のコマンドを実行する.これで GitHub 上の main branch のコードを,手元の main branch に反映させることができる.
git switch main
git pull origin main

このように,「develop branch で開発 → main branch にプルリクエスト → main branch にマージ」という流れで進めるとスムーズに開発することができる

issue を用いた開発

branch を用いた開発によってアプリケーションの更新を適切に管理できるようになったが,細かい修正ポイントなどはコミット内容だけを見ても把握できない.

また,機能追加や修正のゴールを明確にして確認できる状態にしておくことも大切である.

issue とは

issue とは「課題を管理する機能」である.GitHub 上では掲示板のような要領でブラウザ上から操作できる.

開発者は issue を用いることで課題を明確化する,解決した課題を把握する,などが実現できる.

作成した issue には追加でコメントなど行うことができ,課題が解決したら「close」する.close した issue は対応が完了しているものとして扱われる.

issue の作成

GitHub のリポジトリのページを開き,「Issues」タブをクリックする.issue を作成するとここに一覧表示される

「New issue」ボタンをクリックすると入力画面が表示されるので,タイトルと本文を入力する.本文はマークダウン形式で入力することができ,課題の詳細(バグの挙動や修正内容,追加したい機能の内容など)を記述する.

一通り記述したら「Submit new issue」ボタンをクリックすると issue が作成される.

issue とプルリクエストの連携

開発者は issue を確認して作業内容を把握し,前項と同様に develop で開発を進め,push して「main <- develop」のプルリクエストを作成する.

プルリクエストを作成したら画面右側の「Development」をクリックし,連携させる issue を選択する.選択すると issue とプルリクエストがリンクした状態となる.

リンクした状態でプルリクエストをマージすると,リンクした issue も自動的に close される.

GitHub Pages を用いたデプロイ

「GitHub Pages」の機能を用いると,任意のブランチのコードをデプロイすることができる.

注意点

  • GitHub Pages のサーバにはプログラムを動かす機能がないので,デプロイできるのはフロントのコード(HTML,CSS,JS)のみ
  • ソースコードを push した状態でないとうまく設定できない

手順

ブラウザでリポジトリの URL を開き,「settings」をクリックして設定画面を開く.

左側の設定項目の「pages」をクリックする.

表示された画面中央部の「Source」部分で「main」を選択して「Save」ボタンをクリックする.

デプロイ先の URL が表示されるのでアクセスして動作を確認する.

  • 発行された URL を readme ファイルに書いておくとすぐに試せて良き.
  • しばらくしないと反映されない場合があるのでしばらく待機する.
  • 新バージョンを push しないと反映されない場合があるので,適当な内容で再度 push して様子を見る.

gitとgithubを使った小規模開発の手順

開発プロジェクトにおいて、gitとgithubを活用することで効率的にコードの変更やレビューが行えます。小規模開発を想定して手順を説明します。

  1. GitHubリポジトリの作成
  • GitHubにログイン(またはアカウントを作成)
  • 右上の"+" ボタンをクリックし、"New repository"を選択
  • リポジトリ名を入力
  • "Public"か"Private"を選択
  • "Initialize this repository with a README"をチェック
  • "Create repository" ボタンをクリック
  1. ローカルにリポジトリをクローン
git clone https://github.com/あなたのユーザー名/リポジトリ名.git
cd リポジトリ名
  1. 開発ブランチの作成
    各開発者は独自のブランチを作成して作業します。
git checkout -b feature/開発者の名前-機能名
  1. コードの変更とコミット
  • 必要なファイルを編集 + 変更をステージング
git add .

変更をコミット

git commit -m "コミットメッセージ"
  1. GitHubにプッシュ
git push origin feature/開発者の名前-機能名
  1. Pull Requestの作成とコードレビュー
  • GitHubのリポジトリページに移動
  • "New pull request" ボタンをクリック
  • base: main と compare: feature/開発者の名前-機能名 を選択
  • 必要な情報を入力し、"Create pull request" ボタンをクリック
  • チームメンバーにレビューを依頼
  • コードレビューの詳細
  1. コンフリクトの解決
    https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

Discussion