バージョン管理に関して

Question

技術的なことではないのですが、作業の進行管理、バージョン管理に関して質問です。

ホームページやWEBアプリなどを作っている最中の進行管理、バージョン管理に関して
現在作業環境としてはローカル環境で変更、テスト、検証を行い、問題なければバージョン管理でコミットしてからFTPにアップするという流れで作業をしています。

現状一人で作業する機会が多いのですが、たくさんの修正や変更がある場合
全て修正、変更してからバージョン管理で一括コミット（もしくはブランチ⇨マージ）するのか
変更項目ごとにブランチを作って、全て終わったら全てをマージするのか
変更項目ごとにコミットするのか

どういう作業の仕方がいいのでしょうか

質問した経緯としては、バージョン管理をしていますが、あまり旧バージョンに戻すということがありません。
現状は変更や修正の依頼を一括りとして完了後にまとめてコミットしていますが

もし、そのコミットのうち、１つの修正だけ戻したいという事案が発生した場合、
コミットした修正丸ごと戻ってしまうと考えたので、分けてコミットした方がいいのかと不安になり質問しました。

バージョン管理　GItHub

Comments

[gentaro]

そんなもんはあなたが考えて決めるべき話でしかない。
コンサルして欲しいとかそういう話なら金払って相談するべき。
少なくともQ&Aで解決する話じゃないし、質問内容的にここでは非推奨。

https://teratail.com/help/avoid-asking
「teratailは困っている人の質問を解決するサービスです。そのため、漠然とした興味から票を募るような質問や、意見の主張をすることを目的とした投稿は推奨していません。
何か困っている理由があり、最適解を見つける為の知見を得たい場合は、その理由や何が知りたいのかを明確に記述してください。」

漠然とした理由でなく、具体的に困ってる事案があるんならそれを質問文に明記する必要がある。

[u-sukesan]

「こうするのが正しい」という正解があり、
その正解がなんなのかわからなかったので質問したのですが、サイトの使い方を間違っていたようです。

「そんなもんはあなたが考えて決めるべき話でしかない。」
という事案であるかどうかもわからないので質問いたしました。

大変失礼致しました

Answer 1

どういう作業の仕方がいいのでしょうか

「行動指針」という一つの提案で考えてみます。

あくまで私の考えであり
他の方との思想とは必ずしも一致するわけではありません。
単なる参考、納得した箇所だけ採用する感じでお願いします。

---

そもそもGitというのは
ゲームがセーブデータに保存して
プレイ中失敗したり敵に負けてしまったら撒き戻せるものと同様のものです。

ゲームでは保存出来るセーブデータに制限がありますので、
基本的に上書き・上書きになりがちですが
Gitにはそういう制限はないので、無制限にセーブデータ(コミット)を別名義で保存することが出来ます

---

１つの修正だけ戻したいという事案が発生した場合、

コミットした修正丸ごと戻ってしまうと考えたので

これに関しては「1コミット・1タスク」を提案します。
ファイルの編集作業には何かしらの目的があるはずです。

その目的が貴方の今日の作業であり、
その目的には名前が付いてるはずです。

まさか他人に言葉で作業報告も出来ないのに
作業だけしてるなんてありませんよね？
その作業名をコミットメッセージにしましょう。

仮にコミットした修正丸ごと戻ってしまったとしても、
1タスクを完結させたわけではなかったわけですから
そのコミットに意味がありますか？ありませんよね？という話になります。

分けてコミットした方がいいのか

それは1タスク(作業)が重いか否かで判断しましょう。

貴方は普段開発する時に
「素晴らしいソフトウェアの開発」という1タスクだけ用意して
何ヶ月も掛けて完了とはしませんよね？

素晴らしいソフトウェアを仕上げる為に
何十・何百というタスクに分割して
そのタスクを1個ずつ完了とすることで積み上げてきたはずです。

1タスクが重いなら分割して複数のタスクに分け、
そのタスク分コミットしましょう。

GitHubにはIssueという掲示板があり、
Issueを作るとIssueにIDが割り振られて
コミットメッセージに下記のように登録すると紐付けられます。

例: IssueのIDが333だった場合
git commit -m "xモジュールの不具合修正 #333"

全て修正、変更してからバージョン管理で一括コミット（もしくはブランチ⇨マージ）するのか

変更項目ごとにブランチを作って、全て終わったら全てをマージするのか
変更項目ごとにコミットするのか

これに関しては
有名なブランチの運用ルールを勉強することをオススメします。

• git-flow
• GitHub Flow

どちらにも共通して言えるのは、
masterブランチに入っているファイル群は
本番環境に入っているものと同様で何時でもデプロイ出来るという思想です。

GitHub Flowは気にせずどんどんmasterにマージしまくりますが、
それは「悪いものをより良いものに差し替えたら本番環境で動くでしょ？」がベースになっています。
動作しなくても、すぐに差し替えましょう。それで何か問題でも？

git-flowはいやいや、一旦developブランチに集約して
developブランチが問題ない事を検証してから
masterブランチに統合させようよという思想です。

日本企業はgit-flowが多いかな？
git-flowはかなり重い、仰々しい事をやっているので
「そんな大げさな事をこの規模でやってもねぇ……」というわけで、
実践的にはgit-flowを参考にしつつもいくつかの工程を端折ったブランチ運用ルールにしている現場は多いと思います。

現在作業環境としてはローカル環境で変更、テスト、検証を行い、問題なければバージョン管理でコミットしてからFTPにアップするという流れで作業をしています。

本筋とは違いますが

GitHubにはwebhookやGitHub Actionsという
最新世代の機能が存在します。

テスト・検証の一部工程
例えば関数やメソッドの返り値の検証くらいならばコードで出来ますよね。

FTPでのアップロード作業とかも
スクリプト組めば自動化出来ますよね。

その辺は大事な貴方のリソースを使う程高尚な作業じゃないと思うので
暇が出来たら勉強して組み込んでみてはいかが？

Comments

[u-sukesan]

大変丁寧な回答ありがとうございます。

どう運用するのがいいのか、という「考え方」の参考になりました。
協業することも少なく
実際自分が行っているプロジェクトの運用の仕方が一般的なのか邪道なのか、
そもそも正解があるのかないのかなどわからなくなる時があります。

「1コミット・1タスク」を提案された理由なども大変わかりやすく
自分なりにどの範囲でコミットすると運用しやすいかなど考えてみたいと思います。

webhookやGitHub Actionsなども調べてみます。

Answer 2

この手の質問には”正解”が無いので運用次第としか言えません。
が、せっかくバージョン管理ツールを利用しているのであれば、GitHubフローで運用するのがいいのではないのでしょうか？
通常複数人で開発する場合、機能単位で1ブランチ作成しプルリクエストを投げコードを承認してもらいmasterへマージするというのが基本的な流れになっています。
ただ、お一人で開発されているのであればそれはあなたの自由なので、masterに直接pushするのもありですし、上記の複数人のフローと同じようにするのもどっちでもいいと思います。

蛇足ですが、FTPでアップロードするより、サーバーにsshで接続してgit pullした方が反映しやすいのでは？
FTPでアップロードするデメリットとしてはポートを開けているので多少なりともリスクが存在すること、不要になったファイルを手動で削除しなければいけないこと、時間がかかること。等がありちょっと手間だと思います。
せっかくGitHubを使っているのならコマンド一発で反映させた方が早いし確実だと思います。

Comments

[u-sukesan]

大変ご丁寧な回答ありがとうございます。

正解がない

という回答で解決いたしました。
他の方にもご指摘を受けましたが、「こうするのが普通」という正解または王道があると思っていたので
質問いたしましたが、質問自体が漠然としていたようですね。

「通常複数人で開発する場合、機能単位で1ブランチ作成しプルリクエストを投げコードを承認してもらいmasterへマージするというのが基本的な流れになっています。」

ということを知れただけでも参考になりました。

「FTPでアップロードするより、サーバーにsshで接続してgit pullした方が反映しやすいのでは？」
こちらも調べてみます。

ありがとうございました