He/Him/His
I'm a Software Engineer and a teacher.
There's no feeling quite like the one you get when you watch someone's eyes light up learning something they didn't know.
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.
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
β’ Enjoy javaβ spring bootπ and OSS π―
β’ I love implementing automated testsπ
β’ @jhipster lite contributorπ€ and loverπ β’ Proud dad πΌ
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 π
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.
I never know what to write in these things. I should probably spend some time coming up with some snippets about me. I am not new to front end coding, but I am severely rusty.
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"?
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)
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
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.
Hiya! I'm a fullstack developer, with experience with PHP, JavaScript and Go. I'm also an Android enthusiast and I like pretty much everything related to tech.
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.
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
Creating tech and art to serve humanity with love, joy & hope. Studied at UofT, interned at Google, founded Grey Software to democratize education through open software.
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.
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.
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.
Top comments (67)
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!
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.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
I also branch off on very few occasion when working solo, but I use tags.
I do the same:)
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 π
pretty much the same
Same for me - using it essentially in the same way but rarely using other branches than master.
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.
Interesting usage, I will definitely adopt this. Quite a handy debugging method especially for side projects.
lots of commits to
main
with messages like βchangesβ and βmore changesβ70% "fix"
25% "added [thing]"
5% random rambling
100% useless to anyone but me
2:00am - βsaving here to continue tomorrowβ
10:00am - βdoneβ
6:00pm - βmobile styling doneβ
6:01pm - βoops forgot somethingβ
β¦ etc
I always make a main, and a dev branch.
I fork the dev branch in many feature/* branches that I merge to the dev.
Heavy usage of "gitu" alias to push to remotes and mirrors.
and when I need add modification to previous commit.
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).
In case I need to revert bad changes that went into main branch(production)
What about you?!
I really don't get that
main
vsdev
in git-flow.Ongoing development features branches will be merged to dev regularly and dev will be merged to main when dev becomes stable and mergable.
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?
Yes, dev is unstable !
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"?
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)
Yes, for several reasons:
I build out fantastic CI/CD processes for features branches and pull requests, then ignore them and commit straight to main.
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.
git status
git diff
q
git add .
git commit -m Update
git push -u origin main
git rebase -i HEAD~10
reword
reword
reword
squash
squash
squash
git push -f
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, adev
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 intodev
ormain
, mostly used to try new things without actually messing with working code.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
goodI 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.
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.
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 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. π€·ββοΈ