GitとGitHubの使い方（SeeFT）

GitHubの基本

ここではSeeFTに限らず, GitHubを使う際の基本的な操作について記載しています.

◆ Githubからローカルに

Githubのリポジトリを自分のローカルに持ってくる

• git clone <url>

◆ ローカルからGithubに

編集ファイルをステージング（個別）

• git add <file_name or directory_name>

編集ファイルをステージング（一括）

• git add .

ステージングしたファイルをコミット

• git commit -m "<commit message>"

Githubにpush

• git push origin <branch名>

◆ ブランチの切り替え

すでにあるブランチに切り替える場合

• git checkout <branch_name>

新しいブランチを作る場合

• git checkout -b <new_branch_name>

※ ブランチネームは空白とかは使わない，できるだけ特殊文字も使わない. 詳しくは開発ブランチの命名規則の項を参照

◆ ローカルのファイルにリモートの最新情報を持ってくる

• git pull origin <branch_name>

SeeFTのリポジトリのルール（作成中）

ここではSeeFTのリポジトリにおけるルールを記載しています.
他のプロジェクトでは異なる場合があるのでご注意を.

ルールとは書いていますが, 少なくともSeeFTではそこまで堅苦しく考えなくても大丈夫です.
多少ルールとズレてても開発してくれる方が助かるねんの精神で.

◆ ブランチルール

• mainブランチ
  • 安定ブランチ，本番用ブランチ
• developブランチ
  • 開発用ブランチ，開発段階での安定ブランチ，これを公開するときに安定ブランチにマージ
• ラベル/名前/issue{num}-作業概要
  • 開発ブランチ，issue{num}にissueの番号を入れる．

開発ブランチの命名規則

• ブランチ名はラベル/名前/issue{num}-作業概要にする
  • ラベル
    • feat新しい機能に関連するタスクのブランチに付ける
    • fix 修正系タスクのブランチに付ける
  • 名前はローマ字
  • 作業概要は, Google翻訳とか使って良い感じに分かりやすいものにしよう.
• 空白とかは使わない，できるだけ特殊文字も使わない.
• 迷ったら他の人のやつを真似ときゃ大丈夫や！の精神
• EX
  feat/uchida/85-show-max-member

◆ コミットルール

• コミットメッセージは行った開発を端的にわかりやすく書く（長すぎないように注意する）
• コミットメッセージラベルを付ける
  • [add] file or directory の追加
  • [mod]または[feat] file or directory の編集
  • [fix] file or directory のバグや軽微な修正
  • [del] file or directory の削除
  • [wip] 作業中. レビューのためにブランチ移動する際など
  • [otr] その他
    • ぶっちゃけ[fix]と[feat]くらいしか使ってない
    • 参考: 【Git】コミットメッセージの先頭につけた方が良い単語リスト- prefix集 -
• EX
  git commit -m "[fix]mobileの集合場所バグ修正"

よし，開発しようってなったとき

1. まず, ブランチを最新の状態にする
   git checkout develop
git fetch
git pull origin develop

2. ブランチを切ろう
   git checkout -b "<ブランチ名>"

   • ブランチ名の付け方は開発ブランチの命名規則の項を参照
   • ブランチ名は""で囲む

3. 開発をしよう
   がんばれ，応援はしてる.
   まずは開発を楽しんで.

4. ステージングをしよう
   git add <編集したファイルorディレクトリ名>

   • 編集したファイルが複数ある時はgit add .で一発.
   • VSCodeの拡張機能使うと楽. コマンドラインでやるとカッコいい. 好きな方で

5. メッセージを的確につけてコミットをしよう
   git commit -m "<コミットメッセージ>"

   • コミットメッセージの書き方はコミットルールの項を参照
   • コミットメッセージは""で囲む

6. Githubにpushしよう
   git push origin <ブランチ名>

7. pull requestを行おう
   Githubにアクセスしてpull requestを行う．
   mergeはPMが行います.

   • pushが成功している場合, GitHubのページ上部に緑色のボタンが出てくるのでそこでpull requestを作成しよう
   • テンプレートが自動入力されているので, それに沿って記入しよう

おつかれ！！！

reviewをするとき

◆ reviewって？

reviewというのはpull requestというのを送ったときに開発者以外が行う動作確認作業

◆ reviewの手順

1. 今作業している内容をcommitする（なければスキップ）
   git add <編集ファイル>
git commit -m "WIP"

2. ブランチを最新の状態にする
   git checkout develop
git fetch
git pull origin develop

3. pull_requestされているブランチに移動しよう
   git checkout <pull_requestされているブランチ名>

4. 動作確認をしよう
   GitHubのpull_requestのページに記載されている確認事項をチェックしよう.

5. レビューしよう
   まず, pull_requestのページのCommitsのタブで, 一番下にあるコミットを開こう.
   右上に緑色のReview Changesというボタンがあるので, そこでコメントと評価を行おう.
   大丈夫であればApproveを選択してSubmit Reviewを押そう.

   • 評価の種類
     • Comment 「修正点があるよ. コメントしたよ」の意味
     • Approve 「問題ないよ」の意味
     • Change 「あかん」の意味

おつかれ！！！