Anyone know a clean way to have nested git projects? Every time I make a commit in B (the nested git project), there are changes in A. Previous searching of a solution was hard to understand..
Git is my buddy: Effective Git as a solo developer
21–30 of 212 posts
Re: Git is my buddy: Effective Git as a solo developer
#22I'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…
Some of the sophistication you are 'missing' is there as a solution to scaling problems, to business problems (do you need to track/fix customer/client issues?), or to other problems that may not be as critical for solo devs. Some of the other is best practices which you are missing out on. You might want to take a look at what some 'best-practices' are and see which might improve your coding. Simple things like tagg…
For me, those cases of running out of time or inspiration before I get to the end of the task are incredibly common (basically a daily occurence). I understand it might be rare for you, but for me (and I would think others) it's the default state of programming.
When I'm really getting going I flow through a ton of work and only stop when I hit a time limit, so I expect to finish in the middle of a task whenever I start coding.
Re: Git is my buddy: Effective Git as a solo developer
#23I'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…
I think what you're doing is fine especially if you're just coding for yourself. I'm perfectly happy with slightly more expressive commit messages like "LoadData appears to be working; still hacking away at TransmorgifyData", followed eventually by "stabilized TransmorgifyData".
I think it's when you start syncing with other people over multiple days that people start insisting that a commit should (compile), be atomic, tested, etc. What they're really looking for at that point is that incoming changes be easy to understand and modular and possibly easy to omit if some code change is causing them trouble for a moment.
Re: Git is my buddy: Effective Git as a solo developer
#24When I was a new developer and first learned Git, I felt compelled to use Git the "right" way. That is... small commits with clean messages, things described in this and other posts.
But, as I spent more time programming, I developed different Git habits for different situations:
- Solo explorative work: working on a feature, many small commit messages create nothing but noise. Trying to come up with wording for these commit messages is mostly a drain on my mental energy: there is an infinitesimal chance I'll need these commits later. In such cases, I prefer to maintain large "checkpoint" work-in-progress commits that are the result of near-continuous `git commit --amend`s so that I can use `git status` to see what's changed since my last checkpoint, and easily revert to the last checkpoint. If this fails me, I can almost just as easily refer to the reflog to find some changes. The reflog, in my opinion, is an extremely under-utilized tool. `git diff HEAD@{2}..HEAD@{0}` allows me to see what's happened in the the last two times that I updated my checkpoint. Since this is active work I'm doing right now, I have a good sense of what happened and when, all without tiresomely writing commit messages that will be a bunch of gibberish in two days. When I'm satisfied with with the work on a checkpoint commit, I reset the branch to the previous real commit, and then incrementally create real, meaningful commits from the accumulated work, that have some chance to be useful to me in the future.
- Working on patches and bug fixes for live systems or production libraries: small, atomic commits that include tests for the patch are the only way to go. I believe the "correct Git" approach that is widely espouses is targeted to this use case, but not explorative feature work. Or maybe that's just me.
Wondering if anyone else codes like this.
Re: Git is my buddy: Effective Git as a solo developer
#25Anyone know a clean way to have nested git projects? Every time I make a commit in B (the nested git project), there are changes in A. Previous searching of a solution was hard to understand..
Perhaps you're looking for something like submodules?
Just create a Git submodule, and then push from within the submodule, like so: https://stackoverflow.com/a/5814351.
Re: Git is my buddy: Effective Git as a solo developer
#26I'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…
Yep, small disciplined commits take valuable time. If you rarely revert or get other benefits from them they might be a net loss for you. Especially in solo projects when you can keep a lot of what's going on in your head.
It's a bit like testing - there's a lot of posts about where you need them and not many discussing where you don't.
Re: Git is my buddy: Effective Git as a solo developer
#27I'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 to understand, but because it makes us feel better about ourselves. That's a red flag. Understanding how you got to the goal -- encoding all the fumbles and disoriented thoughts right in the commit history -- that can be a genuine benefit to the reader. Who do we really help by pretending that we're more organized, coherent, and linear than we actually were?
Re: Git is my buddy: Effective Git as a solo developer
#28I'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…
I do the same. I use branches almost exclusively for features that won’t be done for a while and won’t make it into production until then.
Re: Git is my buddy: Effective Git as a solo developer
#29I'm happy for this person if this works well for them. For me, no thanks. One of the reasons I feel much more productive as on my solo project than at work is that I don't have this kind of overhead. I don't need to write tests for everything (I write them just where they add value). I don't need to follow some strict branching standard. I can commit in chunks that make sense to me, and adjust as needed for the situation.
From my perspective, a lot of this kind of rigid process is important and valuable when you are working with a team, but is counterproductive when it's just me. I know the tradeoffs of the corners I cut. I have the experience to know, for example, that's it's not a safe assumption that I will understand my own code a year (or even a month) from now. But the solution to that is to throw in some freeform comments that jog my memory; not to implement a heavyweight documentation system.
Everyone should work in the way that makes them the most productive and happy, but I don't think it's a good idea for solo developers to bring in practices that are designed for team collaboration without really understanding what value they will get from the extra effort.
Re: Git is my buddy: Effective Git as a solo developer
#30Relevant useful tool: diff2html - a CLI that lets you quickly see an HTML output of all uncommitted changes you've made (or compare against a branch).
I have an alias `alias diff='diff2html -s side --ig package-lock.json'` which shows a side-by-side comparison of my changes. Highly recommend!