どういう作業の仕方がいいのでしょうか
「行動指針」という一つの提案で考えてみます。
あくまで私の考えであり
他の方との思想とは必ずしも一致するわけではありません。
単なる参考、納得した箇所だけ採用する感じでお願いします。
そもそもGitというのは
ゲームがセーブデータに保存して
プレイ中失敗したり敵に負けてしまったら撒き戻せるものと同様のものです。
ゲームでは保存出来るセーブデータに制限がありますので、
基本的に上書き・上書きになりがちですが
Gitにはそういう制限はないので、無制限にセーブデータ(コミット)を別名義で保存することが出来ます
1つの修正だけ戻したいという事案が発生した場合、
コミットした修正丸ごと戻ってしまうと考えたので
これに関しては「1コミット・1タスク」を提案します。
ファイルの編集作業には何かしらの目的があるはずです。
その目的が貴方の今日の作業であり、
その目的には名前が付いてるはずです。
まさか他人に言葉で作業報告も出来ないのに
作業だけしてるなんてありませんよね?
その作業名をコミットメッセージにしましょう。
仮にコミットした修正丸ごと戻ってしまったとしても、
1タスクを完結させたわけではなかったわけですから
そのコミットに意味がありますか?ありませんよね?という話になります。
分けてコミットした方がいいのか
それは1タスク(作業)が重いか否かで判断しましょう。
貴方は普段開発する時に
「素晴らしいソフトウェアの開発」という1タスクだけ用意して
何ヶ月も掛けて完了とはしませんよね?
素晴らしいソフトウェアを仕上げる為に
何十・何百というタスクに分割して
そのタスクを1個ずつ完了とすることで積み上げてきたはずです。
1タスクが重いなら分割して複数のタスクに分け、
そのタスク分コミットしましょう。
GitHubにはIssueという掲示板があり、
Issueを作るとIssueにIDが割り振られて
コミットメッセージに下記のように登録すると紐付けられます。
例: IssueのIDが333だった場合
git commit -m "xモジュールの不具合修正 #333"
全て修正、変更してからバージョン管理で一括コミット(もしくはブランチ⇨マージ)するのか
変更項目ごとにブランチを作って、全て終わったら全てをマージするのか
変更項目ごとにコミットするのか
これに関しては
有名なブランチの運用ルールを勉強することをオススメします。
どちらにも共通して言えるのは、
masterブランチに入っているファイル群は
本番環境に入っているものと同様で何時でもデプロイ出来るという思想です。
GitHub Flowは気にせずどんどんmasterにマージしまくりますが、
それは「悪いものをより良いものに差し替えたら本番環境で動くでしょ?」がベースになっています。
動作しなくても、すぐに差し替えましょう。それで何か問題でも?
git-flowはいやいや、一旦developブランチに集約して
developブランチが問題ない事を検証してから
masterブランチに統合させようよという思想です。
日本企業はgit-flowが多いかな?
git-flowはかなり重い、仰々しい事をやっているので
「そんな大げさな事をこの規模でやってもねぇ……」というわけで、
実践的にはgit-flowを参考にしつつもいくつかの工程を端折ったブランチ運用ルールにしている現場は多いと思います。
現在作業環境としてはローカル環境で変更、テスト、検証を行い、問題なければバージョン管理でコミットしてからFTPにアップするという流れで作業をしています。
本筋とは違いますが
GitHubにはwebhookやGitHub Actionsという
最新世代の機能が存在します。
テスト・検証の一部工程
例えば関数やメソッドの返り値の検証くらいならばコードで出来ますよね。
FTPでのアップロード作業とかも
スクリプト組めば自動化出来ますよね。
その辺は大事な貴方のリソースを使う程高尚な作業じゃないと思うので
暇が出来たら勉強して組み込んでみてはいかが?