My commit history as a solopreneur
I've been doing that for about a year now.
I'll be doing that as long as I'm the only one writing code.
No issue, I generally use Webstorm to explore file history but that's quite a rare task.
Every second I would spend on the name of the commit would be a waste of time to me.
I just wanted to share that with you.
Best team practice are not always best solo practices.
Have fun coding!
Trending on Indie Hackers
Whatever works for you in order to get ahead on your business goals, but...
If you don’t add general context to commit messages you’re missing out on a great tool which can help you track times you break things. This value is not limited to teams and helps individuals as well.
I think there’s room to gain from improving commit messages, and there’s a whole grey area spectrum between “ok” and long, verbose messages. You can impose a 5 word cap on your messages, waste little time on them - and still gain something worthwhile.
In general, almost nothing is black and white. Being successful is knowing which shade of grey works for you.
Good luck!
You may be right :)
It has been a year though and I never looked back. Looking at the file history is my favorite tool for such a case (which is quite rare), and it's completely free.
This does work for me indeed and it's the opposite of what a best practice might be in this case.
Looking back at previous solo projects, I never looked back at a commit hoping to understand its meaning without looking to the actual set of change (oh I updated this file to this).
Have fun!
But you talk about not wanting to waste any time.
If you look at the file history you're still seeing all the same commit message. So you will need trawl through them, or try and remember the general time line of when you may have changed some code in that file. If you put a meaningful message you'd be able to just look for that instead of rough date estimations and studying the code.
If it works for you though, fair enough. I like to put some clear commit messages personally and it really doesn't take much thinking about.
I write a descriptive commit message every time I commit and I do it about 10 times a day.
I don’t consider it a waste of time nor does it take very long. Most of the time I just write a short form description of the thing I was just working on. It’s not difficult, it comes out perfectly naturally.
This is a muscle you need to exercise to get better / faster at, that’s all.
I consider this best practice even for solo devs. It is the most basic form of documenting your work.
I second this comment.
I tend to do the same but a little be more specific to the feature...
speaker...
speaker...
speaker...
speaker.. done
add calendar...
add calendar...
add calendar... done
This way if by some chance I introduce breaking changes I can quickly role back to the last "done" feature specific commit. This was after a few big fumbles introduced by new features
For me it would look more like:
"add speaker model"
"add speaker CRUD methods"
"add speaker CRUD endpoints"
etc. if I missed something silly in the specific commit, I will always try to
--amendthe previous commit, so that the commit is more atomic. If it's anything more serious, I'll be more specific about it.Might as well just not use the source control then?
I know you say you never looked back (yet), but let's imagine you need to, how do you anticipate finding something? You also said you will keep doing it as long as you are the only author, but let's imagine someone joins you, how do you think they will be able to navigate your history?
You called it best solo practice, and as (sometimes) a solo developer myself I'd like to understand why.
Oops I didn't intend to make it general at all. I was merely pointing that as a counter-intuitive aspect of my workflow, this best practice for teams, was of no use to me as a solo dev in retrospect.
Source control to me is: history, backups and deployments.
Maybe I should have mentioned that I do
git pullon my server (yes! I have a real server without virtualization running my app!) to deploy stuff, and then something along the lines ofpm2 restart stuffandpm2 logs.The funny thing is that I do plenty of things wrong, and yet my customers don't mind.
I'm not preaching anything at all. If you value your commit messages, I understand completely and will never try to make you change. I'm trying to focus on things that matter more to my customers than my perfect git commit history. Sometimes it's interesting to reflect on what you've been doing for years (I've been a pro dev for the last ten years) and update your beliefs to better match your current situation.
Might as well do git commit --amend then
"Initial commit"
"Initial commit"
"Initial commit again"
"Fix bug"
"Unfix bug"
"Actually fix bug"
"Finished"
"Finished again"
In over 35 years of software development (mostly solo, but a lot of team development in there too), I would strongly suggest that you include at least a line of description as to what was changed in the commit.
Trusting your memory is an exponentially increasing risk as you get older. Not only that, but if you don't set at least the semblance of a methodical approach now, it will be a LOT harder to do so when have a second, third, and more developers joining to help you out later.
I have a ton of bad habits too, and I can absolutely guarantee that when the pressure really hits later on, you will fall back on old habits and commit a major big fix or critical change with just 'Ok' for the message and make life way harder for your team than you intended.
Hahah this is so relatable. As long as it make sense to you!
:-D It completely does indeed.
Almost there - mine are “typo” - “ux” - “bug” - “nav on mobile”
I don't think the time saved by not writing a commit message is well justified.
You lose on useful IDE features like knowing when viewing a part of code when it was last changed and why, for example:
I use my personal commit history and publish them to the deployment also ( commits.txt in the root directory).
It's very easy to see which client is on which version of an app ( 1 deployment per client) to quickly see things.
Even if you're solo there are cases where it's useful.
Say your app deals with payments or other mission critical tasks, and you have people that rely on you. Then you want to be able to 1) find what you changed easily 2) be able to revert if needed.
If push 100 file changes in one commit, a.k.a spaghetti changes, then it's so much harder to find what changed and introduce a fix.
True! I try not to do such big changes though. I rarely hit the 100 file changes (if ever). Most of my activity is either fixing bugs (which impacts at most 10 files), and creating new features, but I'm so close to the production server that the delta is very little.
You'd laugh at my testing strategy, but I learned to let go of perfection. I invested in a good communication channel with my customers and they just tell me when I failed to catch a ball.
Also it's true when they say you write a code once, but you read it 100 times. It's my way of working. I reconnect with my past self by reading my code. No comments even, just the code.
As I said in another response, I'm not preaching or anything. I'm talking about my journey as a indie hacker. I'm in love with what I do and happy to talk and share. I found it funny that my commit history was so lame and yet it didn't have consequences for me :-D