What coding concept or practice seem commonly understood, but you never learned?
source link: https://dev.to/ben/what-coding-concept-or-practice-seem-commonly-understood-but-you-never-learned-17fi
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Discussion (59)
Collapse
Expand
git rebase — I barely understand how to use it, and really hope nothing goes wrong.
Collapse
Expand
Imagine a literal tree 🌲 like that.
Now get a saw and cut a branch off
Next change the colour of the leaves of this branch to purple 💜
Next take your glue and climb up 🌲 the tree, and stick it right on the tip.
Where you cut the branch off, go there and paint some bark over it like it never happened but actually pretend it was always at the top
The base is the tree branch
You are re base ing the branch at the top of the tree, I think of it as magical time travel
Collapse
Expand
Except that this picture explains nothing to me about what happens. It begs questions:
- What is a commit? Is it a diff? Or is it a whole copy of the repo?
- If it's a diff, how is rebasing it at the tip different to merging it there, I mean essentially it works fine if there are no conflicts if the diffs can automatically be applied without any ambiguity, but if not ... all the same merge issues arise.
- If it's not a diff, what does this rebase do to the tip and the (new) next commit. How do they relate, what's going on?
You see the confusion I (and I expect many) have around rebase is not the nice imagery of what it means (moving a branch somewhere else) it's the devil of the detail, about what happens to the changes between the point of divergence and the tip of both the branch being rebased and the place it's being rebased to.
Thread
Thread
For simplicity's sake, you can consider a commit a diff to the commit before it (called the "parent"). How git actually works under the hood is a fair bit more complicated (it actually stores blob data of specific states), but that's the surface-level workings.
When you merge, you're creating a new commit that applies the necessary changes to the two commits that are being merged together (the target branch's current commit, as well as the source branch's current commit). Here, again for simplicity's sake, you can consider that merge commit to be two diffs, one on either side, which produce the new merged state.
Rebase instead takes the diffs from the oldest divergence between the two branches, and moves them onto the current commit of the target branch. For that, it applies the same diff onto the current commit as its new parent (instead of whatever was the original parent), changing (ideally) only the parent relationship of the commit.
Thus, where a merge maintains two different routes which converge in the merge commit, the rebase maintains only one route to the same target state. This means that either of the merge commit's parents have their own parents until they reach back to the divergence, whereas the rebased branch only has a single line of parentage going first to the other branch's most-recent commit, which itself then has the parentage back to the original point of divergence (which is now no longer related to the rebased branch directly at all).
So where merge glues two sticks together in parallel, the rebase glues them together in sequence.
Edit: re what the actual differences are after-the-fact, operationally: if you go back to an earlier commit, it will only follow its own parent relationships. So if you check out a commit specifically on either of the merged branches, you won't have the changes from the other branch. As for conflicts, you do indeed get them either way, though rebase makes it a tad easier to ensure that an individual commit is consistent and can, for example, compile correctly for the expected state at the time. Rebase often cuts the conflicts into smaller chunks that are somewhat time-coded to the commit it is currently working on, before moving to the next in the rebase chain.
Thread
Thread
I appreciate your wanting to get technical and I do see your point of view, but my little story is for people who have literally no idea what to think about rebasing, it's what I think about it and I do it all the time with no major fires for almost 5 years of rebasing 🔥🚒🚨. The details you crave and I suspect may know, are best learned / shown not told. Like can you describe an interactive rebase? It's not very easy on paper or in a comment text box ☺️
What I would say is that it offers a jumping off point to allow people to talk about things they would otherwise not know how to find the words
Thread
Thread
Thanks for helping FJones!
Thread
Thread
Was slightly confused there for a minute, thought the other comment was directed at me :D
DEV still can't handle deep threads too well.
Thread
Thread
Collapse
Expand
Love it. Thanks.
Thread
Thread
Your most welcome, of course as it's been highlighted it's more complex than said but I think that's need to know
Collapse
Expand
The relevant usages are pretty rare and rebase can be risky, so, in doubt, not using it might be wiser.
It's not uncommon to set it as a global pull strategy (which is the same as git pull --rebase) to prevent useless merges of the same branch in the git history every time you pull the remote branch for updates (e.g., "merge master into master").
However, I would not recommend git rebase between different branches unless you perfectly know what you're doing (e.g. git rebase master develop). Otherwise, it can turn really nasty. I've already seen it, really hard to resolve.
I find the interactive rebase git rebase -i more helpful and less risky provided you use it only locally BEFORE pushing anything to the remote. It allows reorganizing and editing commits, which can improve readability.
Collapse
Expand
I'm not sure anyone understand git rebase. Every single time someone mentions it I am back to the tutorial pages and it'll cost me some minutes of reading before, if I'm lucky I go "a ha, I think I get that".
Collapse
Expand
Lol that's one I have to look up EVERY time to understand how it works again ... used it a few times, once it went horribly wrong, not using it anymore every since ... plain "git merge" is your friend!
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK