I'm working on a free git cheatsheet that will (hopefully) put all other cheatsheets to shame. It'll have animations like in this video, and will be interactive. If you want to get notified when it's released, please leave your email here: philomatics.com/
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.
This is a great suggestion! I would add that you can at least attempt the rebase once before squashing, and only if you get conflicts, abort it using git rebase --abort, then squash, and then rebase again. I explained squashing in detail on my video on interactive rebase. git interactive rebase - Undo, Edit & Squash git commits with a single command ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-42392W7SgnE.html
I faced this exact situation and was horrified when I saw my old code instead of my latest code. Tried resolving the same conflicts for multiple commits then ended up aborting and pulling the latest master into my feature branch. 😭
This video needs to reach masses ! Exceptional explanation - to the point and succinct animations !! There are abundant videos on this topic but this one really stands out - Wow! Thank You for putting in so much effort to make this - I have consumed this and I am grateful.
Dude, Respect. Love this video and even my manager 6+ year exp don't know how does rebase work. but I know now. please use more examples like the one you did here, that helps alot to understand better. giving you a subscribe buddy.
my philosophy is like this: feature branches belong to a single developer only. even if a reviewer pulled a PR (so he pulled the feature branch), I would not recommend or allow it that he would go on and work with that (reviewing only is fine though). It it is agreed on, that a branch only belongs to one dev, you only have to do force pushes to origin and you are fine. and, if there would be many commits I'd have to go through during the rebase phase, either do a squash beforehand (on your feature branch) or, do a reset with keep local changes just one commit before you started, stash them away, rebase, then re-apply the stash. but, in the end, there can only be one (dev) to rule the feature branch so you can be confident to force push to origin after the rebase.
great video as always. previously i thought, when i have a rebase conflict i should do `git add` , `git commit` . i didn't know about `git rebase --continue`. 🤦♂ thank you very much!
If there are no new changes or file added (check by git status) after rebasing, you don't even need to git add --all. You can directly git push --force or --force-with-lease
That's the true golden rule of rebasing. I would add that only use "merge" when two branches should become one - leaving one of them to be permanently discarded. Technically both branches become discarded because they have been "merged" into a new one. Otherwise, collaborative feature branches should just cherry-pick any critical code that appears on the main / master branch.
@@squishy-tomato To paraphrase The Simpsons: "I'm just going to sit here and push my commits and rebase as I like, and if you get hit, it's your own fault". But I do use "with lease" just in case. I don't really consider my feature branch "public" until I've made a pull request or have asked someone to branch off of it and make use of my work. And by that point I'm only cherry-picking anyway, in the rare event I need to pull code from higher up in the flow.
Agreed, for the video I thought I'd rather make the rule a bit more restrictive than not, so people don't mess up their repos accidentally. But yeah, as long as you know that nobody else is pulling/pushing your branch, you're fine.
I'd say the rule should be don't commit on other people's branches. Then everyone can rebase and force push their own branches to their hearts' content and no one gets hurt.
Nice video! Would love on one squash-and-merge and how it compares to rebasing. I’ve used both a decent amount but don’t feel like I totally understand the pros/cons/differences. :)
Squash is not a "best practice". It is extremely useful if: 1) you create a bunch of local commits without bothering with proper comments. 2) you do not know how to use "first child only" when viewing git history. But if those two do not apply to you you are probably better of with merging.
@@askolotus_prime we review the merge request. The only annoying thing is creating a branch for even single commits, but as none of our branches live that long it is not a big deal. The team can choose to look at the individual commits if they have a reason to do so, but the default view will show all changes. If the PR is updated, they can again choose between seeing all changes again or just seeing the changes since the PR was created.
Any semi-capable git client will allow you to view the first child only in the history. Gives pretty much the same view as squashing but you can easily get access to the full history by simply turning the option off.
I always do rebase, even when I have pushed multiple commits. When that happens, I just do git push -f origin . I've never had any issues with this method, and I've been rebasing like this for years. If you think about it, once you rebase, what's on the remote doesn't really matter anymore. What matters is the new rebased branch, so a git push -f is perfectly fine.
That is ok if you are the only person working on a remote branch. If not, then it is better to use merge. When you check the history of the main branch, you can always filter by merge message or show only first parent. I never heard anyone complaining about messy history. I don't know why it is so hard for some people to filter git log?
@srki22 Why would there be more than one person working on a branch? And if there are, you always make sure you have pulled the most recent changes before force pushing.
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...
@@philomatics Yes, indeed several different. For a long time I was working with only one colleague on a project where we either only had one branch and rebased when getting the changes from remote or we worked independently on two branches. That worked absolutely fine. On the following project I worked with about 4 other frontend developers, where we worked pair wise on feature branches. For remote changes we rebased and the same for changes from main. So our feature branches would always be based on the latest changes from remote. We used force push with lease to update the remote feature branches, which of course required some communication. We had a lot of merge conflicts to resolve, which partially was due to project wide changes that affected our feature as well. In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB. At the moment we handle this with rebasing, like so: - Branch featA is created - featA is implemented to a certain degree - Branch featB is created based on featA - Changes from featA are integrated into featB via rebase - featB is implemented to a certain degree - featC is created based on featB - Changes from featB are integrated into featC via rebase - featA is finished and gets merged into main - featB is rebased onto main - featC is rebased onto featB - featB is finished and gets merged into main - featC is rebased onto main - featC is finished and gets merged into main - Done So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements. Overall this works good, however we still have to force push with lease. Just yesterday, so right before your video, I was explaining what to look out for when rebasing and how the hashes change and that git wouldn't be able to tell that your local commits after the rebase are the same as the ones on remote. I asked them to always communicate a rebase beforehand, especially since those colleagues haven't worked with rebase before. My other colleague, who brought up this way of working, is more experienced and said he doesn't even have issues if he still has local commits. I assume this is still fine because we are still rebasing when fetching remote. Previously we worked in such a way that you would only start featB when featA was merged into main. But that slowed down development.
@@philomatics Yes, indeed several different. For a long time I was working with only one colleague on a project where we either only had one branch and rebased when getting the changes from remote or we worked independently on two branches. That worked absolutely fine. On the following project I worked with about 4 other frontend developers, where we worked pair wise on feature branches. For remote changes we rebased and the same for changes from main. So our feature branches would always be based on the latest changes from remote. We used force push with lease to update the remote feature branches, which of course required some communication. We had a lot of merge conflicts to resolve, which partially was due to project wide changes that affected our feature as well. In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB. At the moment we handle this with rebasing, like so: - Branch featA is created - featA is implemented to a certain degree - Branch featB is created based on featA - Changes from featA are integrated into featB via rebase - featB is implemented to a certain degree - featC is created based on featB - Changes from featB are integrated into featC via rebase - featA is finished and gets merged into main - featB is rebased onto main - featC is rebased onto featB - featB is finished and gets merged into main - featC is rebased onto main - featC is finished and gets merged into main - Done So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements. Overall this works good, however we still have to force push with lease. Just yesterday, so right before your video, I was explaining what to look out for when rebasing and how the hashes change and that git wouldn't be able to tell that your local commits after the rebase are the same as the ones on remote. I asked them to always communicate a rebase beforehand, especially since those colleagues haven't worked with rebase before. My other colleague, who brought up this way of working, is more experienced and said he doesn't even have issues if he still has local commits. I assume this is still fine because we are still rebasing when pulling remote. Previously we worked in such a way that you would only start featB when featA was merged into main. But that slowed down development.
@@philomatics I wrote rather detailed reply, but my comment seems to go missing. I can still give you the whole description if you want, but for now the short story: In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB. So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements. Overall this works good, however we still have to force push with lease.
@@hollow_ego Thank you very much for describing the situation! I'll see if I can work this into a future video. Feel free to email me if you have further questions (email in YT about page).
The potential mistake with pushed commits is why we don't use git rebase by default instead of git merge at work, unfortunate, this is so much cleaner...
Yeah I think there's a lot of fear surrounding rebase, but sometimes it's warranted ;) I think many of us have horror stories of messing up our repos with a rebase ^^
Well, for feature branches i dont see much problem. You can do before a backup branch either local or remote. If you understand rebase and other git commands, theres really no problem. Specially if you know how the reflog works. Everything is reversible. But it is true that most people don’t spend a lot of time learning git. So it is understandable. In my case, I usually work with feature branches where I am the only one commuting, so I do crazy stuff lol. When merging to main I do a squash merge because that’s the policy
The conclusion we came up to is we almost never have 2 people working on the same branch, and if they need the same WIP code that will both cherry pick it, and then one of them will merge to master and the other will rebase on top of master and discard the cherry picked wip stuff
7:00 it probably opens your default editor you can configure that by setting VISUAL or EDITOR or by running update-alternatives or whatever your distro calls that program
So, it means that git merge is better than git rebase? Since I can push my changes whenever I want without afraid of conflict like git rebase, and have to resolved it one by one. Since I usually changes between branch while developing but have to create another branch from main for fixing.
I wouldn't say one is better than the other. It depends on the situation and the workflow in your team. Also the number of merge conflicts you get doesn't change much either way.
I love Vim....and I also love your channel. Great work. For other topics, do you want to get into other devops tools such as K8s, Nomad, Terraform, etc..?
Thanks for the comment. Gotta disagree with you here though. --force-with-lease will prevent most accidental deletions, but it'll still cause headaches when your coworkers pull from that branch again.
Instead of going through commits one by one at a time for conflicts, it would be easier if we squash the commit into 1 commit and then try the rebase. This way you will only have to deal with 1 conflict.
Thanks for the suggestion! Have you seen my video on pull rebase? It might shed some light on what's happening. Basically, when your push is rejected, that's usually because someone else has already pushed on that branch.
Hi, great video, Me and my colleague were discussing on the rebase disadvantages and this video popped up, great explanation. Meanwhile, may i know what animation software or library you're using to creare your videos ?
@@philomatics thank you ! Btw only some videos and your subscription base much more explains that you're doing so good at explaining crisply. Power and success to you 😊
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?
Wait so I’ve been doing this wrong my whole life? Basically: I push my changes to my feature branch. It stays in review longer so other people merge their feature branches in the meantime into master. I see this and I rebase locally and then force push to my feature branch. And it works every time. What I don’t undertand is how people can lose commits because you only mentioned it but didn’t explain. My feature branch is not used by anybody except me. So if those old commit hasesh are being changed, there’s no issue because nobody has them anyway.
That workflow is totally fine :) Like you said, if you're the only one working on that branch, there's no risk of losing anything. A lot of teams are not as structured though, or they're using a different branching flow entirely.
You _can_ also rebase a branch that you pushed, but you gotta be sure that nobody else has pulled it or pushed to it. So if you're working on your own feature branch where that's the case, you're still safe.
8:20 - I do want to see a full video on this. This was my scenario today: I created like 12 commits today. In the 3rd commit I forgot to add into the commit a line from package.json. I rebased using interactive mode, edited that commit, staged the changes and then git commit --amend. It said there are no changes or something. If I wrote git rebase --continue I was getting an error that I have conflicts and need to resolve them. I had zero conflicts. Fast forwards, did this multiple times and advanced a bit and somehow at the end another file (it was un Changes state) was committed idk how. Eventually I gave up, I have created a separate branch, cherry picked and edited the commits and that was all... git rebase is hard. Need your help.
Hmmm kinda hard to diagnose remotely but it sounds like your general approach was correct. You'd basically set the 3rd commit to edit when starting the interactive rebase, make your edits, and when finished run git rebase --continue (no need to amend but I think it also shouldn't hurt). Then when running into conflicts, the process is the same as in this video. I'd have to see precise error messages to give more help probably. You can email me (RU-vid About page) if you want :)
@@josetovarrodriguez3525 Hmm, I think I'd need more info, like a precise error message, to help you here. You can also email me if it's easier for you (email in my YT about page).
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!
Depending on your situation, it can help if you squash first before doing the rebase. Check out my video on interactive rebasing to see how to do that.
@@srki22 ??? Unless you really really REALLY have to collaborate in the same branch with 1-2 more people, there is no other scenario several people should be using the same branch. The best way is always to send a pull request to the dev or the main branch.
Sure! So in the previous video, the commits that were rejected by the remote, the new ones on your computer, were not yet pushed. Since they are rejected when you try to push, the server doesn't have them yet - thus it's totally safe to rebase them with git pull --rebase. Let me know if anything is unclear :-)
You _can_ also rebase a branch that you pushed, but you gotta be sure that nobody else has pulled it or pushed to it. So if you're working on your own feature branch where that's the case, you're still safe.
@@someonesalt5084 Well, it really depends on your branching workflow. If you commonly work on the same branch as a team member, this video might help you more: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-xN1-2p06Urc.html
Sorry, not sure I understood the question. Do you mean rebasing onto another branch than main? Nothing wrong with that if the situation calls for it. The main thing you gotta watch out for is if the branch/commits you're rebasing have already been pushed.
If you wait to long with a rebase you get (maybe) a lot of conflicts too. I use a git rebase --onto the most time. Do you want to explain it or i could :-) btw. your teaching is awesome!
Rebase is cleaner, at the cost of lost information, having two parent commits isn't a bad thing, atleast that way we can pinpoint the exact point of merge without needing to read 10k commits
I don't think there's much benefit of using a versioning system if you're just gonna discard the history like that. There should a different tool for you guys.
Git is the system for tracking **and** managing history. Sometimes I wanna get rid of a bunch of junk from history. I love git and I squash and re-base all the time.
A free advice for your RU-vid Channel to grow. Please don't add distractive material like memes or stuff, it takes away the focus and we get distracted. AWESOME CONTENT THOUGH. I really wish you grow man