Similar to yesterday’s tip, but today, you’ll see how to resolve a conflict when rebasing within Visual Studio.
Suppose you have the same line in the same file modified in different branches. Just something simple to trigger a merge conflict. Or more likely, you’ve added one file in master and you’ve added another file in an experiment branch. Then you get a conflict when rebasing because your project file needs help merging the two newly added files.
First, you’ll get the message that there are conflicts.
Click on the Conflicts: 1 link.
Clicking on the Merge button will bring up the built-in merge tool.
Make whatever selections you want, and then hit Accept Merge.
Now View Changes, as you’ve resolved the conflicts, but still need to finish the rebase.
And finally finish the rebase! (For some reason, I can’t stop hearing the Mortal Kombat game in my head.)
And now you’ll see that the experiment branch has been merged onto master.
Suppose you’ve added a new file to your solution in a branch called `experiment` for experimental purposes. You are happy with this new file and want to merge this back into master. Well, let’s say you (or someone like you*) made a change in master.
Since this is on your local machine, you can decide “do I want to have the history of the experiment branch or do I want a clean, linear timeline?” Guess which adventure you’re going to choose today 🙂
Here’s the visual setup.
Notice how the tip of experiment has a commit that’s not in Master, and vice versa, the tip of master has a commit that’s not in experiment.
First, we’ll use Team Explorer to rebase experiment unto master. BTW I love how Team Explorer uses full sentences to confirm your intent.
Now after the rebase, you’ll see two things:
- The commit from master is now shown in the experiment branch (recall the visualization from previous posts – the master pointer is now behind experimental pointer)
- The commit ID for “added experimental code” has changed (You can compare to the first image in this blog post to verify)
And lastly, let’s get master caught up to experiment by doing a merge. Yay for full sentences in the below image!
And now when you refresh Master history, you’ll see the changes.
*I couldn’t resist. I listened to way too much Matchbox 20 in my youth, “I wish the real world would just stop hassling me .”
This might be a bug with the Git Visualization tool. Via the command line, if your branch can already perform a fast-forward merge, Git won’t let you do a rebase. However, the visualization tool allows for it.
Suppose you create a new branch `experiment` and add 1 commit. Then you try to do a rebase on master. You’ll get the following error.
My guess why this makes sense is because Git is protecting you (or others from you) from rewriting history. In other words, there’s nothing to rewind, so no rebase.
However, the visualization tool allows for it, but I think this is a bug. Hence why always important to experiment IRL!
In yesterday’s tip, you saw how to visualize a rebase. Today’s tip allows you to practice performing a rebase via the command line.
First, we’ll have master contain one extra commit that isn’t included in your `experiment` branch. For example, you were working on `experiment` and a new commit was added to master (either by you, e.g. bug fix, or from a remote).
Next, you’ll have a commit on `experiment` that isn’t on master.
Since you are on your local machine, you can rewrite history because you haven’t shared or pushed these changes.
From the `experiment` branch, you’ll run
$ git rebase master
and then checkout master and merge in experiment to do the fast-forward merge.
One thing the visualization is able to emphasize is how the commit IDs are different for the “added fileExperiment”.
The commit ID `f041b71` is no longer `1601e09` (as shown in the 2nd image for added fileExperiment).