How do you use git when working solo?

Personally — I rarely branch off of main while working solo, but I do maintain high standards of committing regularly with good messages.

That's high level, but would love to hear a few more detailed answers from folks!

For solo projects, I use git as a journal using meaningful commit messages and to mark "save points" where I know the code is working fine. I use git tags as a memorable way to mark the aforementioned good commits. I do not make as much use of branches as I should because it is easy to checkout to a safe commit using tags.

lots of commits to main with messages like “changes” and “more changes”

Yes, for several reasons:

• documentation / log / tags
• backup to origin or other upstream
• easy to make a solo git project a collaboration project
• ci/cd tooling + tagged releases
• keep git skills up to date

I always make a main, and a dev branch.
I fork the dev branch in many feature/* branches that I merge to the dev.

git branch feature/vite
git merge feature/vite

Heavy usage of "gitu" alias to push to remotes and mirrors.

alias gitu="git commit -a | git push"

and when I need add modification to previous commit.

git commit --amend

And I try to write good commit messages following Angular conventions.

When I'm satisfied with my work I tag it (for further fast version reverse).

git tag 0.4.5

In case I need to revert bad changes that went into main branch(production)

git checkout 0.4.4

What about you?!

I use git for organizational purposes when working solo. I don't really stem off the main branch, but the commenting and commit notes help to keep my multiple projects organized and remind me where I was when I last left off. Overall, I think it's good practice to practice how you would work in a team environment, so I do not do sloppy messages when committing.

I build out fantastic CI/CD processes for features branches and pull requests, then ignore them and commit straight to main.

• git status
• git diff
• PageDown PageDown …
• q
• git add .
• git commit -m Update
• git push -u origin main
• Repeat.
• git rebase -i HEAD~10
• reword
• reword
• reword
• squash
• squash
• squash
• git push -f

• I still create feature branches to commit changes
• I squash on merge. This results in a smaller main trunk with better quality messages and clear points to revert.
• Releases are tagged off of the main trunk.

I stay in the middle ground between using git improperly and using git how I use at work.
I have a main branch that have the latest working code, a dev branch with stuff I working on actively and every now and then I have a feature-specific branch that I may or may not merge into dev or main, mostly used to try new things without actually messing with working code.

I use git on almost all of my projects. And I get sloppy compared to my work git usage. But the main goal with these personal git repositories is that I could use git bisect to find a breaking change. The commit messages are very useful, but it requires more discipline than I'm often bringing for my persona repositories.

For consistency's sake, I try to mirror what I do at work (practice makes perfect and all that) other than maybe branching. Gotta make more commits for that sweet sweet dark green block on my activity graph :)

I haven't heard about tags though, I'm definitely gonna have to check it out! Still got to git good

I usually work from two different computers, so primarily it's a way to keep all my code nice synced.

I'll create a new branch occasionally, mostly when I'm just experimenting with new design of functionality.

It saves my butt once in a while when I delete something I shouldn't have, or need to reference some file history.

And that's about it. I haven't had a shared Git project in years. Could use some help though, that would be nice!

However, I use Github endlessly. It's where I keep countless project notes, whether it be development related, business related, or product ideas. It's a pretty darn good place to store all that stuff.

That's what I got. 🤷‍♀️

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.

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.

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.

I sort of got addicted to git flow and conventional commits.
So, it is feature branches and feat:, chore:, style: for me.

But, my old projects have been committing to: master and keeping my commit messages: Imperative and <50 characters in length

For personal projects, I usually commit everything directly to main but I have good commit messages and I commit regularly. I do branch off sometimes, especially if I wanna do a bigger refactor.

I also often use git for stuff that I never push anywhere, like personal notes, dotfiles, some config files, etc, just to keep a historic record with ability to locally restore back if I ever need to.

For the most part on client projects I do tend to maintain just main and develop branches and have a live and staging sites for the client reflect those branches. As much as possible the deployment of both is automated (laravel forge or GitHub actions) I will use feature branches when doing some new feature work to allow a release to be independent of new/experimental work and can shift the deployment to the 'staging' server to reflect that branch for client preview. Client approval is done via a pull request that they then can approve and merge and then the automation handles the deployment to the live site (this is for GitHub git repositories) When collaborating with other developers or designers I will often follow something more like git-flow but that is not really the nature of this question ;)

I try to commit important checkpoints so if something breaks I can check the log and do a hard reset to the last commit that worked. Since I enjoy finding creative ways to refactor code, this is super useful if I go down the won't refactoring path.

I don't stress too much about being religious with feature branches. I let the feature branches evolve naturally with the project.

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.

I use meaningful commit messages with checkpoint(like #1 or similar).While I push to a test branch and if everything is okay I merge it with the main branch.I sometimes use git tags.

All of this is true unless I'm working on a personal project .-.

I have main branch and everytime I have new idea about new future or a branch new components that can be anywhere in my app I would create a new branch. Ex: "In-app buying or dark mode, new animation" . If some changes can break the app I would create new branch.

For my solo work I use Git commits to separate out and annotate different kinds of changes. So the desire for each commit to only mean one kind of change at a time has actually changed my approach to editing. Occasionally I will have an intensive reworking session where the sheer number of simultaneous changes breaks that rule but the idea that a meaningful commit message will cover that still guides my edit point.

I've had just one time when I embarked on more changes than I could manage in a single session, and so belatedly wished I'd set out a branch for that.

In practice, I make a distinction between the commits and the pushes (to Gitlab) because my full scale testing gets done in a different instance that first pulls the latest change from Gitlab.

So I might make a series of commits, but the push may wait until I have a new point to be tested.

Do note that as I'm old school, by "testing" I mean actually running the code on real stuff. I'm not into writing "test code".

FWIW in my "work" environment my code only sees git as a form of backup (or sometimes to share as example). I still can't see any way for git to have a role in "data script" coding. (There's much more I can say on that topic, but it is quite another topic.)

For some of my earlier work projects, I have a dev, test, and prod branch set up and do the full dev > test > prod deployment cycle - although now that the main rollout is done and it's mostly small maintenance updates I don't have users do a proper testing of the test branch any more.

For newer projects I've been using a single branch and only branching if I want to do a major overhaul update - for example I overhauled the CSS to use Tailwind of one and I did that all in a side branch so that I could make sure they were okay with the minor changes before committing to prod 😅

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.

That is a great question. I mostly work solo but git helps me keep a track of my projects. Everything from the simple ability to put my code up on GitHub to be able to revert, branch out and make experimental changes, etc. helps me a lot and hence I use git with all my projects. I also commit my changes regularly and if I ever need to refer back to an older version, it helps me a lot.

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.

While working solo, I will try a bunch of things like creating different branches, merging them, seeing the green getting darker in my contribution bar😂, good commit messages.
And moreover I am trying to get more comfortable using different commands and the errors that get popped up.
I mainly use it for learning purpose.

For me, working solo is pretty much working as a team with my future-self.

I'm working on plenty project at the same time, and mostly are the "legacy apps". And remembering details isn't my strong point.

So: as organize as possible as long the constraints allow it. Branching off main branch, dev branch, hot fixes branch, squash the "oh I should've done this" commits, clear commit messages, etc.

If it's something completely personal (not a tool to be used by others), then I'd probably use the master branch for everything with a lot of the same repeated commit messages 😅

I call my main branch master.

I use git as a checkpoint, and on my commits I just mention what I was doing before, Because after 2 or 3 days definitely I won't remember where I left off. When I finish my task I do the rebase to remove the giant commits msg haha hahaha and write short msg.

git push origin master 😂😂

In very cool manner

checkout my github profile atulcodex

Poorly

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

Always two branch for features : main and dev, but I can work direclty to the main if is a small changing.

Well tbh, I dont create branch for issues that I know would not take a big amount of time and lot of changes. For something that would, I go for branching

Use it as if you were in a team. Branch then commit a lot ( as a journal like others mentionned) do not push until you have easy to read squashed commit(s).

Usually I use 2 branch, dev and main. Branch dev for staging test and main for production. I use CI/CD tools like Jenkins for deployment

So haphazardly that I embarrass myself.

for my side projects, I use trello as my kanban board, then each card is linked with a git branch.
I use pull requests to keep tracking the evolution of the project.
may look crazy but it works 😁

Depends on whether I'm going to be deploying something (in which case, I'd make branches) or I'm just working on something local for fun (commits straight to main).

Lots of commits with 'something'
Once it's done I squash the entire history write 'initial commit' and force push.
After that I am doing proper commit messages, but always to main.

git add .
git commit -m "update"

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.

Pushing directly into Master or to Develop if I've already set up a pipeline and then merging to Master when it suits.

I mostly stay on the main branch. I sometimes use good ethics (commit often with meaningful messages). I primarily use git as part of a ci/cd pipeline in Jamstack projects.

I use the command line exclusively and Main branch. I mostly build simple projects for learning purposes, so I have no use for multiple branches.