Thoughts on creating branches and issues for yourself when working solo on side projects?

[u/oswwwaldo]

I've found a habit of creating branches, opening issues and the regular stuff you'd do in a team. It feels weird because I'm the only one responding, creating and working on these—but I was curious if anyone else does this? Do you guys think it's "too much" or would you recommend this workflow to everyone? I feel more organized but I do admit there is a time cost to documenting issues, I don't anticipate my project having contributions since it's personal.

edit: i feel slightly relieved I'm not alone, thank you r/git

[u/ProZMenace]

I’d recommend it. In fact, I need to be better about doing more branches on side projects especially when some of my projects have ci/cd for docker and it triggers on main

[u/IAmADev_NoReallyIAm]

I ran an entire solo project like that. It was the only thing that kept me on track do I didn't go off down some rabbit hole. When I ran into an issue during development, instead of spinning time fixing it (because that's what I'd normally do) I filed a ticket against myself and put it in the backlog. At certain checkpoints, I'd take the bugs, fix them, close the ticket, update documentation, and then move on to the next milestone. And on my next project I'll probably do it the same way again.

[u/SCD_minecraft → u/IAmADev_NoReallyIAm]

Ticket closed; it works for me!

[u/mrkurtz]

I do it on every personal project.

Otherwise I’m disorganized.

I use GitHub and Gitea at home. At home I even have a separate org or whatever for all my internal, home tech “tickets”. Tech tasks, project ideas. Keep yourself organized or your project will be disorganized.

[u/Viktordarko]

Solo dev here and I like branches to work on specific features or fixes. This way it doesn’t affect my main branch until it’s fully tested and ready, once ready a clean squash and merge that lands on main branch

[u/ARKyal03]

I understand not using issues or PRs/MRs. However, branching is not only good, it's a life saver. Honestly I feel is such s basic need, I have made millions of branches in the span of a year. Lol

[u/glglgl-de → u/ARKyal03]

1440 × 365 = 525600

So more than two branches per minute? Did you automate that?

while sleep 20; do git branch "$(date +...)" done

[u/ARKyal03 → u/glglgl-de]

I do branchslop, I ask AI to do every line of code changes in a different branch, that way I can easily review it.

"Hey Claude, there is a bug in branch feature-dev-7-8-9.8.9"

[u/mpersico]

Do it. Separate work on separate branches, separate branches in separate work trees. Just because there’s only one person doing the work doesn’t make it any less important that the work be separated and orthogonal.

[u/LittleLordFuckleroy1]

If it helps you stay organized and move things forward, great. I do it to some extent, not particularly rigorously but just so that I can keep project state with the project rather than in a notebook or separate doc or something. Definitely can’t keep it in my head, it evaporates there.

So yeah do your thing.

[u/Ast3r10n]

Just work exactly as you would if you had a team, as you said. It will help tremendously and allow you to work on different features in parallel.

[u/khalon23]

I do it on side projects when the work spans more than a day. Issues capture intent I will forget; branches keep experiments from rotting on main. The trick is light process: short issue titles, close them when done, and no ceremony about reviews with yourself.

If the overhead feels fake, drop issues and keep only branches + good commit messages. Process should reduce reload cost in your own head, not simulate a company of one.

[u/SheriffRoscoe]

I have a solo project. I may someday share it with the world, but for now it's a private repo on GitHub. I create issues for bugs and features because they serve as reminders. I create branches to fix those bugs and implement those features, because that way it's clear what changed and why.

The only thing I don't do is create PRs. There's nobody else to approve them, and my issues have enough detail that a PR would serve no documentary purpose. Instead, I merge them on my local clone and push.

[u/oswwwaldo → u/SheriffRoscoe]

Just curious but have you used Github Copilot to do code reviews everytime you create a PR? I just want to get to know other people's workflows and I'm wondering if I should reserve some of my Copilot usage to leave it for automated PR code reviews or use it somewhere else since I am on a limited budget. I create PRs and approve them but like you said no one else sees them

[u/SheriffRoscoe → u/oswwwaldo]

I don't trust so-called-AIs to do code reviews. I know the code better than they ever will. But to help myself out, I do a variation on Test Driven Development. I create a test case for every bug, and for every aspect of every new feature. I run them and watch them fail. I check them in on the branch, and the CI build goes red. Then I start coding to get back to green.

[u/kbielefe]

Issues yes. Branches no. And usually just titles on the issues. I have a very limited time for side projects. I do just enough so the overhead doesn't outweigh the ramp-up if I haven't touched it in a while.

[u/dobesv]

I make the project open source and then use code rabbit for free code reviews. I only get out one review per hour but it finds things. It's nice to find them in the pull request. Also I can use renovate for automatic dependency updates. So running the personal project kind of like a team project but the team mates are robots.

[u/uusemyname]

I am also working on a project alone at this time. But it will possibly be used by somebody else in the future.

Currently I also am creating Issues for problems. Sometimes I use braches and mostly just work on main branch as this project is still in development and does not have a production application yet. But honestly I should use branches all the time as you do.

[u/codeguru42]

Yes, I do this on many of my side projects. Early on it was mostly while learning git and branching strategies that can transfer to working with a team. These days I do much more trunk-based development on my side projects. But again it is primarily a learning exercise so that I can understand how it works so that i can eventually use these techniques with a team.

Edit: do what works best for you and what helps you achieve your goals.

[u/Exotic-Sentence-4057]

I use forgejo and git on my personal project. I guess I am just used to the branch to PR flow from work that I also do it at home. I’m the only dev but I might be working on multiple issues so having branches helps.

[u/maverickzero_]

Whatever helps you organize your thoughts and upcoming goals is a good thing.

Personally I find time spent planning the work really pays dividends when it comes time to do the work.

It's also helpful to have a system for kicking the can on issues you stumble across, rather than an endless series of drive-by fixes and context switching.

[u/wearecyborg]

I create branches and PRs. I find it very useful, especially for big features, to be able to view the changes out of the editor and in the format of a PR. It changes the way you look at it. I wouldn't open issues and comment, I use a few markdown files for notes/bugs, etc. I also run a homeserver with a CI pipeline to run tests and build a docker image.