Video

I use rebase quite often, but not so much with the interactive option. Great walkthrough, thank you! 🙌🏾

Very good video :)

Thank you, this helped me a lot.

Thank you for the wonderful video sir it was so useful for me and my team, thanks again

I first got to learn these concepts when starting with big data, and again when starting to learn Spark. I wish someone had explained them to me this well back then!

woow... that was useful. Thanks!

Thanks a lot for all your work. Especially this video helped me with my work the last few days a lot and how to "correctly" use git rebase!

@2.08 information I have been looking for for literally years. Thanks, all the "use rebase!" guys I have worked with never once managed to explain why!

very easy to sift through merge commits. a normal gui will hide them for you. Don't waste your CPU on overthinking git. The simple rule is always merge. Never rebase, never squash.

Can you make a video about classes/oop

You can set the default behavior of git pull to --rebase by doing git config --global pull.rebase true

I would use something like this but its slower and often harder to read than loops (when it gets complex)

awesome vid

another banger, didnt even know i wanted this

great content, just started with coding, it s deffo not for beginners, or its just me , i will learn and then get back to this video. Keep it up!!

I don't know about other languages, but in C#'s LINQ, there is more to that. With the code provided in the video, each element is processed immediately when using .map(). In C#, you can use .map(...).first(...), and only the first element will be processed by .map()'s function. Similarly, if you assign processed array.map(...).filter(...) to a variable, it will return IEnumerable, and callbacks passed to .map() and .filter() will be executed only when you enumerate it (for example, use .first() or foreach on said variable)

11:34 Ha, good one haven't seen that one yet.

Great explanation

Good visualization

Nice, variable are in like everything. Love it.

Is there any way to avoid this repetition of rebasing after --continue or --skip if i have resolved my code in the first time. Because every time after --continue command i have new conflicts to resolve? Please answer!

I'll add a tip that you lightly touched on: never rebase on another branch without *first* squashing your branch on itself. That way lies madness. Picture this - you've got 20 commits and you're rebasing on main (or whatever) that has several commits. If you get a conflict, that's *not* a conflict between the current state of your branch and the current state of the other. It's a conflict between the state of your branch 20 commits ago, 19 commits ago (plus changes from last conflict resolution), 18 commits ago (plus changes from previous conflict resolutions), etc. So you have to mentally time-travel back in time to fix what the conflicts would've been at each point in time, for each and every commit, including between code that you didn't write back then but modified during previous conflict resolutions. Possibly introducing more conflicts and/or bugs all along the way. In the end, you haven't rebased the current state of your branch on the current state of the other, you've added all kinds of changes along the way. Now you have tons of changes and untested code that you're pushing. In a merge commit, *or* if you've squashed your branch into a single commit and *then* rebase, in that case you're only dealing with conflicts between the current state of the two branches. Which is *vastly* easier to wrap your head around and understand and test. No time-traveling needed, no accumulating bugs. That of course means that you lose your commit history of how you got here from there, since you only have 1 commit instead of 20. But at least you have your sanity.

Nice

...or maybe just configure git pull command to by default use rebase strategy?

As a junior i have a question... If I plan to work on an important feature while other colleagues carry on other features should I simply avoid rebase? Or is keeping the branch local not so bad?

i like how vs code simplifies this with the sync button that will pull then push the local changes automatically without the user seeing it actually created a merge in the background then i see the commits by my coworkers and know they forgot to pull i always pull first, ifit fails (i'm behind) i either undo my local commit then pull and redo mine, or rebase (which i usually dont need to), but i too avoid this unnecessary merge commits, i hate those too

The command `git pull --rebase` running without errors is no guarantee there are no problems. Rebase works on plain text files without semantic understanding of them, so there still could be problems stemming from functionally conflicting commit mismatches. As an example, suppose you call a function somewhere in your rebased commits that is removed by the fetched commits. This is a nice example because it visibly breaks the code, but it could be less subtle. If you like to use `git pull --rebase` (which definitively is better than `git pull`) you should still spend a few seconds to check there are no functional conflicts.

In most cases you will be working on different branches/PR and the main branch is usually locked from direct push. When finishing the PR most hosts offer "squash merge" that no matter how many commits in your PR, there will be one commit in master after merging.

amazing video explaining git concepts :) really helped me visualise and understand better. thank you so much

Why not git stash, git pull, git stash pop?

What is the right syntax if I am not trying to push to a shared branch, but I am just updating my feature branch before submitting for a code review? Do I git pull --rebase origin/master?

So what is difference between git pull --rebase and git rebase <branch>?

Another interesting topic would be patches. What do they do? Why are they useful? How do they differ to cherry picking? Pros? Cons?

never rebase pushed commits! So what to do with pushed ones? git merge?

I literally chat GPT'd for this and found out about the interactive base, but I didn't do it because it looked complex. Your video explained it pretty well ❤ Also, I'd love that video on removing wrongly committed sensitive information. Thankss soo mucchh

Thank you! Now I know why doing rebase for my remote branch doesn't work. Please explain git merge squash as well!

Just do "git config --global pull.rebase true" to change the default behavior. You can also use git pull --ff-only which will fail if you cant easily pull the remote changes Edit: i guess I should have read the pinned comment hum?

It would be very interesting if you could make a video about the configuration and the integration between Git and the remote repos. There are some obscure things like "verified" commits and other things I never truly understood but I did it...

The master of git back at it again😅

Just saw this in my feed and subscribed,my guy came out of nowhere cooking git💯

Great video. Really helpful. Thanks

wake up babe, new Philomatics video just dropped

Cheat sheet would be amazing. Waiting for it. 🙌🏻

Subscribed, thank you.

a tip from experience: if you have a huge repo, "make a copy" to "backup before a rebase" is not always feasible. you could instead make a copy of your current branch (the one you're trying to rebase, ie 'feature/login') by just branching off of that (eg to 'feature/login_backup'). this would keep all the relevant "original" commits, As a branch stores references to commits (and does no copy of actual data), this should be very fast. Then if your rebase completely falls apart or you are not happy, checkout the 'feature/login_backup', delete the (broken) 'feature/login' branch, and branch 'feature/login_backup' again to 'feature/login' (ie like the above, but swapped, if that makes sense). This "restoring with a copy-branch" is then also reasonably fast, depending on what you changed in the rebase. This avoids large copies, and you don't have to touch the '.git' directory (if you had the idea to "just copy that and the few files"). I mean, "if it works, it works", but i would not touch the .git dir at all Also some more shortcuts: the 'fixup' command in the rebase is like 'squash' but it always keeps the first commits message (without asking! so make sure, its the correct order). Useful, when you are "done", but want to make small corrections outside a active rebase (eg, when you need all commits for some compiled language or whatever). So at the end you just need to "reorder and squash" all of that - and when you have a lot of those tiny commits, fixup is faster and less annoying that squash, since that opens the edit-message-file every time. 'break' may also be useful in specific cases. it's like 'edit' but doesn't need a commit. like instead of 'edit' one commit, you 'pick' that and put an empty 'break' after it. this is relevant, when you want to insert something new at the very start (when you don't have a commit to re-order) Very specific, but perhaps for someone easier to understand (as the order is more explicit)?

This was so helpful thanks :) I need video on atomic commit and removing sensitive info from commit

this was so helpful!

nice, could you explain git rebase --onto? Instead of creating a backup folder you can just use the reflog. and again a nice video! keep it up. I recommend your videos to all my colleagues

what if vim is actually my main editor? (P.S. I use arch btw)

Those memes are funny