Видео

nice

really informative video

After git rebase -i HEAD~n I got an error : cannot rebase : you have unstaged changes . Please commit or stash them. What to do ?

Crystal clear explanation! Well done!

clean graphics, love it

great video but the vim part was too obvious for people who use it and maybe confusing to people who don't. I would have kept that out, the text editor is irrelevant at the end of the day, maybe they even have nano configured

Even after 6 years, this was the best video explaining rebase.

Thanks. But if this tutorial is for a beginner, I wish you take it slow and elaborate about merging. When you say git merge localBranch, does it mean merging to local main repo? Because you're now the one to merge to the remote main, it's the lead in my case. Most tutorials I watched, most of them they just spit out what' merge or pull, not.,.../., I can read that

Thank you for making this!

This combination of a simple description of the processes with a clear, simple visualization is gold. Many professional coaches should learn from this. I haven't seen such a good way to explain processes that can be easily overcomplicated for a long time. I bow to such skills.

This series on git commands is easily one of the most easiest I've found to follow, kudos!

Really it is a super helpful video, Thank you!

Your approach of teaching git is awesome. I have cleared lots of my concept by watching your playlist.

wait, i'm still learning but confused by how you rebased on the master branch. Should the rebase be run while on the feature branch? I'm very confused by this and feel lost now. Did you mean to rebase from master? I don't see how this could EVER work if you have other team members like you quoted. This video should be removed or at least have the dangers outlined better. Somebody is going to get into a LOT of trouble if they think they found a 101 how-to. I've learned a lot from all your content so thank you for that.

9:19 That animation is not what a merge would look like of updates in `main` onto shared feature branches. It'd be like the 6:05 animation.

Great, btw, what font is that?

The rule is simple: always use rebase. Just forget that merge exists. In the last 10 years I've made rebase literally thousands of times and I've made merge maybe 5-10 times (when there were big very badly mantained branches not suitable for rebase). Your branches should be small and short living so there should be no problems rebasing

Thank you for this great explanation. To clarify, at 9:18, you say "use rebase to re-anchor your feature branch onto baseline". If I understand correctly, more accurate would be to say "use rebase to re-anchor your feature branch THAT WAS NEVER PUSHED TO THE REMOTE onto baseline"? This would mean, check git branch -a and if you dont see your local branch in remotes, you are safe to use rebase; otherwise, use git merge.

We spend the whole video talking about rebase then in the end say that using rebase to merge into a main branch is bad practice. without any further explanation. When else would we use rebase? our shop is trying to get our developers using rebase consistently. so we're trying to explain to them why we do it

Great series of videos; thanks. There is one very important thing, however, that everyone tends to gloss over regarding conflicts, and this cannot be understated: just because a merge or rebase results in no conflicts does not mean the resulting code is correct! Everyone who actually works in software development needs to be reminded of this constantly. You absolutely need to test your code after doing the merge/rebase (both testing of your new features as well as regression testing). The merging algorithms are not intelligent programmers... Furthermore, because you need to do this testing, it is always wisest to pull in changes from main to your branch and then test before merging or rebasing your branch back into main.

I've just prepared my first hotfix release using your tips. My tag version is going to be in production next wednesday. 😝

thanks for the video!

Thanks bro you just saved me

At 5:06, I didn't get the idea why we checked out to feature branch for rebase to work. Aren't we actually doing it as following: "Change the base of your feature branch to the latest commit (head) of the master branch"..? I'm a bit confused here, pls help.

Your videos are an absolute gem. Thank you

Linus Torvalds and Ada Lovelace. You have friends in high places 🙂

3:09 You lost the instagram_username line from the bugfix commit LOL.

Beast video! Thanks.. I just got my new mac today and this video helped alot!

dude! so envy about the city, nice content tanks a lot for sharing

Great class! Thank you!🙏🏼

this is so helpful, thanks man

gooog

6 years later and this is still an amazing video! Super clear and intuitive, thank you!

Nice format. Thanks

git config --global rerere.enabled true git config --global pull.rebase true That’s the way

Nice explanation, thankyou

Crystal clear ! I'm glad I've found your channel and eager to discover more

Excellent explanation and a nice, clean video. Well done. Subbed

Excellent videos, have been using git but I had lot of confusion about many basic concepts, luck i came across your videos with very crisp explanation with awesome graphical representation which makes it very easy to understand. Keep up the good work, looking forward for more informative videos..

SUPERB... Video. Crisp and upto the point. Nugget sized videos - addressing specific topics THANK YOU SO MUCH This video saved me a lot of reading and researching time

I came to Git from SVN -- and the ability to modify history was probably the hardest thing to wrap my head around. Not only that it was possible, but that there were situations where it is actually desirable! Now ... well, I could not go back to SVN! 🙂

Thank you, till now I faced difficulty about cherry picking, but after watching this video it made completely sense. Thanks again.

How do you make such beautiful animated presentations?

Hoping I see you point out rebase leaves a clean tree, merge creates new commits.

I always merge latest from main/dev branch into my feature branches, so my feature branches always up to date. Then PR into main/dev branch when I’m done with a feature

Nice edit and animation

To clarify a common misconception: A "tree" in the context of Git does not refer to a commit history (because that is not in fact a tree in the mathematical sense due to merges, actually it's a DAG) but it refers to a snapshot of the repo, i.e. the content of a commit and therefore a filesystem tree. That might be important to know so not to get confused when reading the Git docs and learning about the Git working tree.

It's simple, never fucking rebase. The very concept of rebasing is fundamentally flawed and only used by damaged OCD people.

شكرا جزيلا .. thanks' a lot man

I think you may have an incorrect mental model of vim. The escape is not part of the quit command. The default mode in vim is the command mode. i puts you into insert mode and escape leaves insert mode and returns you to command mode. Colon moves you to another mode: ex mode where you can type ex commands. The ex command you're using in this situation is wq. If you're using escape before quitting even when in command mode, then it suggests you're not thinking of insert mode as something you dip in and out of before returning to the steady state of command mode and possibly missing out on the incredible power of command mode.