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.
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
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.
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.
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 ;)
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.
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.
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.
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.
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.
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.)
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.
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.
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 .-.
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.
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.
French software engineer with 15 year experience on 3D data visualisation and processing. Lots of C++, and switch to Unity recently.
I like when it run fast ๐
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 ๐
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.
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.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
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.
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).
French web developer mainly but touches everything. Volunteer mod here at DEV. I learn Nuxt at this moment and databases. โ Addict to Cappuccino and Music
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.
HTML, CSS, Bootstrap, XML, ajax, react js, WordPress, Magento, Shopify, Photoshop, Camtasia, SEO & learning new skills every moment ๐จ๐ผโ๐ป | I believe in learning and sharing with others ๐ด
Personally โ I rarely branch off of
mainwhile 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
mainunless 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. 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
mainwith 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
mainvsdevin 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 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 statusgit diffqgit add .git commit -m Updategit push -u origin maingit rebase -i HEAD~10rewordrewordrewordsquashsquashsquashgit push -fFor 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
gitgoodI stay in the middle ground between using git improperly and using git how I use at work.
I have a
mainbranch that have the latest working code, adevbranch with stuff I working on actively and every now and then I have a feature-specific branch that I may or may not merge intodevormain, mostly used to try new things without actually messing with working code.I actually don't work differently on solo projects or team ones: I rarely branch off of
maineither, 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.
For the most part on client projects I do tend to maintain just
mainanddevelopbranches 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.
For personal projects, I usually commit everything directly to
mainbut 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
mainbranch 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. ๐คทโโ๏ธ
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:
masterand keeping my commit messages: Imperative and <50 characters in lengthI don't really branch from
masterat 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.
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.
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.
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.
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.)
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.
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.
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 .-.
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.
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.
I call my main branch
master.git push origin master ๐๐
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 ๐
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
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.
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.
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.
So haphazardly that I embarrass myself.
git add . && git commit -a --amend --no-edit && git push origin main -f
๐
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
Always two branch for features : main and dev, but I can work direclty to the main if is a small changing.
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"
In very cool manner
checkout my github profile atulcodex
Poorly
The only thing I can think of is my work notes. The git log will always be a straight timeline, unless there's another me in a parallel universe.
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.