MORE GIT VIDEOS: ukposts.info/slow/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM

BY FAR, the best channel on git

Great video. I've been using Git forever, and this is probably the best explanation I've ever seen of merge, rebase and fast-forward.

Probably the best videos about git, out there. The animations are a huge help. Thank you so much!

Amazing tutorial !! really appreciate posting this tutorial explaining "git merge" and "git rebase"

Best git videos on youtube!!

Your videos are the most clear I ever seen on this topic and still contains enough details

Fantastic. I've subscribed !!

great stuff

Great explanation. Well done!!

This is the best git videos on youtube. This is amazing work. I am begging to you please move whole git with kind of videos

Thank you!

I'd like to think of both as merging, but done differently. Here's how: "Git merge" from a current branch into the target branch is when Git takes the latest changes of the current branch, then take the latest changes of the target branch and combine them. The new combination is made into a new commit and placed as the latest commit of the target branch. Git will still keep around the history of all the commits that had been made up until the merge of either branch. "Git Rebase" from current branch into target branch is when Git first takes all the commits from the current branch, lines them up in the order they were made and puts them aside for now. Then Git takes the oldest commit from current branch and "merges" it with the latest commit on the target branch by doing it like a regular merge: combing the changes, make a new commit that represents those combined changes then places that new commit as the latest commit on the target branch. Then Git moves on the second oldest commit on the current branch and repeats the process. All the way until the latest commit of the current branch is merged. But remember, the current branch is still set aside, what will Git do with those commits that have effectively become duplicates? Git will just delete those commits, hence why history has been rewritten. Hope this helps

Excellent content, don't stop

Great video! You seriously deserve more recognition.

Great video! Thanks

First time i have seen such an attractive videos regarding git, captivating !!

Just amazing!! Thank you so much for your work! Nothing even close to your explanations of the work of git does not exist.

Excellent video, I've always been worried about using rebase, this helps massively

Amazing 😮

Thanks

Great video and explanation! I honestly can't think of a scenario where I'd want to rebase, versus just using merge. The risk outweighs the benefit, and honestly the overhead of a merge process on your local repository is moot. Just my two cents.

How to handle the case when while doing rebase and we encountered conflicts ? Best video i found for my confusion on rebase and merge ❤

Excellent

Hey man, amazing video with great illustrative animations out there. There's just one thing which I found confusing. So in most of the scenarios that I have worked in, the git workflow looks something like this: 1) Create a feature_branch from main: `git checkout -b feature_branch`. 2) Makes changes to your feature branch: `git add -A && git commit -m "Your commit message"`. 3) During the development process some changes were pushed and merged to the REMOTE main branch. So you need to sync your LOCAL main with the REMOTE main: `git checkout main && git pull origin main` Once that's done... 4) You checkout your feature_branch and merge the updated local main with your feature_branch: `git checkout feature_branch && git merge main` 5) You push your local feature_branch to remote and create a pull request: `git push origin feature_branch` In this workflow we can probably replace the merge thing in step 4 with a rebase thing, if this feature branch is being worked on by a single contributor. What confuses me in the video is that at 5:40 : when we are on the feature branch we run `git rebase main` and then we checkout to main and run `git merge feature_branch`. Maybe that's done to illustrate fast forwarding merge here but in a production workflow isn't it discouraged to merge directly onto the main branch? Let me know if I missed a point or something.

This was great. My current job, devs keep telling me to rebase and I ask myself "why not merge". This explains it lol. Thx!!

You are the best

In flow, when we have master branch and release branch for patches, when developers have merged master changes into they feature/fix branch, it is hard to rebase it to patch release branch.

I absolutely agree with what you said towards the end and that's what I like to do: rebase on personal feature_branch, merge the feature_branch on main. But how can we do this when doing PRs? I mean...you can do rebase and merge, but if there are conflicts, who should deal with them? How to organise with the team?

Can you do a video of How to revert already merged branch from a main branch.

There is a main branch and a feature branch which is based on main branch commit MBC1. Now my other developer added MBC2 and MBC3 commits in main branch. I commited FBC1 and FBC2 into my feature branch. When i want to incorporate those two commits of master into my feature branch, i will do a rebase with master. After rebasing, i end up with same two branches master and my feature branch where master history is not changed but my feature branch will contain MBC2, MBC3 commits added and then after these two commits, my individual commits will be added in the history of my branch wvich are FBC1 and FBC2 . Is my understanding correct ?

😮 Excellent video! Btw, what is the cool font used in the videos? JetBrainssMono Nerd Fonts isn’t it?

Great explanation. I have a question: you mentioned using rebase is not recommended when there are multiple contributors working on the same branch because the remote and local version will diverge. But when same branch is shared by multiple people at the same time, doesn't it diverge anyway because of different commits by the contributors? If yes, which specific aspect you are talking about?

Hi I have a question. I have a parentfolder which contains 4 Javascript project subfolders. I have git on the parent folder so I could upload all the subfolders to one folder on github . I also have git on every subfolder to manage each project. In total I have 5 gits, is it legit to use it like that or is there a better way? I just want to group the projects in one folder on github.

@TheModernCoder pls make video on git stash too

Great video. Thanks. What software fif you use to animate?

The quality of this video is 10x the other ones that you can find around

wow

I my case rebasing onto main creates way more conflicts than merge main into feature. Why is that happening? Is there a way to prevent this?

Nice video but it would be even nicer if you could demonstrate it with the github and merging options of pull requests so not locally but remotely too ;)

What about rebase one-author feature branch to multi-author main branch?

Okay, now that I actually know what Rebase is, number one, the name makes a lot of sense. You're "rebasing" where your branch starts. But two, this doesn't seem to be an accurate history of work anymore. We're pretending that I started my work after whoever got their changes into main, somehow that feels wrong.

Will rebase delete the original commit authors?

gogo gaga

Why would multiple people ever work on the same branch? Isn't the entire point of branching to allow each individual a branch and thus deal with version control? If 2 people start working on a feature, that feature should be split into 2, or 3, or 1000 branches for each individual. Then each person should be merging or rebasing on that feature branch, resolving conflicts before again merging the feature history onto main. You'd have to be crazy to have multiple people working on a single branch! IMO

ukposts.info/have/v-deo/sn-fq52voHlhsHU.htmlsi=NcGWivMhokq4XNCM&t=326 What do you mean by "replaying" each commit? Are they actually getting merged with the latest commit from the main branch?

Very perfect but you speak too fast. slow it down a little bit

Nice but too abstract 😢

You have great content. Following you is hard though. Why? You aren't pacing yourself when you speak. Slow down ! You are speaking for others to absorb what you are sharing.