git commit -m "It's 4:59pm, let me commit since it seems like a sane choice even though everything is currently broken"

I feel strongly that there should be a permanent version of this frature - something like git stash but more pertinent to the core functionality. Something like commit --unstable

if you *really* need to commit it, just put it in a branch where it doesn't matter.

I implemented a branch system consisting of [project]_unstable, development and production. Unstable is for everything that doesn't really run, dev is for stuff that works but isn't yet implemented in an active version and prod is what is running can only be updated by the ci bot after dev ran through all tests and passed them. Worked quite well until now.

@Godisalie this sounds messy.

@Godisalie why not keeping it just in your feature branch? Even if it's unstable, it's not a merged code after all.

@plusgut Git is supposed to be messy and overly rich with experiments, so your final code doesn't have to be.

Git is not something that needs to be cleaned up, or structured. It needs to be honest and true.

There's something to be said for squashing commits from working branches right before merges — but still, I rather have too many points to revert to than too little, because sometimes even that fucked up state contained a little nugget of brilliance.

@bittersweet since when is git supposed to be messy? This goes against all best practises. And I feel sorry for all your teammates.

@plusgut

Because it's about documenting history, not changing it. History isn't always nice and pretty, it's messy, and it's important to be able to revisit the state of the project later.

Your fucked up commit might have introduced 6 bugs and fixed 1. If you delete the commit in a hard way, you lose information about fixing that one bug. If you soft revert it using a new commit, you clean your project, and retain that information.

Go fight in someone else's thread!

@bittersweet I strongly disagree, in my opinion each commit should be cleanly thought-out. Just because human history is messy, doesn't mean we have to encourage a messy artificial history. Sure the history will get a little messy, but it has not be encouraged.

In my opinion always when a part of task/ticket is actually done, then you do your commit.
Makes things easier when you want to get the information why this line was written, when in the git blame is the ticket-number with all the detailed informations.