14 ms·

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 ba

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 terrible coding practice? I don't have enough non-me experience to know what an anti-pattern this probably is. I probably won't change my process, but I'm curious.

ChuckNorris89 6y ago
I thought I was the only one using guy like this.
scaladev 6y ago
Just squash the junk commits with rebase when you are done. It keeps the history clean and you have many points to revert to.
edu 6y ago
If it works for you it's fine. I used Git in different ways depending on the projects, on some solo projects I do like you say (similar to saving a game to be able to go back). For some other solo projects (with a longer lifespan or more critical) I follow Gitflow and I am more strict with the process.
Ajedi32 6y ago
Pretty much what I do too, even working in collaborative projects. Once nice thing about git is that it makes it easy to go back and clean up your history with rebase before publishing it to others, so you can make as big of a mess as you want in your local branches without anyone else having to see it. So yes, having "interm" or "wip" commits would be an anti-pattern in a shared repo, as it makes it harder for others to see what changes you made. For a local branch though; not a big deal.
- rrosen326 6y ago
  So maybe that's the idea for my projects that I make available to others. Be a bit more deliberate with branches, allow them to be junky, and clean up when I merge to master. That seems like the best of both worlds with minimal effort. I think I'll even try it.
  - kop316 6y ago
    That has been how I have started to do it. I make a new branch, make a mess of it (until I am finished), then merge it back into the original "golden" branch.
jidiculous 6y ago
I don't think it's an antipattern if you're working by yourself. As you said, it's a safety net that helps your confidence in case something does go wrong. The only thing I'd recommend changing might be to make your commit messages a tiny bit more detailed, even for the interim commits - that way you know what's going on at each commit if you do have to eventually do a `git bisect` to hunt down a regression. Going a step further and rebasing interactively to tidy up your logs would also accomplish the same goal, but if it's just for your own eyes, it's probably not worth the time.
sodapopcan 6y ago
Absolutely nothing wrong with this if you are developing solo. As suggested by a sibling comment, you can always squash if you are looking for a cleaner history, though this is probably isn't necessary if you are never going to share your code. If you are going to share and your important commits are clean, then it's easy to squash. Another good trick trick is to simply stage things to "freeze" them—You can then `git checkout` any changed files if you want to revert to the staged state. This is useful if you are in working state without a lot of changes but want to run a quick experiment before committing.
kop316 6y ago
That has been my pattern for some hobby projects, however it quickly becomes a mess to keep track of what you have done over a period of time (I have the same bad habit, I commit things so I can freexe my code in case I mess something up). My hobby project has been to extend a program with a new plugin, but then along the way I found bugs in the core code, and I wanted to upstream the fixes (and the plugin). I am very glad I knew what the fixes where, becasue I more or less had to rebase to the original code in order to untangle the mess of commits I made. I have also found other folks wanting to use my code, so it also made it much more helpful if ourside folks can see how I altered the original program.
mellavora 6y ago
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 tagging a commit as "feature/fix/refactor/chore" might make you think differently about your programming workflow. Or you might find it more of a distraction and limitation than a help. and yes, sometimes you certainly need that 'interim' tag to freeze work. For those rare cases where you run out of time or inspiration before you get to a natural end point of a task.
- sebmellen 6y ago
  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.
prpl 6y ago
If using this pattern it helps to split out your commits, i’d possible. I do this with changelists in intellij/pycharm.
philote 6y ago
Even when I use git by myself, I like to use branches. This helps me keep my work separate, and avoids issues if I'm working on one thing but need to do a quick fix elsewhere. I also tend to have anything in master set to go to live, so branching helps keep things that aren't ready from going live. Even if you don't have a "production" environment you push to, making sure your master branch is only code that works well is a good idea IMO. And as another reply mentioned, squashing commits is good for keeping your history cleaner. My branches tend to have a ton of "fix" commits that get squashed out when merging into master.
- ZephyrBlu 6y ago
  Another reason I personally like branches is because it gives me confidence to make breaking changes without immediately having to worry about regressions.
deleted 6y ago
[deleted]
NortySpock 6y ago
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.
seanwilson 6y ago
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.
- oivey 6y ago
  If you use “git add -p” it makes small commits pretty painless. I still like small commits in repos I work alone on because it makes reading the history during future debugging easier.
- JoblessWonder 6y ago
  It is funny because I use git (and commit messages) to help me keep track of what I was working on since I'm a solo developer but also an entire IT department so coding is only a portion of my time. Sometimes I'll just be starting to implement a major feature when something else will come up and I'll have to put it on hold for a few days/weeks. Having the quick little commits helps me figure out where I was and helps me get back into the flow.
- japhyr 6y ago
  Side conversation because I recognize your username. I've been playing wordoid every day since you posted it three weeks ago. You made a comment about having heard that someone scored 3000, and I think that's now in my mind as an end goal. I've gotten to about 1800 and can't quite let go yet. :) https://news.ycombinator.com/item?id=25999655 https://news.ycombinator.com/item?id=25999655
  - seanwilson 6y ago
    Great, glad it's a fun distraction and that's a better score than I can get. :) Feel free to contact me outside HN as well if you can think of any improvements (global high score tables are sounding good!). More on topic, when coding the game, I was Git committing maybe every hour or so without useful commit messages and didn't have a problem. With games (in the early stages anyway), I find you're typically changing lots and lots of small things all over the place to tweak the gameplay and presentation in an experimental way, so granular commits aren't helpful. I would switch to more granular commits now though since the game has stabilised more.
gmfawcett 6y ago
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 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?
- nemetroid 6y ago
  > 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 (especially when reading code) I'm more interested in the point itself. The same applies to version history. It can be used to tell the raw story, but there's usually a more useful and interesting story to be told.
  - acemarke 6y ago
    Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I working on? - What was the reason for any of these changes in the first place? - Why did I make some of these changes specifically to implement that task? - What additional side info is important context for understanding the diffs?
Semaphor 6y ago
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.
w0mbat 6y ago
Absolutely. This guy has too many rules. When I work alone I'm climbing a mountain, and Git is the rope. I can fall, but I won't fall far. I commit as often as I want to. The log is not a story for someone else to read later, it's the way I get to the top.
- mplanchard 6y ago
  This is an excellent metaphor, thank you. I’m going to add it to the bag of metaphors I use when explaining git
- jeremyjh 6y ago
  I find commit logs useful even if I'm the only person ever reading them. I like to be able to git blame on a line and be reminded of the context in which I did something and what I was trying to solve. I don't bother to pretty up my feature branches though, I just squash them so that master has a clear story
  - SilverRed 6y ago
    How we do it at work is every single commit message must have a ticket number in it. This is super easy to do and super useful. Even if the commit message is "fix exception #1823" you can go and look up #1823 and see what that issue was to make sure you don't reintroduce it with your change. You will always find more info and context in the ticket than in git commit messages.
    - w0mbat 6y ago
      I hate this. Often I am rewriting a bad comment, or improving the working code I checked in yesterday whose ticket has already been closed. Deleting an unneeded #include. All kinds of stuff for which there is no open ticket. This kind of rule prevents people from maintaining the code base as they go. I have literally quit a company because of bullshit such as this. I was a senior engineer and could not fix a typo in a comment without a bug number and two code reviews.
stevecat 6y ago
If you work with branches, can you merge with the --squash option? This makes one neat commit on your default branch. You could even then commit without the -m option, and type a more descriptive multi-line commit message detailing the changes you've made. I only work on little solo projects and this is what I'm doing. It makes a very readable history, and helps me answer "why on earth did I do that?", but it's harder to revert small changes later. If I'm working with others, I try to match my committing style to the project.
- fiddlerwoaroof 6y ago
  Squashing makes tools like git blame or emacs’s vc-annotate a lot less useful: with small commits, I can reconstruct the code as it was when a particular line changed; with a squash, the coordinated changes are a lot less useful.
  - jeremyjh 6y ago
    Without squashing git blame has too much noise in it for my taste. I don't want to see 90 different commits in a single file's blame, when they were actually related to 9 different features. If each topic branch has a reasonable scope then the squashed changes I think are more useful than each little tweak or fixup.
    - SilverRed 6y ago
      If you really want to do it nice, you get to the end and then move all of the commited changes in to the uncommited state and then recommit them in to logical steps and commit them piece by piece with well written messages. But at some point you are spending more time bookkeeping than the actual value you will get from it. If its a personal repo, don't bother. If you are sending a patch to Linus, tidy your commit messages.
gopalv 6y ago
> It's kind like a snapshot-based local history. You can extend it to remote-history too, because git makes it almost trivial to create a repo that you want to work over the network (without a running server of any kind). I use git as a fancy rsync sometimes. I do most of my work on a remote box, but I still like to edit locally in an IDE, but occasionally I make a change on the remote side. On the remote side, I do git init --bare project.git git remote add clusterx remotebox:dev/project.git Then do a git clone on the remote box from that repo, then I can push changes back to that local repo and when I'm done with the day, I can just pull it all back to my laptop with a git pull. This used to be full of patch + diff + rsync in the past, but when you build stuff remotely and do diffs, but add new files to the codebase, it is so much easier to just use git. For my personal projects, I think CSS files are the most common things I've edited in this sort of loop - my web-app folders are generally just git clone --depth 1, which also takes care of the other loop where I edit locally and deploy to remote.
khalilravanna 6y ago
I don’t think it’s an anti-pattern but you might just need some sort of backup tool with incremental backups and rollback. Sounds like it would likely suit your needs with less overhead.
pkulak 6y ago
I do that on shared projects too. I absolutely will not end my day with work that exists only on my machine, and git is a fine place to put it, as far as I'm concerned. I routinely make a branch called "phil/stash" that I will commit totally broken code to at the end of the day. Then I rebase/ammend it into shape when I'm ready to PR.
zeta0134 6y ago
For my solo projects I break the "don't code in master" rule because there is nobody else to coordinate with, and I usually only work on a major idea at a time. However I still use branches, usually if I want to quickly test out a breaking change, or if I start something I don't anticipate being finished with in a long time, so that my master branch remains usable for other side tangents. The branching strategy means that it's pretty important that my commits are small, the brief commit message is accurate (even if I occasionally commit too many changes at once) and the description explains my train of thought. Nearly every time, I am communicating those changes to myself in 6 months when I switch into that branch randomly and wonder what I was in the middle of doing.
bluetwo 6y ago
As a solo developer who works across several machines, I still use subversion to coordinate code. I have yet to see the advantage of using git in this situation.
- gmfawcett 6y ago
  As long as you're not still using CVS -- that would just be masochistic. :) If it's working, stick with it. Most people use Git as a centralized RCS anyway. I like the decentralized features of Git (darcs, fossil, hg, whatever), but mainly for short-term problem solving -- on any project, eventually an official hub emerges.
tux1968 6y ago
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, rebasing is fine." -- Linus Torvalds [1] https://yarchive.net/comp/linux/git_rebase.html https://yarchive.net/comp/linux/git_rebase.html
- frant-hartm 6y ago
  This applies mainly to projects with kernel style of development. There are not many of those. In centralized repo style (GitHub), it's fine to rebase, even force push as long as you know exactly what you are doing and coordinate with your colleagues.
  - jeremyjh 6y ago
    In a lot of projects topic branches generally have a single owner and are not used as the basis of other people's branches, even if they are technically public they are not public in the same sense that he is referring to. If you aren't going to be getting PRs on your branch you can consider it private and rebase all you like IMO. edit to add: I generally prefer people not rebase after they've asked for a PR review just because the reference for comments will be lost. If they want to, maybe do it after all the reviews are approved.
  - matwood 6y ago
    I'm going to disagree, unless your are a solo developer (and even then it's bad practice to rebase commits that have already been pushed). Allowing rebase on shared branches just opens the door to too many possible catastrophic mistakes. When I make a new repo the first thing I do is disable history rewriting.
gregmac 6y ago
> 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 everywhere, or just make a full copy of the folder. It doesn't take long before this becomes an absolute mess. Copying in particular was a barrier: you had to realize it was necessary then interrupt your flow to do something that would take a several seconds. (By contrast, if you commit as you go - especially everytime you get to a working "checkpoint" - there's zero extra effort needed.)
- jonwinstanley 6y ago
  Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.
- colllectorof 6y ago
  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.
  - dimitrios1 6y ago
    Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.
    - hinkley 6y ago
      I'm butchering something someone said here about a month ago: Some people cut a trail through the jungle, others just push the branches out of the way and expect everyone behind them to do the same.
  - 6y ago
dilawar 6y ago
I do the same if I am doing assignment or writing a single script. I'd prefer something close to his if I am writing a library or a small app.
deleted 6y ago
[deleted]
j7ake 6y ago
I mostly do solo work too and for me the main goal is less to make code readable for other people, but for code to be readable for myself in a year from now. I’ve definitely had situations when I had reverted code to a year back to check if there was a bug. Git was very helpful from that point of view.
jrochkind1 6y ago
Is it "terrible"? 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.
lamontcg 6y ago
Yeah I'm 13,000 lines into a solo side project and haven't bothered with a single branch+merge. I've got a bunch of tests, but I don't test everything, I don't make sure every commit has tests. Commits are mostly checkpoints of when major feature achieve some kind of initial stability where I want to be able to diff back to last-known-working. I try to do better commits than "WIP" but they're something like "such and such feature now seems to actually work (lots of buggy edge conditions)". I'll throw in a lot of unrelated code cleanup that happens into single commits as well. I focus on moving the needle on the end results though and not having perfect process. Many bits of code that I have which work well enough don't have any tests at all. As I hit bugs I drill into code and fill out the tests that I didn't do. Simple code that is used all over the place and doesn't cause issues may not have any formal tests at all. I rarely actually bother to go back into my own git history, mostly I just use it like a quicksave in case I wind up dying at the next bossfight. I think what'll get you in trouble more than having perfect process is writing spaghetti code that violates separation of concerns. If things are separated well, you should be able to come back and test it easily if it causes issues. Test the stuff that is complicated and obviously will cause issues if its not perfect. Test the stuff that is found to be buggy or needs to be proven to be not buggy in order to track down bugs. Don't bother with perfectly testing everything. I've been adding a threaded AVL tree implementation lately. I definitely tested that extensively and did a savegame when the AVL tree was written and passing tests properly, and then added threads and did another couple of savegames. I'm going to build on top of that, and I need to be able to trust it without falling back into debugging it. I've got a Clamp01 function though which takes a double and ensures it is within 0 <= x <= 1 and I don't have that one tested. I'm pretty confident it works though.
- mr_mitm 6y ago
  Sounds exactly like what I'm doing. What I wondered was if and when other developers deviate from that workflow. After the first release? After the first collaborator has joined? Never? Are there textbook developers who use a strict strategy like the one Daniel Stenberg [1] is following from day 1? [1] https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/ https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/
GuB-42 6y ago
Same thing for me. Generally I am against rewriting history unless there is a big mess to fix. For me, git is my work process, and bugs, typos, bad merges and code that doesn't compile is part of it and I don't try to hide it. Personally, I value historical accuracy more than cleanliness. But some people have compelling arguments for the opposite, like the author. These people tend to view git as a release schedule where every commit is workable code. It is good for bisecting, and git log is your actual changelog. But you lose information about how you solved problem, when you did what, etc... it is also more time consuming to maintain. You can use a hybrid solution with two parallel branches and merge commits, or you can just use tags. Git is not very opinionated on how you should work. Merge or rebase, clean or historically accurate, push or pull, etc... There is more than one way to do it.
matwood 6y ago
> Is this a terrible coding practice? Not at all. Copying folders with names like code1, code2, code3 is terrible practice. Using SCM and committing as checkpoints while you work is good coding practice. You have a process, and it works for you.
CalChris 6y ago
Yeah, I'm pretty much the same. Still, there are elements of the article's approach that I follow. Principle 2a: Every commit must include its own tests Principle 2b: Every commit must pass all tests But otherwise, I don't create branches. My commits are medium sized, one big thing, and to the trunk. My commit messages are at best ok. After a commit, I git --amend liberally. It's never really clear in my mind when a commit ended and the next one starts. This wouldn't fly in a group. The one think I'd recommend is Never Type git. That's overstating, but basically git's command line syntax is just terrible AND thus dangerous. I think my one moderate sized git screwup was due to the command line syntax. So now I hide (most of) it behind shell aliases. This guy goes a bit far but you get the idea: https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet I pull rarely enough that I prefer to type it out. Also, configure a good diff tool (although Apple seems to reject kdiff3 for now). And .gitignore goes without saying.
- dotancohen 6y ago
  Regarding diff tools: suggestions welcome. I've used VIM's three-way diffs, and would prefer to stay in the CLI. But the Jetbrains IDEs come with a great GUI diff tool for Git merge conflicts. I'd love to find something comparable on the CLI.
  - CalChris 6y ago
    I use kdiff3 but I only want a visual diff. I'm not using it as a merge tool. VS Code has great git support and great diff support. If it only had better (or rather, more accurate) vim support I'd be there but every time I try, I head back to standard vim with something like VimR. It's been six months and I should try again again.
    - dotancohen 6y ago
      Thank you.
Groxx 6y ago
>Is this a terrible coding practice? Are you the only consumer of the practice? And do you like it? Then no, it's not terrible at all, it's useful. Git will function just fine for this. I do similar things with my "experiment" repos, they're practically "streams of thought saved to disk" and they contain a ton of digressions and occasional breakages and that's totally fine. I have zero complaints after several years of doing this. The major benefits to much-more-structured approaches come in the form of automated tooling that's really only useful when you have large repos or many contributors (git bisect is a perfect example), or external automation (ci/cd pipelines, etc). For those kinds of repos, yeah, I'd say it's a terrible practice, and it'll cause some easily-avoided pain. But even then: work however you like on a branch, and merge (or squash) when you have "good" stuff, and it generally works well.
BrandoElFollito 6y ago
> Is this a terrible coding practice It is not. I do the same. I tried to use git the way OP describes and I was taking more time to manage the logistics than to code. I then hit the "I can obviously call a function in a new commit from one in a previous one". Handling this gracefully means full time work. My code works 70% of the time anyway si I ended up making efforts to move it up a few percent points than to have a byzantin git tree.
dataflow 6y ago
> Is this a terrible coding practice? I don't have enough non-me experience to know what an anti-pattern this probably is. I probably won't change my process, but I'm curious. For solo development? I don't think it's good, but ultimately you should do whatever works for you. When you work on a team, though, it might be hard to break the habit later if this is what you're used to, and you really really will need to. Nobody wants to see "snapshot" commits in a shared repo; commits will need to actually accomplish a clear goal. Also, I find it very helpful to be able to make independent changes in separate commits (sometimes I see something wrong that's unrelated to whatever I'm doing), then reorder (rebase) them to polish them sometime before pushing. If you don't get in the habit of making your commits somewhat orthogonal, you won't be able to do these kinds of things (whether on teams or solo).
lmm 6y ago
As long as the commits compile, it's a great coding practice. Unfortunately most development teams haven't caught up to what git actually helps with (and doesn't help with) yet and will block you from doing this, but if you can find a team that's open to actually testing out different practices and seeing what works better then it will serve you very well.
thefz 6y ago
> Is this a terrible coding practice? Nope. I have been versioning everything from C# to SQL for more than a decade and it saved me many, many times. With Subversion too, which is far less evolved and modern than Git. The advantage of mastering a complex tool like git and mantaining a central repository is the increased granularity of commits/branches and clarity of versioning, but if the "snapshot here and there" approach works for you, then use it.

ChuckNorris89 6y ago

I thought I was the only one using guy like this.

scaladev 6y ago

Just squash the junk commits with rebase when you are done. It keeps the history clean and you have many points to revert to.

edu 6y ago

If it works for you it's fine. I used Git in different ways depending on the projects, on some solo projects I do like you say (similar to saving a game to be able to go back). For some other solo projects (with a longer lifespan or more critical) I follow Gitflow and I am more strict with the process.

Ajedi32 6y ago

Pretty much what I do too, even working in collaborative projects. Once nice thing about git is that it makes it easy to go back and clean up your history with rebase before publishing it to others, so you can make as big of a mess as you want in your local branches without anyone else having to see it. So yes, having "interm" or "wip" commits would be an anti-pattern in a shared repo, as it makes it harder for others to see what changes you made. For a local branch though; not a big deal.

rrosen326 6y ago
So maybe that's the idea for my projects that I make available to others. Be a bit more deliberate with branches, allow them to be junky, and clean up when I merge to master. That seems like the best of both worlds with minimal effort. I think I'll even try it.
- kop316 6y ago
  That has been how I have started to do it. I make a new branch, make a mess of it (until I am finished), then merge it back into the original "golden" branch.

jidiculous 6y ago

I don't think it's an antipattern if you're working by yourself. As you said, it's a safety net that helps your confidence in case something does go wrong. The only thing I'd recommend changing might be to make your commit messages a tiny bit more detailed, even for the interim commits - that way you know what's going on at each commit if you do have to eventually do a `git bisect` to hunt down a regression. Going a step further and rebasing interactively to tidy up your logs would also accomplish the same goal, but if it's just for your own eyes, it's probably not worth the time.

sodapopcan 6y ago

Absolutely nothing wrong with this if you are developing solo. As suggested by a sibling comment, you can always squash if you are looking for a cleaner history, though this is probably isn't necessary if you are never going to share your code. If you are going to share and your important commits are clean, then it's easy to squash. Another good trick trick is to simply stage things to "freeze" them—You can then `git checkout` any changed files if you want to revert to the staged state. This is useful if you are in working state without a lot of changes but want to run a quick experiment before committing.

kop316 6y ago

That has been my pattern for some hobby projects, however it quickly becomes a mess to keep track of what you have done over a period of time (I have the same bad habit, I commit things so I can freexe my code in case I mess something up). My hobby project has been to extend a program with a new plugin, but then along the way I found bugs in the core code, and I wanted to upstream the fixes (and the plugin). I am very glad I knew what the fixes where, becasue I more or less had to rebase to the original code in order to untangle the mess of commits I made. I have also found other folks wanting to use my code, so it also made it much more helpful if ourside folks can see how I altered the original program.

mellavora 6y ago

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 tagging a commit as "feature/fix/refactor/chore" might make you think differently about your programming workflow. Or you might find it more of a distraction and limitation than a help. and yes, sometimes you certainly need that 'interim' tag to freeze work. For those rare cases where you run out of time or inspiration before you get to a natural end point of a task.

sebmellen 6y ago
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.

prpl 6y ago

If using this pattern it helps to split out your commits, i’d possible. I do this with changelists in intellij/pycharm.

philote 6y ago

Even when I use git by myself, I like to use branches. This helps me keep my work separate, and avoids issues if I'm working on one thing but need to do a quick fix elsewhere. I also tend to have anything in master set to go to live, so branching helps keep things that aren't ready from going live. Even if you don't have a "production" environment you push to, making sure your master branch is only code that works well is a good idea IMO. And as another reply mentioned, squashing commits is good for keeping your history cleaner. My branches tend to have a ton of "fix" commits that get squashed out when merging into master.

ZephyrBlu 6y ago
Another reason I personally like branches is because it gives me confidence to make breaking changes without immediately having to worry about regressions.

deleted 6y ago

[deleted]

NortySpock 6y ago

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.

seanwilson 6y ago

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.

oivey 6y ago
If you use “git add -p” it makes small commits pretty painless. I still like small commits in repos I work alone on because it makes reading the history during future debugging easier.
JoblessWonder 6y ago
It is funny because I use git (and commit messages) to help me keep track of what I was working on since I'm a solo developer but also an entire IT department so coding is only a portion of my time. Sometimes I'll just be starting to implement a major feature when something else will come up and I'll have to put it on hold for a few days/weeks. Having the quick little commits helps me figure out where I was and helps me get back into the flow.
japhyr 6y ago
Side conversation because I recognize your username. I've been playing wordoid every day since you posted it three weeks ago. You made a comment about having heard that someone scored 3000, and I think that's now in my mind as an end goal. I've gotten to about 1800 and can't quite let go yet. :) https://news.ycombinator.com/item?id=25999655 https://news.ycombinator.com/item?id=25999655
- seanwilson 6y ago
  Great, glad it's a fun distraction and that's a better score than I can get. :) Feel free to contact me outside HN as well if you can think of any improvements (global high score tables are sounding good!). More on topic, when coding the game, I was Git committing maybe every hour or so without useful commit messages and didn't have a problem. With games (in the early stages anyway), I find you're typically changing lots and lots of small things all over the place to tweak the gameplay and presentation in an experimental way, so granular commits aren't helpful. I would switch to more granular commits now though since the game has stabilised more.

gmfawcett 6y ago

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 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?

nemetroid 6y ago
> 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 (especially when reading code) I'm more interested in the point itself. The same applies to version history. It can be used to tell the raw story, but there's usually a more useful and interesting story to be told.
- acemarke 6y ago
  Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I working on? - What was the reason for any of these changes in the first place? - Why did I make some of these changes specifically to implement that task? - What additional side info is important context for understanding the diffs?

Semaphor 6y ago

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.

w0mbat 6y ago

Absolutely. This guy has too many rules. When I work alone I'm climbing a mountain, and Git is the rope. I can fall, but I won't fall far. I commit as often as I want to. The log is not a story for someone else to read later, it's the way I get to the top.

mplanchard 6y ago
This is an excellent metaphor, thank you. I’m going to add it to the bag of metaphors I use when explaining git
jeremyjh 6y ago
I find commit logs useful even if I'm the only person ever reading them. I like to be able to git blame on a line and be reminded of the context in which I did something and what I was trying to solve. I don't bother to pretty up my feature branches though, I just squash them so that master has a clear story
- SilverRed 6y ago
  How we do it at work is every single commit message must have a ticket number in it. This is super easy to do and super useful. Even if the commit message is "fix exception #1823" you can go and look up #1823 and see what that issue was to make sure you don't reintroduce it with your change. You will always find more info and context in the ticket than in git commit messages.
  - w0mbat 6y ago
    I hate this. Often I am rewriting a bad comment, or improving the working code I checked in yesterday whose ticket has already been closed. Deleting an unneeded #include. All kinds of stuff for which there is no open ticket. This kind of rule prevents people from maintaining the code base as they go. I have literally quit a company because of bullshit such as this. I was a senior engineer and could not fix a typo in a comment without a bug number and two code reviews.

stevecat 6y ago

If you work with branches, can you merge with the --squash option? This makes one neat commit on your default branch. You could even then commit without the -m option, and type a more descriptive multi-line commit message detailing the changes you've made. I only work on little solo projects and this is what I'm doing. It makes a very readable history, and helps me answer "why on earth did I do that?", but it's harder to revert small changes later. If I'm working with others, I try to match my committing style to the project.

fiddlerwoaroof 6y ago
Squashing makes tools like git blame or emacs’s vc-annotate a lot less useful: with small commits, I can reconstruct the code as it was when a particular line changed; with a squash, the coordinated changes are a lot less useful.
- jeremyjh 6y ago
  Without squashing git blame has too much noise in it for my taste. I don't want to see 90 different commits in a single file's blame, when they were actually related to 9 different features. If each topic branch has a reasonable scope then the squashed changes I think are more useful than each little tweak or fixup.
  - SilverRed 6y ago
    If you really want to do it nice, you get to the end and then move all of the commited changes in to the uncommited state and then recommit them in to logical steps and commit them piece by piece with well written messages. But at some point you are spending more time bookkeeping than the actual value you will get from it. If its a personal repo, don't bother. If you are sending a patch to Linus, tidy your commit messages.

gopalv 6y ago

> It's kind like a snapshot-based local history. You can extend it to remote-history too, because git makes it almost trivial to create a repo that you want to work over the network (without a running server of any kind). I use git as a fancy rsync sometimes. I do most of my work on a remote box, but I still like to edit locally in an IDE, but occasionally I make a change on the remote side. On the remote side, I do git init --bare project.git git remote add clusterx remotebox:dev/project.git Then do a git clone on the remote box from that repo, then I can push changes back to that local repo and when I'm done with the day, I can just pull it all back to my laptop with a git pull. This used to be full of patch + diff + rsync in the past, but when you build stuff remotely and do diffs, but add new files to the codebase, it is so much easier to just use git. For my personal projects, I think CSS files are the most common things I've edited in this sort of loop - my web-app folders are generally just git clone --depth 1, which also takes care of the other loop where I edit locally and deploy to remote.

khalilravanna 6y ago

I don’t think it’s an anti-pattern but you might just need some sort of backup tool with incremental backups and rollback. Sounds like it would likely suit your needs with less overhead.

pkulak 6y ago

I do that on shared projects too. I absolutely will not end my day with work that exists only on my machine, and git is a fine place to put it, as far as I'm concerned. I routinely make a branch called "phil/stash" that I will commit totally broken code to at the end of the day. Then I rebase/ammend it into shape when I'm ready to PR.

zeta0134 6y ago

For my solo projects I break the "don't code in master" rule because there is nobody else to coordinate with, and I usually only work on a major idea at a time. However I still use branches, usually if I want to quickly test out a breaking change, or if I start something I don't anticipate being finished with in a long time, so that my master branch remains usable for other side tangents. The branching strategy means that it's pretty important that my commits are small, the brief commit message is accurate (even if I occasionally commit too many changes at once) and the description explains my train of thought. Nearly every time, I am communicating those changes to myself in 6 months when I switch into that branch randomly and wonder what I was in the middle of doing.

bluetwo 6y ago

As a solo developer who works across several machines, I still use subversion to coordinate code. I have yet to see the advantage of using git in this situation.

gmfawcett 6y ago
As long as you're not still using CVS -- that would just be masochistic. :) If it's working, stick with it. Most people use Git as a centralized RCS anyway. I like the decentralized features of Git (darcs, fossil, hg, whatever), but mainly for short-term problem solving -- on any project, eventually an official hub emerges.

tux1968 6y ago

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, rebasing is fine." -- Linus Torvalds [1] https://yarchive.net/comp/linux/git_rebase.html https://yarchive.net/comp/linux/git_rebase.html

frant-hartm 6y ago
This applies mainly to projects with kernel style of development. There are not many of those. In centralized repo style (GitHub), it's fine to rebase, even force push as long as you know exactly what you are doing and coordinate with your colleagues.
- jeremyjh 6y ago
  In a lot of projects topic branches generally have a single owner and are not used as the basis of other people's branches, even if they are technically public they are not public in the same sense that he is referring to. If you aren't going to be getting PRs on your branch you can consider it private and rebase all you like IMO. edit to add: I generally prefer people not rebase after they've asked for a PR review just because the reference for comments will be lost. If they want to, maybe do it after all the reviews are approved.
- matwood 6y ago
  I'm going to disagree, unless your are a solo developer (and even then it's bad practice to rebase commits that have already been pushed). Allowing rebase on shared branches just opens the door to too many possible catastrophic mistakes. When I make a new repo the first thing I do is disable history rewriting.

gregmac 6y ago

> 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 everywhere, or just make a full copy of the folder. It doesn't take long before this becomes an absolute mess. Copying in particular was a barrier: you had to realize it was necessary then interrupt your flow to do something that would take a several seconds. (By contrast, if you commit as you go - especially everytime you get to a working "checkpoint" - there's zero extra effort needed.)

jonwinstanley 6y ago
Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.
colllectorof 6y ago
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.
- dimitrios1 6y ago
  Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.
  - hinkley 6y ago
    I'm butchering something someone said here about a month ago: Some people cut a trail through the jungle, others just push the branches out of the way and expect everyone behind them to do the same.
- 6y ago

dilawar 6y ago

I do the same if I am doing assignment or writing a single script. I'd prefer something close to his if I am writing a library or a small app.

deleted 6y ago

[deleted]

j7ake 6y ago

I mostly do solo work too and for me the main goal is less to make code readable for other people, but for code to be readable for myself in a year from now. I’ve definitely had situations when I had reverted code to a year back to check if there was a bug. Git was very helpful from that point of view.

jrochkind1 6y ago

Is it "terrible"? 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.

lamontcg 6y ago

Yeah I'm 13,000 lines into a solo side project and haven't bothered with a single branch+merge. I've got a bunch of tests, but I don't test everything, I don't make sure every commit has tests. Commits are mostly checkpoints of when major feature achieve some kind of initial stability where I want to be able to diff back to last-known-working. I try to do better commits than "WIP" but they're something like "such and such feature now seems to actually work (lots of buggy edge conditions)". I'll throw in a lot of unrelated code cleanup that happens into single commits as well. I focus on moving the needle on the end results though and not having perfect process. Many bits of code that I have which work well enough don't have any tests at all. As I hit bugs I drill into code and fill out the tests that I didn't do. Simple code that is used all over the place and doesn't cause issues may not have any formal tests at all. I rarely actually bother to go back into my own git history, mostly I just use it like a quicksave in case I wind up dying at the next bossfight. I think what'll get you in trouble more than having perfect process is writing spaghetti code that violates separation of concerns. If things are separated well, you should be able to come back and test it easily if it causes issues. Test the stuff that is complicated and obviously will cause issues if its not perfect. Test the stuff that is found to be buggy or needs to be proven to be not buggy in order to track down bugs. Don't bother with perfectly testing everything. I've been adding a threaded AVL tree implementation lately. I definitely tested that extensively and did a savegame when the AVL tree was written and passing tests properly, and then added threads and did another couple of savegames. I'm going to build on top of that, and I need to be able to trust it without falling back into debugging it. I've got a Clamp01 function though which takes a double and ensures it is within 0 <= x <= 1 and I don't have that one tested. I'm pretty confident it works though.

mr_mitm 6y ago
Sounds exactly like what I'm doing. What I wondered was if and when other developers deviate from that workflow. After the first release? After the first collaborator has joined? Never? Are there textbook developers who use a strict strategy like the one Daniel Stenberg [1] is following from day 1? [1] https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/ https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/

GuB-42 6y ago

Same thing for me. Generally I am against rewriting history unless there is a big mess to fix. For me, git is my work process, and bugs, typos, bad merges and code that doesn't compile is part of it and I don't try to hide it. Personally, I value historical accuracy more than cleanliness. But some people have compelling arguments for the opposite, like the author. These people tend to view git as a release schedule where every commit is workable code. It is good for bisecting, and git log is your actual changelog. But you lose information about how you solved problem, when you did what, etc... it is also more time consuming to maintain. You can use a hybrid solution with two parallel branches and merge commits, or you can just use tags. Git is not very opinionated on how you should work. Merge or rebase, clean or historically accurate, push or pull, etc... There is more than one way to do it.

matwood 6y ago

> Is this a terrible coding practice? Not at all. Copying folders with names like code1, code2, code3 is terrible practice. Using SCM and committing as checkpoints while you work is good coding practice. You have a process, and it works for you.

CalChris 6y ago

Yeah, I'm pretty much the same. Still, there are elements of the article's approach that I follow. Principle 2a: Every commit must include its own tests Principle 2b: Every commit must pass all tests But otherwise, I don't create branches. My commits are medium sized, one big thing, and to the trunk. My commit messages are at best ok. After a commit, I git --amend liberally. It's never really clear in my mind when a commit ended and the next one starts. This wouldn't fly in a group. The one think I'd recommend is Never Type git. That's overstating, but basically git's command line syntax is just terrible AND thus dangerous. I think my one moderate sized git screwup was due to the command line syntax. So now I hide (most of) it behind shell aliases. This guy goes a bit far but you get the idea: https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet I pull rarely enough that I prefer to type it out. Also, configure a good diff tool (although Apple seems to reject kdiff3 for now). And .gitignore goes without saying.

dotancohen 6y ago
Regarding diff tools: suggestions welcome. I've used VIM's three-way diffs, and would prefer to stay in the CLI. But the Jetbrains IDEs come with a great GUI diff tool for Git merge conflicts. I'd love to find something comparable on the CLI.
- CalChris 6y ago
  I use kdiff3 but I only want a visual diff. I'm not using it as a merge tool. VS Code has great git support and great diff support. If it only had better (or rather, more accurate) vim support I'd be there but every time I try, I head back to standard vim with something like VimR. It's been six months and I should try again again.
  - dotancohen 6y ago
    Thank you.

Groxx 6y ago

>Is this a terrible coding practice? Are you the only consumer of the practice? And do you like it? Then no, it's not terrible at all, it's useful. Git will function just fine for this. I do similar things with my "experiment" repos, they're practically "streams of thought saved to disk" and they contain a ton of digressions and occasional breakages and that's totally fine. I have zero complaints after several years of doing this. The major benefits to much-more-structured approaches come in the form of automated tooling that's really only useful when you have large repos or many contributors (git bisect is a perfect example), or external automation (ci/cd pipelines, etc). For those kinds of repos, yeah, I'd say it's a terrible practice, and it'll cause some easily-avoided pain. But even then: work however you like on a branch, and merge (or squash) when you have "good" stuff, and it generally works well.

BrandoElFollito 6y ago

> Is this a terrible coding practice It is not. I do the same. I tried to use git the way OP describes and I was taking more time to manage the logistics than to code. I then hit the "I can obviously call a function in a new commit from one in a previous one". Handling this gracefully means full time work. My code works 70% of the time anyway si I ended up making efforts to move it up a few percent points than to have a byzantin git tree.

dataflow 6y ago

> Is this a terrible coding practice? I don't have enough non-me experience to know what an anti-pattern this probably is. I probably won't change my process, but I'm curious. For solo development? I don't think it's good, but ultimately you should do whatever works for you. When you work on a team, though, it might be hard to break the habit later if this is what you're used to, and you really really will need to. Nobody wants to see "snapshot" commits in a shared repo; commits will need to actually accomplish a clear goal. Also, I find it very helpful to be able to make independent changes in separate commits (sometimes I see something wrong that's unrelated to whatever I'm doing), then reorder (rebase) them to polish them sometime before pushing. If you don't get in the habit of making your commits somewhat orthogonal, you won't be able to do these kinds of things (whether on teams or solo).

lmm 6y ago

As long as the commits compile, it's a great coding practice. Unfortunately most development teams haven't caught up to what git actually helps with (and doesn't help with) yet and will block you from doing this, but if you can find a team that's open to actually testing out different practices and seeing what works better then it will serve you very well.

thefz 6y ago

> Is this a terrible coding practice? Nope. I have been versioning everything from C# to SQL for more than a decade and it saved me many, many times. With Subversion too, which is far less evolved and modern than Git. The advantage of mastering a complex tool like git and mantaining a central repository is the increased granularity of commits/branches and clarity of versioning, but if the "snapshot here and there" approach works for you, then use it.