How do you use git when working solo?

Comments

[Mark Smith]

Hi, new to all of this. What's a good resource for getting started with GIT? There is a _Guide to Git for Solo Projects _by Abhinav Saraswat on Medium but it's behind a paywall and I'm trying to curtail expenditures at the moment. Thanks for any suggestions you might have.

Mark

[Ruby Rubenstahl]

So haphazardly that I embarrass myself.

[Jonas Brømsø]

I do a lot of Exercism.io exercises, I always initiate a Git repo, so I can experiment when my proposed solution gets stuck or I want to try another path. I do not branch a lot, but I have the option and I do it once in a while.

For my GitHub projects I try to keep everything in branches and even send PRs to myself, I got that as a recommendation once from somewhere and it works great.

[Jem]

What I usually do is like this following this format: -

Then I list down other minor significant changes I did included also in current commit.

Example commit:
Develop top navigation bar - /top-navbar
- Added new src: brand image

Just my preference when working solo. I do not make changes directly to the main branch except if current phase of the project is considered done.

[Matthew O. Persico]

The same way that I work in a team; I create a new worktree and branch for each change I want to make, work through it, PR it, merge it. In this way, if I have to drop the idea for a bit and then get hit with a bug, I can wt/br/PR the bug and don't have to worry about getting that other idea OFF the main before applying the fix, and putting it back after.

Also, I keep my dotfiles and utilities in a git repo. When I clone that down to a new machine, I immediately create a new branch with that hostname. In that way I can make changes on whatever machine I need them and PR/sync all the branches before pulling on each machine.

Branch discipline is best when it becomes second nature; the more repetitions, the better. Why would I keep doing two different things when I can do the same thing in all situations? Easier on the mental dispatch that way.

[Deepak Singh Kushwah]

Create branches for each feature, merge them to master on finish feature and remove unnecessary branches. Not good at meaningful commit messages. Like to keep repo clean.

[Thomas Broyer]

I actually don't work differently on solo projects or team ones: I rarely branch off of main either, good commit messages, rewrite history often until pushed. This probably because we use Gerrit at work, so no "pull request from a branch".

I do work differently when contributing to FLOSS projects though: branch early because I know I'll have to make a PR from that branch.

[KevinLeeBuchan]

I have a "dev" branch that I use while I'm working on something new, with regular commits. When I'm done with what I was trying to accomplish, I will clean up the commits and often collapse them into one or two, then merge into main. If I'm trying something really new, I might use a feature branch so I can discard the whole thing easily if I need to.

[𒎏Wii 🏳️‍⚧️]

I don't really branch from master at all when working on my own and do a lot of force-pushing. I attempt to do force-pushes within ca. 10 minutes of the first commit that would be replaced to reduce the chance of any random person cloning the repo in that precise moment to something reasonably low.

As for commit messages, I usually don't write more than the first line and occasionally add a paragraph explaining my rationale if it isn't obvious from the change itself.

[Nicolas Bourdin]

git add . && git commit -a --amend --no-edit && git push origin main -f
😈