Ok, well I was looking for a new project - guess I’m making git-ar hero now
this post was submitted on 09 Oct 2025
863 points (99.4% liked)
Programmer Humor
26817 readers
3181 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Is the goal to make branch commands that match a specific song? That’s be fun.
Use the guitar controller to branch, commit, and merge to the beat of Through The Fire And Flames and try to get a conflict-free repo.
Presented without comment: https://www.youtube.com/watch?v=wesICmc48UE
Jazz 2.0 just dropped
Jazz 2.0 just dropped
LOL!
That or Progressive Acid Folk.
Dad joke for coders? Ooooo... you!
Next version git-tar hero, where you also need to take care of the tar process
Although I don't have a realistic direct use case, I thought the name and complexity of the game should be worth it
in the projects i work in i always try to force semi linear history to avoid all of this, never merge (unless it's the MR) always rebase.
this leaves a very readable history, with each feature branch highlighted and no mixture in the commits...
i haven't found any downside yet... maybe that some ci/cd are built to push to main, but making them do branch pr automerge is not that difficult
How does a rebase play out? I know what it is conceptually, but usually just do the difficult merges myself
Instead of git history, you get a git fairy tale. Practically, the merge conflicts and their resolutions get spread across one or more commits on the branch that was rebased, and the history makes it look like all the work was done after the upstream commit(s) that there was a conflict with. This can be much tidier, but also loses the context of changes. E.g. you can no longer see that something is done differently to everywhere else that does the same thing not because it needs to do it differently, but because it copied and pasted something from ten lines above and the thing ten lines above received a bug fix on another branch which the feature branch was rebased onto. Based on my experience working on large projects that used both approaches, I'd rather scroll past extra commits and squiggly branch lines than try to reconstruct what someone was thinking when they made a mistake without access to the original commit they made the mistake in. If I had to allow history-rewriting operations in git, the one I'd pick would be rewriting the history of Earth so that when history rewriting operations were implemented in git, they defaulted to adding some metadata to the rewritten commits making the operations reversible so I could decide I wanted the real history back.
Having read through these replies, I'm leaning towards your thoughts on this. It does exactly what I thought it did, and I'm just not seeing the upside
I think I'm going to just push more strictly following feature branches
The upside is that a beautiful lie is often preferred over an ugly truth.
It's basically like you check out the destination branch and cherry pick your changes on top of it.
I don't know if there is a functional difference between a merge and a rebase assuming your git history is reasonable, but rebasing makes the history so much easier to follow. Every commit only has a single ancestor, commits are generally better structured because devs where I work tend to squash and rebase.
I get that theoretically... But does it like, just work automagically?
Like, I'm the git guru on my team, and we're about to start a new project larger than what we've done before. My teammates are old school and don't get git
Is frequent rebasing something I should push for? A clean history is nice, but I've just won them over on feature branches... Is this something quick and easy that would improve our quality of life?
Is frequent rebasing something I should push for? A clean history is nice, but I've just won them over on feature branches... Is this something quick and easy that would improve our quality of life?
Realistically, in the short term, no. If neither you nor any of your team members are familiar with rebasing or rebase-based workflows, you will encounter problems that no one will know how to solve without researching. That'll lead to frustration, and before you know it those old school teammates that don't get git will fall back into using svn, or zip files with names like final_project_v1.2_final_final (copy)
I recommend getting familiar with rebase- and merge-based workflows on your own first, like on your own projects/private repos, and reading through the git documentation. Once you become more of an expert, you might be able to teach your teammates how to be proficient at using git, or at bare minimum, you'll be able to help them unfuck themselves when they inevitably fuck their repos up.
it's great if your commits are smaller and more focused. main issue is it can be harder to solve some diff issues as it requires solving merges at each commit being rebased. so if you have a large feature branch that can be challenging when it starts to diverge a lot (ex: bug fixes on main). though the argument then is more for keeping branches smaller and focused which is a better process imo.
just beware it can be confusing for newer git users and when using shared branches can cause no ff commits.
It can. It depends on what changed. If both of you touch the same file in a conflicting way you'll have to merge the commit with the conflict. If you don't then it just auto magically works.
For example if you have commits A - B - C with a branch A - D with D adding a brand new file you can trivially rebase (IE no need to merge) D onto C for a history of A - B - C - D
The best part about rebasing imo is that you get to merge commit by commit. Using the previous example if there's a conflict in commit B but nothing in C all you have to do is fix commit D to handle the changes B made, nothing else
Look at this person over here using branches, show off
At least twelve lanes on a single track. If I recall, the cool keytar instrument you could get for... was it Rock Band 3? might be able to make a song with that track in it. Not sure how many other games or instruments could do that though.
I've seen worse ... so much worse.
I have made worse, I used to do a cascading merge everyday to move stuff from dev branches to staging to production. Then I did a merge in the opposite direction for a small selection of branches so they could get their updates from staging. Feature branches were rebased as needed.
I wonder if anyone's tried to play Bad Apple! on the branch graph.
(edit) Not exactly, but close. https://www.youtube.com/watch?v=-I8Jis87nmE
You, kind sir, are giving me ideas...
Trunk based: am I a joke to you
Lmao still nicer than mine.
Nah, just sort by date instead of topology, or vice versa.
tomfoolery, even
Can someone please play this in the guitar (or sitar?) and share it here?
Yeah lemme just grab my squints thirteen string guitar