I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…
Rebasing private code to clean up WIP commits and break it into logical steps is healthy and a very good practice. But as Linus himself says in the linked mailing list post[1], just don't rebase public code. "In other words, you really shouldn't rebase stuff that has been exposed anywhere outside of your own private tree. But *within* your own private tree, and within the commits that have never seen the light of day…
Git is my buddy: Effective Git as a solo developer
111–120 of 212 posts
Re: Git is my buddy: Effective Git as a solo developer
#112Re: Git is my buddy: Effective Git as a solo developer
#113Re: Git is my buddy: Effective Git as a solo developer
#114I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…
Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier…
Re: Git is my buddy: Effective Git as a solo developer
#115Earlier quoted context omitted.
> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…
Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.
That said, it can be a lifesaver when I didn't make an explicit commit, then started doing stuff, then realized "ok this got out of hand AND I wish I could go back five minutes but it's gonna be annoying."
Re: Git is my buddy: Effective Git as a solo developer
#116Earlier quoted context omitted.
Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier…
> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (…
I suspect this is the type of tendency which goes away with experience, but it makes git a lot less useful. My commits won't really tell you what changed; the most they can tell you is the primary change I was working on.
Re: Git is my buddy: Effective Git as a solo developer
#117I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…
> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…
Re: Git is my buddy: Effective Git as a solo developer
#118As a solo developer/potentially newbie, I think it's better to spend brain cycles on actually learning programming, than to learn the idiosyncrasies of some crazily complex tool like git.
Re: Git is my buddy: Effective Git as a solo developer
#119I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…
If it's working for you to produce software how you need, then it's working.
But I would say it's building up habits of using git that would not transfer well to a multi-person team. That may or may not matter to you.
OP's usage is interesting, I think by and large they are transferable to a multi-person team, they are still good habits, or on the _way_ to good habits or _similar_ to good habits with a multi-person team. The one difference is how much easier it is for a solo developer to "rewrite git history" without disrupting others, in OP we see it done with abandon.
But in general the way OP is thinking about things -- what they are trying to prioritize how -- are things that apply to a multi-person team too. Keeping commit history readable, keeping branches cohesive, etc.
Your practices are... not. Which doesn't make them terrible, but it means you are developing habits you'd probably have to revise when/if working on a multi-person team.
Re: Git is my buddy: Effective Git as a solo developer
#120Earlier quoted context omitted.
> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…
Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.