私のgithub flow
- 基本1人、たまに2人で開発している
- 今のところ特に問題なく運用できている
開発スタイル
- vscode or gitpod or github codebaseを使用して開発
- バッグエンドJava,フロントエンドhtml+javascript+cssで開発
- バックエンドとフロントエンドを同一Githubリポジトリで開発
ブランチは3種類
- main
- release
- 作業
mainブランチ
mainは作業ブランチをマージするブランチです。
releaseブランチ
リリースするときにmainブランチをマージするブランチです。github actionなどでリリースモジュールを作ったりもします。
-
利点、pull requestを作成すると、前回リリースからの差分を確認できる
-
DBの変更がある場合は、pull requestにSQLを記載する
-
設定ファイルの変更がある場合は、pull requestに設定内容を記載する
- 利点、リリース作業をpull requestで進められる
- 欠点、リリース前にpull requestがcloseしてしまう
作業ブランチ
自分のgithubアカウントID/issue番号
という名前を付けます。
例えば、
hoge/3など
バグとかマージミスの場合など、同一issue番号の修正をする場合は、
hoge/3a
hoge/3b
hoge/3c
というふうにアルファベットを変えていきます。
a-zで26文字しかないけど、そんなに発生しない。
- 利点、自分のIDが含まれるので衝突しない。ブランチ名を考えなくても開発がスタートできる。issue内容が変更になってもブランチ名を変更する必要はない
pull requset作成後にdevelopmentでissueを紐づける
pull requestをmainリポジトリにマージしたら作業ブランチを削除する
pull requestのコメント
- #123などとハイフンをつける。
と、Github上ではissueタイトルにリンクが付いた状態で表示される
- 利点、ぱっと見でわかりやすい
bugが発生したらどうするの？
issueチケットを作成するので、
通常の開発と同じくmainブランチから作業ブランチを作成する。
デプロイはどうするの？
他社のgithubリポジトリや他社サーバへのリリースの場合は、Releaseページからダウンロードして、配置する。
自分のgithubリポジトリで、自社サーバへのリリースの場合は、tokenを発行してgithubから配置先サーバに直接ダウンロードする。
- 利点、通信量を節約できる