Can someone tell me how to properly rebase changes from main branch

I always fuck myself over. Fucking merge conflicts i caused by myself. Since the CD pipeline creates a commit or i merge into main from a side branch, i often forget to pull those changes locally from main branch

What happens then is i just create a new branch to start working on the next feature

git checkout -b feature/shit

Totally forgetting to first do

git pull --rebase

From main branch. Because of this when i push shitload of features to feature/shit branch and then try to merge that shit into main. CD pipeline gets fucked. There are merge conflicts now because i havent rebased

Question -- if i switch to a new branch, make a shitload of changes and forget to rebase from main branch First, what command do i type to rebase right there (on the new branch) but rebase from main branch so these conflicts dont appear?

🍿🍺

@retoor when i try to rebase from main on a new branch it just causes a downward spiral that makes everything more fucked the more i try to get out of it. So i want to know the proper correct way of doing this. Im probably over complicating stuff. It's impossible to know everything. You learn stuff as you work. So whats your answer to this problem?

Create a branch from your base and then cherry-pick the commits one by one if you’re really messed up. Otherwise while on the feature branch just do

git pull origin develop —rebase

This should update the base and apply your commits on top of it. It gives more control

@b2plane just branching from main & pull & rebase a lot in your branch. That's what I do. I never use git magic

Checkout main
Pull
Checkout your branch
Merge or rebase from your now updated main

git fetch
git rebase origin/main

It's not that complicated. If you have messy conflicts either the codebase is very spaghetti and those are natural or (if you fix the same things over and over in a single rebase) your branch history is messed up, so you should clean that up beforehand with an interactive rebase.

Bonus point for using `git rebase <base> <branch>` instead of checking out your <branch> beforehand to optimize IO for older branches.

Isn't it faster and safer to just squash a merge request instead of rebase?

@PappyHans thats the exact command i use. But then it just gives me deeper problems. The new branch is now 4 commits ahead of main and tells me to git pull. When i git pull then "error not possible to fast forward, aborting". The mess piles up

@retoor while on main, when i git pull rebase and Then switch to new branch, thats fine! But it gets fucked when i first switch to new branch, commit to new branch but havent git pulled prior

@SuspiciousBug that button is greyed out for me because of merge conflicts which im trying to resolve

@b2plane Wait... button?

@c3r38r170 button on github when u create a pull request to merge tbe side branch into main

@cafecortado @saucyatom it works now the conflicts are gone. thanks

Just a longer explanation cause some comments made my eye twitch.

Git has local and remote support - it allows operating on both *locally*.

https://git-scm.com/book/en/...

origin is the common alias for referencing the remote ....

git merge feature/XY
git merge origin/feature/XY

are two different things.

One refers to the local reference, the other to the remote reference.

@saucyatom did include the fetch, so that information of the remote is up to date in the local git repository.

Important detail, often overlooked or misunderstood. git pull is a combo operation fetching and then merging...

Another detail: Test before destructive operations.

Git branching is cheap.

Just create a new branch *after* checking you don't have staged / uncommitted files and then test before creating a cluster fuck and loosing data.

Last important detail: Wether the remote branch was updated with rewriting history.

If the remote has a rewritten history (squashing, rebasing, ...) you will get funky results.

Cause your local copy and the remote history have diverted.

Usually git should tell you that, I just mention it explicitly because I have seen too many devs *not* reading the warnings of GIT and wondering why the fuck everything broke.

Yeah. Mashing together two different histories = bad idea.

Happy that you achieved it, but maybe for future reference ;)

Thank you for sharing an alternative approach.

If everything else fails (history rewrite magic or rebases directly on main or whatever black magic fuckery other devs came uop with), you can as a last resort always just check out main into a new branch and cherrypick your commits from your feature branch one by one ontop of it - solving conflicts as you go.

@b2plane this would only work if you didn’t already pushed to the remote. Your remote is always going to be behind because you updated you base and its no longer matching the remote. In other words your base will have more commits preceding your changes. You need to force push to the remote (not recommended) or create a new feature branch and cherry-pick the commits

@PappyHans exactly. And i always avoid force pushing cause that usually ends up catastrophically

I do this.

* git checkout -b new_branch
* Work, git add, git commit -m, git push, repeat
* Git checkout main && git pull
* Git checkout new_branch
* Git reset --soft main
* Git commit -m "finished feature"
* Git push --force

The reset and commit squashes and rebases.

@b2plane force pushing is there for a reason, but it has to be justified and done primarily in cases where there is no other way around to fix your problem but to use force push ignoring all git checks.

I have to deal with constant rebases and that’s why I only push my local changes to the remote when done and creating a PR. If I have to update my feature branch with the remote after I pushed then I only use merge, as merging the changes from the remote branch is creating a new commit on top of my changes as opposed of changing my base and then applying my commits on top.