DEV Community

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

Posted on

How do you use git when working solo?

Top comments (67)

Collapse
 
ben profile image
Ben Halpern

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!

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

Collapse
 
rubiin profile image
Rubin

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

Collapse
 
spo0q profile image
spO0q 🐒

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

Collapse
 
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 😆

Collapse
 
dendihandian profile image
Dendi Handian

pretty much the same

Collapse
 
leob profile image
leob

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

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

Collapse
 
nissikazembe profile image
Nissi Lawrence Kazembe

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

Collapse
 
lukewestby profile image
Luke Westby

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

Collapse
 
randomblock1 profile image
Benjamin G.

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

Collapse
 
fyrfli profile image
Camille

2:00am - “saving here to continue tomorrow”
10:00am - “done”
6:00pm - “mobile styling done”
6:01pm - “oops forgot something”
… etc

Collapse
 
areskul profile image
Areskul • Edited

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?!

Collapse
 
tbroyer profile image
Thomas Broyer

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

Collapse
 
sanampakuwal profile image
Sanam

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
Areskul

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"?

Thread Thread
 
sanampakuwal profile image
Sanam

Dev is not totally unstable! It's yet not ready for production. All internal phases (dev, test, regression) will be carried out here and finally will be merged into stable branch (name as per your preference)

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

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

Collapse
 
taufik_nurrohman profile image
Taufik Nurrohman • Edited
  • 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
Collapse
 
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.
Collapse
 
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