Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
by
Lessons:2Length:4 minutes
  • Overview
  • Transcript

1.2 Git Rebase Mixtape

In this lesson, I'll share some advanced uses of Git rebase. I'll show you the ins and outs of rebasing to clean up your version history, to cleanly merge changes from a remote, or to pick only some useful commits from a branch. I'll also show you scenarios to watch out for—when a rebase could cause problems for your teammates.

1.2 Git Rebase Mixtape

My last video Merge versus Rebates gave you a solid basis to integrate changes from one brand into another. But unsurprisingly, it is a deep tool and there's more to learn about rebates. We need to cover a bit more ground to get you ready for the real action in the big leagues. I thought I'd make you a quick mix tape with a few highlights. Understanding indirective rebasing, cherry picking, and doing a git pull rebase, rounds off what you should understand to step up your game. But let's start with the dangers of re-base first, and save our appetite for some cherry picking at the end. If you're not careful with rebasing you can quickly enter a world of pain. If you rebase commits that have been outside your own repository you have a high likelihood of making people hate you or wanting to put funny stuff in your coffee. Let's say you have a local branch that has already pushed to remote that other team members had access to. This branch is off-hands for any rebase action. If you then rewrite history, you will potentially mess with the history of other people's forks if they already have built on top of your work. Never, ever, ever do that. You might enter a world of pain. You and potentially everybody else on the team. If you need to get, push, force something with a rebase, it should be a warning sign that you need to stop and make sure you know what you're doing. Just remember to rebase only local changes and you and everybody else on the team will be safe. Say you work in fork for an open source project and you can't merge a fork because the remote branch of the original repo has moved forward. In that case, you'll often be asked to do a rebase. What you need to do is fetch in these changes and rebase your work on top of the newest changes that come from the upstream branch of the open source repo. Your branch moves forward as a whole. As if it was spit off from at layers commit on master. After that, you force push it to your remote, from which you start or continue your pull request. A normal git pull consists of two operations, git fetch, which is automatically followed by a git merge. There is another option, though. Some say, a more elegant way, since it does not create along the way. What we can do instead is a git pull --rebase. This also fetches the newest changes and rebases the current branch on top of the upstream branch. Git pull --rebase rewinds your latest commits, fetches down the newest changes and replays your commits on top of the newest work from the remote. The end result looks like your newest work happened after the work you pulled in. In reality, your work could be much older. This will result in a cleaner timeline of commits and avoids the creation of merge bubbles. Your local branch and the remote version of it are actually two different branches. When you do a classic git pull you merge the commits from the remote branch into your local one. With git pull rebase we can pretend they are one in the same branch. We have another, more fine-grained way to rewrite history with interactive rebasing. The -i flag initiates what we call an interactive rebasing session. The underlying logic of a rebase stays the same with an interactive one. We just have more options to fine-tune the process. The commits will pop up in your editor of choice and are ready to be changed, Git lists the oldest commit at the top, why? Because this one will be replayed first by default. We can change multiple commit messages at once. Can reorder commits, easily delete them, and we can squash multiple commits together. When is squashing a good idea? If you have a messy that you want to clean up for example. Squashing that's unnecessary insignificant committee disappear. It gives you an opportunity to polish your work before you hand it in. We save the cherry for last. Cherry pickings is a form of rebase that let's you fine tune individual commits you need. Say you have a branch that only has only one or a couple of useful commits before you discard the rest of the branch. An ideal scenario for cherry picking. You can target a single commit by its hash number, or define a range of commits that you want to pick. Each picked commit gets recreated for the rebase. We can observe that when git is changing their hash number. As you can see, cherry picking is easy as pie.

Back to the top