初めてのgithubで簡易的な流れを完全に理解した話②

Rad Adventar 2022 の16日目の記事です。

https://scrapbox.io/files/6381c8ada58f990021f33c92.png

ご挨拶

この日の担当は自分ということでよろしくお願いします。

チームで開発行う上でレポジトリを作る側と使う側で別途分けて考えたほうが良かったなと…。

しかし、まあ書いてしまったのでこのまま直進だ！

Twitterの個人DMにでも気になった箇所や良い提案ございましたらご指摘願えますと嬉しいです。

(またこの記事では Ubuntu 20.04 LTS の bash で行っています)

それではまたもや行ってみよう!

Issue

解説

Issueは実はテンプレートが作れます！

しかし、今回はあくまで簡易的な流れですので載せません！

時間があれば別途で記事を執筆します。

Issueはチケット型駆動開発のチケット部分を担うものです。

Issue型駆動開発として自分たちが使う場合チケット(TODO)を書いていきます。

一応Issue型駆動開発で書く場合のIssueテンプレートも下記においておきます。

code:template

# 概要

//簡易的な実装内容の概要を説明

# 目的

//なぜそれを実装するのかを説明

# 実装内容

//実装内容の詳細を説明(実装方式や環境など)

# タスク

[]XXX

//IssueはMarkDownで書けるため、[]とするとチェックシートが作成できます

//もし詳細な工程があるなら書いてもいいかも

手順

githubのGUIから該当レポジトリの『Issues』の『New issue』から作成します。

https://scrapbox.io/files/639ab6290b43c0001d42b784.png

あとは簡潔に短いタイトルとMarkDownでtemplateのようなことを書いていけばOK！

『Submit new issue』を押せばIssue番号(＃から続く数字)が割り振られたIssueができるはずです！

このIssue番号はチケット番号と同等の意味を持っていて、コミット(Commit)時に使います。

Status

解説

本当はここにProtectedが挟まったほうがいいのかもしれないけど…今回は初回の流れどうりやっていくよ！

機会があったら記事書きます…(負債)。

Statusは前回のpullから変更があったファイルがあるかどうかを洗い出してくれるコマンドなのだ！

もしStaging(後述)されてないファイルがあった場合は赤色で、されてるファイルは緑色で表示されるぞ！(環境依存)

手順

code:bash

$ git status

これだけ！

add(staging)

解説

変更済みファイルをワークツリー(操作してるフォルダ)からインデックスに登録する行為

つまり、コードを書いたら status → staging → commit → push の順でリモートレポジトリに保存するってことですね。

(イメージは下記の図を参照)

インデックスはコミットをするときにまとめて送るためのバッファとしてあります。

コミットはこのstagingしたファイル群を一つの塊として行うことが大半です。(固まりすぎるとまずいですが…)

https://scrapbox.io/files/639ae1bd35faaf001ee8af2f.png

手順

add コマンドを使用することでできます。

code:bash

$ git add <インデックスに登録したいファイル名>

status コマンドで staging できてるか確認しましょうね。

commit

解説

commit(コミット)はローカルレポジトリにインデックスに登録した変更をコメント付きで反映させるためのコマンドです。

このコメントが曲者でして…。

プレフィックス、Issue番号などを使うのが礼儀なんですよね…。

正直ここで詰まることもあるかもしれないですね。

一つ記事がかけるくらいなので、ここでは簡易的にコメント例を載せておきます。

code:template

//一行空ける

Issueを閉じる場合(そのコミットがIssueのタスクをすべてクリアする場合)、refsの部分をfix, close, resolveとするとIssueが勝手に閉じる(解決済みになる)ので便利！

コミットの単位はチームメンバーで決めてくださいね！できるだけ小さい方がいいですよ…多分。

手順

bash で git commit コマンドを使用する。

-m オプションを付けるたびに行数が追加される。

code:bash

$ git commit -m <1行目> -m <2行目> -m<3行目>

fetch

解説

リモートレポジトリの更新があった場合、ローカルレポジトリに反映する行為(詳細を話すと少し違う)

これによって更新があるかわかる。

あと競合したファイルがわかる。

push するまえにとりあえず挟む。

競合してしまったファイルの効率のいい直し方は…わからないので教えてほしいです。(もとよりかぶらないように配分をするっていうのは当たり前)

https://scrapbox.io/files/639ae1bd35faaf001ee8af2f.png

手順

git fetch コマンドを打つだけ！

code:bash

$ git fetch

pull

解説

fetch でもし更新があった場合に行う。

これを打つとリモートレポジトリのものをローカルにすべて反映してくれる。

fetch の時点で競合があった場合 pull するとめちゃくちゃになるので、対処しましょう…。

手順

git pull コマンドを打つだけ!

--all オプションを入れるとすべての branch を反映してくれるぞ！

code:bash

$ git pull --all

②の終わり

記事の続きを執筆しましたが、反省点がもう多くて顔を日々覆っています(恥ずかしい…)。

しかし、コマンドの打ち方などがブレを無くして読みやすくしたので今回は少し成長したかな！(自画自賛)

次は③！push, tag, pull request... 短いように見えて魔の pull request があるので大変です！

もしよかったら読んでもらえると嬉しいです！

③に続く…

/icons/hr.icon