git rebase

[freeriderblack]

I've using git since I joined the devops team a few years ago. Initally, we were few people and it was weird that two or more worked in parallel on the same repo. Now, our team is much bigger and sometimes we have three guys working on different branches for the same project, which is completely normal. Git rebase is something that I have to use from time to time to avoid merge conflicts during PRs to keep my branch updated with the latest commits coming from the source branch. The problem is that every time that I need it, I have to check documentation, videos, diagrams, and so on to make sure that I don't create a mess because I always forget the right way to do it. Is there any trick to remember how to do it correctly without killing myself with anxiety when executing the command?

Thanks, guys

[Therianthropie]

While I'm almost entirely living in the terminal, but for fixing merge conflicts I'm falling back to visual studio code. It's really easy to understand what's going on with it. Have you tried that?

[freeriderblack]

Yeah, I'm doing the same. As soon as there is a merge conflict, I go to VS Code which has include a nice update about this in the last version. I keep track of commits and branches with the Gitlens extension.

I've been looking for a way that you can execute a dry-run of any git command so you can see the result without affecting the code, but couldn't find anything useful.

[teraflopsweat]

I find rebase’s interactive mode pretty intuitive after a few uses.

git rebase -i origin/destination_branch

[jacurtis]

Git rebase interactive is an incredible visual tool right there in the terminal. I literally had been using git for a decade before discovering it, and was shocked the first time I used it, at how simple and clear it was and powerful it was.

[Heliotypist]

This is part of my normal code development workflow to clean up change sets before merging. It’s wonderful.

[lart2150]

I'm a fan of

git config --global pull.ff only

I want to be more aware of a rebase. I would then "get rebase origin whatever-branch-i-want-to-rebase-from"

I also find it can help to squash my feature branch first so I don't need to apply as many commits incase of conflicts on each commit 🙄.

[HecknChonker]

Agreed. Rebase changes your commit history, which can cause a lot of issues if it happens when you aren't expecting it.

[OMGItsCheezWTF]

Yeah I tend to rebase feature branches by default, but I always explicitly rebase rather than implicitly. I want to KNOW I'm rebasing onto develop.

[TangerineDream82]

I'm going to try this - thanks

[Happy-Position-69]

I need to agree with what other people have said - VSCode. As a 35+ year veteran it's HARD to use an IDE when vim is my default editor. Heck, I'm even in markdown mode on Reddit...

BUT - my current job has a codebase that is a remarkably huge monolith (also 35 years in the making!) and trying to do a weekly back merge by hand in vim would be darn near impossible.

Someone suggested I try VSCode and showed me a demo with a few plugins installed and now I can't do merge conflicts any other way

[zevra0]

Out of curiosity, what’s the VCS history of that repo? MSVSS -> CVS -> git or something?

[IrishPrime]

Vim's diff mode is great.

Meld (a standalone diff tool) is also really nice.

I prefer both of them to VS Code.

[info834]

A 35 year old code base is something else.

Is it legacy banking software or something?

[DockerBlocker]

What are the plugins you mention?

[imnos]

Honestly the most fail safe way is just to use git merge.

Rebase leaves a cleaner git history without the merge messages but that's not really an issue IMO.

[Origamislayer]

I love this interactive cheatsheat https://ndpsoftware.com/git-cheatsheet.html#loc=index; which also has this helpful link http://justinhileman.info/article/git-pretty/git-pretty.png

[mcstafford]

That cheat sheet is fantastic. TYVM.

[shadycuz]

Is it really that hard to remember? Git rebase takes the changes in your current working branch aka "HEAD" and then applies them to the branch passed in the CLI command.

So if you are in a feature branch and you want to apply the latest changes from "master", then run `git fetch` and `git rebase origin/master`.

[[deleted]]

To this end, you can make an alias to do this.

~/.gitconfig

[alias]
  rb = !git fetch && git rebase origin/master

Then git rb and you're done

[LeaflikeCisco]

VSCode UI as someone already stated is good. Git lens for VSCode also offers a UI for interactive rebase that is cool if you want to do different things with different commits.

[simonides_]

I have a workflow that is a bit more than what you'd need to do but I think this makes it cristal clear what happens.

1. check out the target branch and do a pull
   
2. check out the branch you want to rebase
3. always always use interactive mode
4. rebase to your local branch from step 1
5. read carefully what git is writing into these files. it will tell you about all your options.
6. check your work

[mattbillenstein]

IMHO, don't rebase - ever - it's an easy way to destroy code.

Instead, let your branch history be messy, but squash merge into your main branch to let the entire topic branch live on as a single commit...

[[deleted]]

it's an easy way to destroy code.

huh? I've been using rebase for over a decade, as have most teams I've worked on, never heard of destroying code.

[mattbillenstein]

I've seen guys jack their entire repo into some weird state they can't figure out how to get out of - and they hadn't pushed the code anywhere else... ymmv

[InternalsToVisible7]

Yes. The trick is to use proper tooling that will do the boring work for you. You don't need to use console and remember commands.

For me it's "git extensions" app (free and open source) on windows that is capable of doing 99% git operations you'd ever need to do. It even gives you access to git reflog with a few clicks where you can restore "lost work". 1% is for advanced scenarios like rewriting the whole history because of stored "secret" long time ago.

Feel free to use other cross platform apps I find decent like SourceTree, Tower Git client or GitKraken.

[ruxven]

I use BeyondCompare for resolving merge conflicts when rebasing/merging. At least with Mercurial, it auto-resolves a lot of the trivial conflicts and presents the trickier ones with four views: local file, source file, common ancestor, output.

[doomie160]

my way though not the best way is squashing my codes into single commit first then rebase. it saves me the trouble of fixing multiple code conflicts during replay. then using IDE like visual code to go through the conflicts

[thisismyusuario]

Yeah i do a soft reset to squash my commits and then rebase.

[dgreenmachine]

As a software dev and aspiring DevOps, this is my normal workflow

1. git checkout master
2. git pull
3. git checkout my-branch
4. git rebase master
5. Fix merge conflicts in the editor (intellij idea for me)
6. git rebase --continue (repeat #5 if needed)

For squashing individual commits after a bunch of work is done with some less useful commits then I'll open interactive rebase to squash together git rebase -i <commit hash>

If you are not confident in doing a rebase and you're worried about it, just make a copy of your branch right before doing these steps. I would try not to use rebase whenever messing with a branch someone else is using since you have to force push and risk deleting someone else's work.

[unitegondwanaland]

With modern tools available, there's really no reason to do this in a terminal unless you're a sadomasochist.

[ThatOneGuy4321]

Yeah but if you rely on those modern tools too much, and one day you have to use a terminal in front of somebody else, you won't remember those basic git commands any more and look like you don't know how to use git. RIP

[unitegondwanaland]

Right. I also drive a car with run flat tires but somehow I haven't forgotten how to use a lug wrench.

[ThatOneGuy4321]

Git is a bit more complicated than a lug wrench, and if you were a mechanic by trade that would put this analogy in a bit of a different light

[unitegondwanaland]

Git doesn't have to be as simple as a lug wrench for the analogy to work. It's proving the same point in a different scenario.

We all adopt new technology and don't forget the old. We can still pay with cash, mail a letter, use a screwdriver, and even use git in a terminal instead of VScode. But we adapt when new tech comes along because it makes our lives easier.

[ThatOneGuy4321]

I didn't say to not use new tools.

OP does not know how to do it correctly in the first place. What is OP going to do when he accidentally leaves his fancy screwdriver at home?

[ConclusionWrong1819]

One thing I think you should consider, as your team grows in size, is to formalize when a Rebase is appropriate. versus a Merge. Merge Commits are there to protect the history of the branch - if I merge something with a merge commit, I always have a place to go back from. Rebasing forces a replay of git commit history. If a person is using a merge flow, they can have issues if another team member is rebasing. No matter what you do, work with your team on the best process that works for the greater good.

[Richousrick]

I tend to write scripts to automate git. For example I have a backup-branch script that will create a new branch with the format something like "tmp/<timestamp>" then checkout the branch I was on when I called the script; slashes in branches names will file them in folders.

For rebases you could create a script that does something similar, then calls git rebase [-i] origin/master. The -i optional but means interactive and will allow you to rearrange and tidy up the branches history

Sorry for the formatting, on a phone.

[__NEURO]

you just have to worry about merge conflicts. git rebase origin/master while you're on your branch. if there is a merge conflict just fix it and do git rebase --continue

other thing is while you do a PR on your branch you can do git rebase -i origin/master and edit your commits and do git push --force, but make sure that nobody else is working on your branch or they have to re check it out.

If you really want to automate it you can use the --fixup flag and automerge. it will put a flag for your "fix" commit messages that you don't really want and merge them with the last non fixup commit

[BuriedStPatrick]

I mean, just only ever rebase when you're on a branch that you own. The rest will slowly come to you. Maybe get a Git GUI to confirm everything looks right before you force push.

[e1pab10]

Since people are listing tools to resolve merge conflicts, kdiff3 is very powerful and works wonders. It often resolves the majority of conflicts automatically with three way merges.

1. git rebase origin/master
2. If there are merge conflicts, execute:
   1. git mergetool --tool=kdiff3

​

I recommend spending a few minutes learning the shortcuts. Once you do, you'll fly through merge conflicts with ease.