DEV Community

Cover image for How do you use git when working solo?
Ben Halpern
Ben Halpern

Posted on

How do you use git when working solo?

Discussion (66)

ben profile image
Ben Halpern Author

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!

yechielk profile image
Yechiel Kalmenson

I generally don't branch off main unless I'm doing a long and fairly involved feature. Mainly so it should be easy to throw the work away if it turns out to be too hard or too long to keep working on.

rubiin profile image

I second you Ben. I do maintain some quality commit messages following the conventional commit. That would help me in future track what went wrong and on which commit rather than scratching my head for an hour or two

saptakbhoumik profile image

I do the same:)

jmau111 profile image

I also branch off on very few occasion when working solo, but I use tags.

renanfranca profile image
Renan Franca

I do the same. But I started to create branches to be committed to releasing a new version to myself ๐Ÿ˜…. So doesn't feel like an endless project ๐Ÿ˜†

dendihandian profile image
Dendi Handian

pretty much the same

leob profile image

Same for me - using it essentially in the same way but rarely using other branches than master.

rrampage profile image
Raunak Ramakrishnan

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.

nissikazembe profile image
Nissi Lawrence Kazembe

Interesting usage, I will definitely adopt this. Quite a handy debugging method especially for side projects.

lukewestby profile image
Luke Westby

lots of commits to main with messages like โ€œchangesโ€ and โ€œmore changesโ€

randomblock1 profile image
Benjamin G.

70% "fix"
25% "added [thing]"
5% random rambling
100% useless to anyone but me

fyrfli profile image

2:00am - โ€œsaving here to continue tomorrowโ€
10:00am - โ€œdoneโ€
6:00pm - โ€œmobile styling doneโ€
6:01pm - โ€œoops forgot somethingโ€
โ€ฆ etc

jankapunkt profile image
Jan Kรผster

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
areskul profile image
Areskul • Edited on

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
Enter fullscreen mode Exit fullscreen mode

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

alias gitu="git commit -a | git push"
Enter fullscreen mode Exit fullscreen mode

and when I need add modification to previous commit.

git commit --amend
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

git checkout 0.4.4
Enter fullscreen mode Exit fullscreen mode

What about you?!

tbroyer profile image
Thomas Broyer

I really don't get that main vs dev in git-flow.

sanampakuwal profile image

Ongoing development features branches will be merged to dev regularly and dev will be merged to main when dev becomes stable and mergable.

Thread Thread
tbroyer profile image
Thomas Broyer

That doesn't explain (and even less so justify) why you do it.

Also, does that mean that dev is not always in a releasable state?

Thread Thread
areskul profile image

Yes, dev is unstable !

Thread Thread
tbroyer profile image
Thomas Broyer

You're saying this as if it's a feature. In projects I work on, they could be released/deployed almost at any time (at a minimum they are deployable to a testing/demo server), and if the tip of the branch happens to not be, we can easily deploy/release a version from a few commits earlier. Tag it and call it a day. I don't get that "merge dev to master" process.

Are you really saying your dev branch can at times be in a state where you'd say about it: "oh yes, this is currently entirely broken, but don't worry, we'll fix it in time for the scheduled release"?

hoshiharetsu profile image
Rebecca DuPont

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.

jake_nelson profile image
Jake Nelson

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

taufik_nurrohman profile image
Taufik Nurrohman • Edited on
  • 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
theaccordance profile image
Joe Mainwaring
  • 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.
renanlazarotto profile image
Renan Lazarotto

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.

jeremyf profile image
Jeremy Friesen

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.

zferguson profile image
Zachary Ferguson

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

bugsysailor profile image
Bugsy Sailor

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. ๐Ÿคทโ€โ™€๏ธ

iasjem profile image

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.

tbroyer profile image
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.

darkwiiplayer profile image
๐’Šฉ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.

snikhill profile image
Nikkhiel Seath

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

guitarino profile image
Kirill Shestakov

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.

sdevore profile image
Sam DeVore

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 ;)

arsalakhan profile image
Arsala Khan

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.

kevinleebuchan profile image

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.

dumboprogrammer profile image

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 .-.

salyndev0 profile image

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.

geraldew profile image

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.)

terabytetiger profile image
Tyler V. (he/him)

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 ๐Ÿ˜…

jonasbn profile image

I do a lot of 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.

anishde12020 profile image
Anish De

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.

matthewpersico profile image
Matthew O. Persico • Edited on

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.

rohithv07 profile image
Rohith V • Edited on

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.

mmn6d6d6e profile image
Rahman Nur Hadi

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.

shahednasser profile image
Shahed Nasser

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 ๐Ÿ˜…

tandrieu profile image
Thibaut Andrieu

I call my main branch master.

jeh212 profile image

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.

chadwinjdeysel profile image
Chadwin Deysel

git push origin master ๐Ÿ˜‚๐Ÿ˜‚

atulcodex profile image
Atul Prajapati

In very cool manner

checkout my github profile atulcodex

sherrydays profile image
Sherry Day


nbourdin profile image
Nicolas Bourdin

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

thomasbnt profile image
Thomas Bnt

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

rubiin profile image

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

dagr8 profile image

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).

agiksetiawan profile image
Agik Setiawan

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

rubyrubenstahl profile image
Ruby Rubenstahl

So haphazardly that I embarrass myself.

mustabelmo profile image
Mustapha Belmokhtar

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 ๐Ÿ˜

cerchie profile image
Lucia Cerchie

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).

jaecktec profile image

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.

fish1 profile image
Jacob Enders

git add .
git commit -m "update"

deepaksinghkushwah profile image
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.

joelbonetr profile image

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

mathieuhuot profile image
Mathieu Huot

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.

karamfd profile image

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.