3
2
個人開発のときにGitのブランチは切りますか?
自分はmasterで作業しています。わざわざ、ブランチを切ってプルリクを出してマージするのがめんどくさいので。。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答9件
#1
総合スコア1581
投稿2024/01/19 04:08
自分の場合,CI/CD組んでてmasterにcommit / mergeされた瞬間にリリースされるようにしてるので開発用ブランチがあります.この場合はmasterで作業するのはNGですが,これ以外のケース,つまり対外的に何もリリースしないならmasterで作業してもブランチ切りまくってもなんでもアリじゃないですかね.
#2
総合スコア4443
投稿2024/01/19 13:32
まず、「プルリクエスト」はGitの機能ではありません。GitHubなどの特定のリポジトリ管理システムに備わっている機能です (同様に「フォーク」などもGitの機能ではありません)。プルリクエストを利用しなくても、git mergeコマンド (あるいは利用しているGitクライアントでの同等の機能) を使えばブランチのマージはできます。
さて、開発の過程で何らかの機能追加や変更作業のためのブランチ (フィーチャーブランチ、トピックブランチなどと呼ばれるもの) をmain (master) ブランチとは別に作成し、そこで作業してみて有望そうならマージするというのは、個人開発でも有用な方法だと思います。マージするまではmainブランチに触れなくていいため、何度でもやり直しがききますーー試してみた変更が気に入らなかった、思ったような結果が出なかったときは、そのブランチを捨てて別のブランチを作ってやり直したっていいのですから。
ブランチを使う方法を複数人のコラボレーションに応用するために種々のワークフローが考案されたりもしていますし、そのためにプルリクエストなどの支援機能が付加されたシステムもあります。しかしGitそのものは複数人での開発に特化しているわけではなく、ブランチの機能は個人の開発でも有用だと思います。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#4

退会済みユーザー
総合スコア0
投稿2024/01/23 00:38
例えば新機能の開発でブランチを切っておくと、開発中に元のコードでバグが見つかった時、すぐに本流に戻しバグを修正しまた新機能の開発を進めるという事ができます。
自記事ですが詳しい解説はこちらを:
GitHubというのが重要らしいと知ったばかりの人のための必要最小限のGitの知識
https://zenn.dev/lamrongol/articles/0f5e69ea459041
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#5
総合スコア6
投稿2024/01/23 01:14
ブランチを切ることで様々なものを並行して試せるため、機能ごとにブランチを作って作業しています。
あとはMasterのコミット履歴をSquash Mergeするためのリリース版用のブランチも作成しています。
リリース用のブランチのおかげで細かいコミット履歴をすっ飛ばしたバージョン管理ができます。
ブランチで作業 -> Masterにマージ を繰り返して
最終版をリリース用に一気にコミットするイメージでしょうか。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#6
総合スコア163
投稿2024/01/23 19:02
「個人開発である」という前提に沿うのならば、回答は「どちらでもよい」という事になろうかと思います。何をどのようにしても自由、それが個人開発の良い所です。
ただし、個人的な見解としては、「ブランチを切っておいた方が何かと都合が良い」と思います。以下に、理由を2つ挙げます。
まず第一に、(#4 のLoranさんも仰っていますが)「割り込みタスクへの切り替えが容易になる」というのが挙げられます。現在編集している対象のコードに何らかの不具合を発見する、という事は意外とよく有る事です。些末な問題であれば後回しという事も出来るでしょうが、セキュリティリスクが有る物だったり、ハングアップする物であった場合等、現在行っている事よりも優先して対応したいという事は有り得る話です。既に複数のコミットを重ねていたとしても、もしブランチを切って作業していたならば、容易に作業を切り替える事が出来るでしょう。
第二に、訓練、或いは練習や復習の為です。今の開発は個人で行っている物かもしれませんが、別の機会で他者と共同で開発を行う事が無いとは言えません。その時に「あれ、どういうふうにやるんだっけ?」では相手に要らぬ迷惑を掛けてしまうという物です。「ブランチの作成や切り替えなんて基礎的な事を忘れるなんて有り得ない」と仰っしゃられるかもしれませんが、基礎こそ軽視出来ない物です。「慌てず騒がず外に避難する」なんて誰でも当たり前に出来そうな避難訓練でさえ定期的に行う必要が有る事からも、それは御理解頂けるかと思います。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#7
総合スコア21397
投稿2024/01/25 09:29
個人開発のときにGitのブランチは切りますか?
私はあんまり切らないですね。
masterをどんどん進めてやる気がなくなったら放置。
しかし、破壊的変更をしたくなる時がしばしばあって
ライブラリを取り替えるとか、大幅にリファクタリングするとか
そういう時はゲームのセーブデータを増やすノリでブランチを切って作業しています。
ブランチを切ってプルリクを出してマージするのがめんどくさいので。
それはGitではなくGitHubの機能なので、
しばらくfeatureブランチで作業したら、masterブランチにmergeコマンドでしれっと統合させてまとめてしまえば良いです。
お行儀よくPRを作って何すんだという話に関して、
Issueを主目的、PRを手段として使うのであればありかと思います。
todoだと思って大量のIssueを作っておき、
それに対してブランチ・PR→即承認マージを適応
PRの1行目でFix #100
(#100はIssueのID)みたいにしておけば、Issue側にもこのPRを作ってやりたいことを推し進めたんやなということがログとして残ります。
やりたい事やアイデアがあったとしても、メモしておかないと忘れてしまう。
なので私は本気のプロダクトならtodoなり紙に書くなりしてどっかにメモは残します。
私の場合は紙のノートにバレットジャーナルでバババっと書き残す習慣があるので個人開発のIssueも使いませんが、これぞというやり方が確立してないのであれば、GitHubのIssue欄を活用してみるのは良い習慣だと思います。
個人開発だったらどうせレビューとか出来ないので
PRを作ったとしても、1秒で承認→即マージという運用になるので弱くはなりますが
その場合はGitHub Flowをちゃんと作ってあげて、CIでテストしてやれば良いんじゃないですかね?
テストコケたら真っ赤になるんで
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#8
総合スコア22
投稿2024/01/26 06:57
「個人開発でもブランチを切らないなんてダメだ!」などと言われて自信をなくして質問されているようでしたら「切らなくても全然OK!」と承認しまくります!!!
それはさておき。
様々な回答を読むことで、質問者もそれ以外の通りすがりの人も「こんな使い方もあるんだ」と気づきを得られれば、それはそれで経験値になるとも思います。
私も個人的には、個人開発でブランチを切ることがありますし、他のコメントを読みながら同じことをやってたりやってなかったりです。
それ以外にも、私の場合は実装方法を調べたり、バグの修正方法を調べたりするうちに、選択肢が複数出てきた場合などに、それぞれ用のブランチを切って試していく使い方が多いです。(これは個人開発でも、業務でもやります)
最終的に採用したもの以外は削除してしまいます。
以上、ご参考までに。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#9
総合スコア270
投稿2024/01/29 02:10
個人開発のときにGitのブランチは切りますか?
私は基本的には切って作業してます!
個人開発であれば、他の回答者様が記されている通り、切る切らないはお任せ(やりやすい方で良い)で良いと思いますが、一応なぜ切って作業しているのかを以下にまとめておきます。(参考にはならないと思います。。。
- 元々Git(Github)に関しての知識がほとんどなかったところからスタートしたので、学習のために細かくブランチを切るクセがついた(その名残)
- 単純にマージしたPRの山を見るのが楽しい(完全主観)
- PRはほとんどタイトルしか記載してないですが、積み上げたPRを見ると達成感を感じられるので楽しい
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。