git rebase - Why, When & How to fix conflicts

[@philomatics]

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/

[@AhmedGamal-mm4sp]

can you also please make a video that explains everything in the cheatsheet?

[@philomatics]

@@AhmedGamal-mm4sp Hah, working on it! :D

[@b213videoz]

I know a guy who, upon having been fired, committed his changes but never pushed them 😁

[@cola5323]

I can’t seem to subscribe! It keeps giving me “TypeError: Load failed”

[@philomatics]

​@@cola5323 Hey, thanks for letting me know! Which browser are you using? Do you get the error when trying to submit the form, or later?

[@rascta]

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.

[@philomatics]

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 kzbin.info/www/bejne/amOWamWNbLiapKc

[@MGenrih]

I prefer linear history over sanity

[@mirasowndaryar5049]

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. 😭

[@bobDotJS]

I have been doing this for years professionally and just learned about cherry picking. Thats why your channel is important. Git education sucks.

[@thedelanyo]

This channel is a gold mine. Please keep it up. 😅😅

[@philomatics]

Thank you for the nice comment, made my day :)

[@arungowda]

BEST VIDEO ON REBASING EVERRRRR. Thanks for making this

[@Lavless12]

I need more content like this, it's very useful and it keeps me focused while programming

[@ARKGAMING]

The first two minutes I was like "our team squashes the commits so the merge commits don't matter" But of course you pointed it out as an option

[@privateagent]

Same. Problem with that, you lose track of what you did for 2 weeks while working on a feature

[@saurabhsoni5047]

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.

[@philomatics]

Wow, thank you!

[@streettrialsandstuff]

I'm using rebase for many years now. It's the best way to deal with history and conflicts.

[@adrians9367]

You explain it so easy I hope you keep with this type of git videos 😅

[@2012mindmaster]

Very good explanations. I confess I´ve worked with git for many years without fully understanding the rebase concept. Thanks a lot

[@philomatics]

You're not alone in that :) Thanks for the kind words!

[@vladislav_artyukhov]

Beautiful explanation. I haven't found some good guides earliers, and now found perfect

[@wadecurry938]

You tell beginners to switch away from vim!?!? The learning curve is GOOD for ya!! It made me what I am today!

[@philomatics]

"A good beating never hurt anyone" - Albert Einstein

[@CottidaeSEA]

Really good video, it tells exactly why I am hesitant to ever recommend rebasing. I'm glad you mentioned you were working on it in the replies.

[@stanislavkozak2806]

Wow! Such a clear explanation. I should have watched it before I started fighting the Lord of Branches myself. 😅

[@alperari9496]

Funny that your video was uploaded yesterday and i just today had to do a rebase for my company's project and referred to your video. Thanks!

[@sahil_singhai]

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.

[@volodymyr.brodskyi]

I like your videos! Really informative!

[@PbPomper]

You can also run git merge --continue (that's what I usually do). You also get an autoamted commit mesage you can change.

[@reinhardlackner1925]

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.

[@avramitra]

Awesome tutorial. Thank you. Please also make videos on git squash

[@philomatics]

Thank you! Coming up soon :)

[@НазарПанасюк-у8я]

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!

[@sahajmalla]

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

[@nandordudas]

"never push if" - you can do anything on your branch (rebasing + force pushing, etc.) until any other users not connected or touching your branch

[@TokyoXtreme]

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.

[@TokyoXtreme]

@@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.

[@philomatics]

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.

[@DaveSteinberg]

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.

[@ghun131]

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

[@residual-entropy]

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. :)

[@askolotus_prime]

Please make more videos! I'm learning proper git and very interesting in Squash and other best practices

[@lmoelleb]

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]

@@lmoelleb right now I'm squashing before creating a PR, because it makes no sense to review 20-30+ small local commits for my team

[@lmoelleb]

@@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.

[@DK-ox7ze]

I have always used git merge and yes it creates a messy history, but I have never found that to be a problem.

[@lmoelleb]

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.

[@m4l490n]

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.

[@srki22]

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?

[@m4l490n]

@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.

[@jinx.love.you.]

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]

Thank you for the suggestion!

[@hollow_ego]

I'd like a video about merging strategies for bigger teams and scenarios where you might need work from a different feature branch

[@philomatics]

Thanks for the suggestion! Do you have a concrete scenario that you've run into in the past that was difficult to handle?

[@hollow_ego]

@@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.

[@hollow_ego]

@@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.

[@hollow_ego]

@@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.

[@philomatics]

@@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).

[@Z3r0M1st]

Very easy to understand the topic git rebase, your explanation is easy to git(get) hahaha

[@VincentOrdioni]

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...

[@philomatics]

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 ^^

[@VincentOrdioni]

@@philomatics Yeah, it's scary... Great video though, and very good channel in general, keep it up!

[@greyshopleskin2315]

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

[@royler8848]

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

[@MrMassaraksh]

You can create fresh branch locally. Rebase it and then push to merge

[@spiffjekey-green4034]

You just got yourself a new subscriber :)

[@philomatics]

Welcome aboard! :)

[@tobiasj8019]

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!

[@privateagent]

I'm genuinely this dude 2:55

[@Soromeister]

Yes, please Squash us with more info.

[@Zeutomehr]

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

[@MsSLOOM77]

Thanks for sharing this video ❤

[@rbfndz]

All hail team rebase. Branch history as straight as bamboo 😂

[@AnggiWijaya]

your voice and choices of memes reminds me of @ModestPelican gaming channel 😂 7:07

[@bboydarknesz]

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.

[@philomatics]

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.

[@emersongabrielrochanobre9319]

great job, you have got a new subscriber

[@PbPomper]

We only allow rebasing on your own dev branch that stems from a feature branch. Of course you need forcce push peromissions here.

[@drakezen]

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..?

[@philomatics]

Thank you! Also, thanks for the suggestions, will consider it!

[@Kitsune_Dev]

yes, please make a video on Squash merge😊

[@philomatics]

Thanks, will consider it if there's enough interest :) Got a lot of other stuff already planned, stay tuned!

[@lucianodesa1]

If you use "git push --force-with-lease" it is fine to push to remote.

[@philomatics]

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.

[@sahajmalla]

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.

[@philomatics]

That's a good suggestion! Didn't want to do squashing as well in this video as I thought it would be a bit overwhelming. But definitely a good option.

[@sahajmalla]

@philomatics no problem. I'm just sharing the users to know that this is also an option instead of being overwhelmed by lots of commit's conflicts

[@philomatics]

It was a really good point, I wish I would've included that in the video. Maybe in a follow up :)

[@Ripcraze]

Rebase gave me so many issues in the past with endless conflicts, since then I never rebase, only merge.

[@DarshanKMANJUNATH]

Some time we see the branch diverge message which will stops pushing to remote. Please make a detailed video for these kind of edge cases

[@philomatics]

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.

[@philomatics]

Here's the video: kzbin.info/www/bejne/rn-UXmWmZZuIqMU

[@infinite4evr]

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]

Thanks for the nice comment! I'm using Motion Canvas :)

[@infinite4evr]

@@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 😊

[@desmontandolaweb]

This.. mate is good stuff!

[@shis10]

Very helpful video.

[@grymmjack]

:D rebasius lord of branches!

[@SimoneCattaneodango]

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?

[@philomatics]

In my opinion, it's fine to keep branches local and rebase as much as you like before you push.

[@SimoneCattaneodango]

@@philomatics got it, thank you so much 😀

[@FarukLuki111]

So if I already pushed my branch to „origin“ I should not use rebase? That makes rebase useless (for me)

[@philomatics]

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.

[@mtahiralauddin]

A free advice for your KZbin 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

[@philomatics]

Thanks for the feedback!

[@69k_gold]

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

[@854gabryel]

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.

[@philomatics]

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.

[@diegocraftxx_gd9214]

Nah this videos are fucking awesome

[@OpenDeepLearning]

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.

[@philomatics]

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 (KZbin About page) if you want :)

[@MikelAingeru]

Good explanation, better memes 🤣

[@FelipeV3444]

Based video

[@yuxiang4218]

great video !

[@josetovarrodriguez3525]

Hey dude i always have problem with git rebase command, it ever rebase in main/master branch and nt in feature branch

[@philomatics]

Hey, what exact command(s) are you using? What's your branching structure (what's the output of git branch -a)?

[@josetovarrodriguez3525]

@@philomatics 1. It is a complex structure righ now 😅 2. git rebase master (from feature branch)

[@philomatics]

​@@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).

[@josetovarrodriguez3525]

@@philomatics oh sure thanks dude I appreciate. Blessings for your

[@funkjoker]

Just found it. Please tell about git rerere, to not resolve same conflicts everytime you go to next commit

[@philomatics]

Thanks for the suggestion! Might make a video on this in the future (might be a while, got a lot of stuff in the works).

[@tanujkanti1088]

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!

[@philomatics]

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.

[@philomatics]

git interactive rebase - Undo, Edit & Squash git commits with a single command kzbin.info/www/bejne/amOWamWNbLiapKc

[@tanujkanti1088]

Thanks I'll try that

[@sineshkumarr]

Tutorial on Rebase + Squash

[@TheThirdWorldCitizen]

git pull origin main -rebase gang

[@srki22]

Maybe it works in small teams where you don't have several people committing to the same branch.

[@TheThirdWorldCitizen]

@@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.

[@unskeptable]

Sweet video

[@shlokbhakta2893]

If anyone has run into a conflict with unity and git knows what pain looks like

[@waynelau3256]

When in doubt, force

[@thilakreddy1904]

😂

[@mivalentine2794]

Iam convinced that it probaly took weeks to beat Rebasius, Lord of branches.

[@krissh_the_dev]

I want the video on interactive rebase 🖐

[@severgun]

In previous video you say "use pull rebase". Now you say it is not a good idea to rebase if pushed. Can I have more comments on this?

[@philomatics]

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 :-)

[@someonesalt5084]

When are you actually working on a branch that isn’t pushed?

[@philomatics]

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]

@@philomatics I guess it feels pretty useless as most projects are collaborative

[@philomatics]

@@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: kzbin.info/www/bejne/rn-UXmWmZZuIqMU

[@r-i-ch]

Squash! Squash!

[@philomatics]

Do you mean "you should squash", or does that mean you'd like a video on squashing? :)

[@andregoncalves-sm5ii]

What is your opinion on doing git rebase onto another branch?

[@philomatics]

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.

[@andregoncalves-sm5ii]

@@philomatics thx

[@JasonCage-y2d]

Just a reminder: there are no links to videos in the description.

[@philomatics]

Hey, thank you so much for letting me know! I completely forgot about that. Thanks!

[@JasonCage-y2d]

@@philomatics NP. Keep making videos like this.

[@El_Remolino19]

godlike content, and at low subs. thats ripe

[@philomatics]

Thank you! Channel is still pretty new :) Please share with colleagues, every little bit helps :)

[@El_Remolino19]

@@philomatics nah man, this knowledge is just for me. jk what other sorts of videos do you have planned?

[@philomatics]

I got more stuff on git in the works - any specific requests about other topics? :)

[@AkashSingh-hs5sg]

Squash

[@philomatics]

Do you mean "you should squash", or does that mean you'd like a video on squashing? :)

[@AkashSingh-hs5sg]

​@@philomaticsvideo on squash

[@DerSolinski]

Guys, guys... GUYS!!! LISTEN FOR ONCE! I know you like the pretty rainbow... but you're doing it WRONG!

[@j.r.r.tolkien8724]

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.

[@jp93k]

Yeah but the history on main matters not the history on your random branch whilst it is still a work in progress

[@dvdrtrgn]

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.

[@abdullahX001]

$5000 for the workshop? Welp

[@philomatics]

The workshops are more for established companies that prefer personal interaction and support :) Stay tuned for more free content here and on my site!