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.
Trunk based: am I a joke to you
Nah, just sort by date instead of topology, or vice versa.
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
A rebase rewrites the history of your branch, so that it’s as if you just branched off and then coded all your changes in one sitting.
It will go through each of your commits and try to apply them one after another. If something changed on the base branch that conflicts with your changes, it will prompt you to adjust your commit. You adjust it so that looks as if you just coded it on top of the base branch.
When you have lots of commits on your branch, this can mean that while you’re rebasing, you have to then also change your following commits which happened to touch the same lines as a previous commit. This can mean additional, stupid work.
As such, a workflow using rebases (“trunk-based workflow”) works best, if you can rebase often and merge back early. You won’t get merge conflicts when merging back, nor merge commits, because you resolved these while rebasing.
In particular in smaller teams where you have tight-knit communication, this workflow is absolutely stellar. It completely bypasses so many pain points that folks have with Git.
Merge conflicts are significantly reduced when you merge often and a trunk-based workflow removes the ceremony that typically prevents teams from doing just that.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
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.
Look at this person over here using branches, show off
Ok, well I was looking for a new project - guess I’m making git-ar hero now
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.
Here is the git-music Video: https://www.youtube.com/watch?v=S9Do2p4PwtE
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
Dad joke for coders? Ooooo… you!
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.
Can someone please play this in the guitar (or sitar?) and share it here?
Yeah lemme just grab my squints thirteen string guitar
Here is the git-music Video: https://www.youtube.com/watch?v=S9Do2p4PwtE
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…
tomfoolery, even
This in fact is vert good d’or large trams that work on 3 to 7 featyres or bug fixes in thé aame tome. Simple, ans vert easy to trace.
I’ve se en much much worse where you can’t keep track of where branches come from and where they go, and even if you do, you cannot predict what they can contain.
