diff options
Diffstat (limited to 'git_rebase_illustrated_with_time_travel.html')
| -rw-r--r-- | git_rebase_illustrated_with_time_travel.html | 56 |
1 files changed, 56 insertions, 0 deletions
diff --git a/git_rebase_illustrated_with_time_travel.html b/git_rebase_illustrated_with_time_travel.html new file mode 100644 index 0000000..ebfc19f --- /dev/null +++ b/git_rebase_illustrated_with_time_travel.html @@ -0,0 +1,56 @@ +<!doctype html> +<html lang="en"> +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<meta name="author" content="aki"> +<meta name="tags" content="git, rebase, branching, guide, time travel"> +<link rel="icon" type="image/png" href="cylo.png"> +<link rel="stylesheet" href="style.css"> + +<title>Git Rebase Illustrated With Time Travel</title> + +<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav> + +<article> +<h1>Git Rebase Illustrated With Time Travel</h1> +<p class="subtitle">Published on 2022-01-28 16:43:00+01:00 +<p>Back in the office days, colleagues and I would have weekly discussions about git which usually ended with comparing +merge to rebase or with me preaching about the dangers of rewriting the history. Let's go back to these times but with +a slight twist. There's already plenty of other in-depth git tutorials and <b>git-rebase</b>(1) is great and you should +read it. There is no point in creating yet another resource, so instead let's make it a fun and chill weekend read. +<p>Let's say two different people are working on two completely disconnected task in parallel in a known period. These +tasks can be divided into a sequence of sub-tasks, where each sub-tasks enables next sub-task to be performed and there +is no room for parallelization (for now). This situation can be illustrated like this:</p> +<img src="git_rebase_illustrated_with_time_travel-1.png" alt="original timeline"> +<p>In the graph <strong>A</strong> and <strong>B</strong> lanes represent the progress of a task with significant points +in sub-tasks. All sub-tasks can be projected into the time line and their order remains the same. +<p>Let's expand the example by adding two common spots in time for both tasks: first being someone ordering to perform +both tasks, and second being the merge of both lanes into one.</p> +<img src="git_rebase_illustrated_with_time_travel-2.png" alt="timeline with common tasks"> +<p>This should look somehow similar to you, because (if not for the missing middle part) this graph represents a regular +workflow that uses <b>git-merge</b>(1). <strong>C</strong> is a common origin and goal for both task lanes and serves +the same purpose as <code>master</code> branch. +<p>In order to reduce the number of lanes we can let one of the tasks claim the main lane for their own. This happens +when you branch off an active branch that gets some additional work done before you merge back into it:</p> +<img src="git_rebase_illustrated_with_time_travel-3.png" alt="branch off and back"> +<p>This image was probably recognized by you right away. +<p>Now, it just happened, but turns out that by the end of the <strong>A</strong> task the person responsible for it +built a time machine and proposed to the project management to use it in order to perform both tasks sequentially but in +parallel time. They were as confused as you are but gave green light just to see what happens. +<p>Developer took the results of <strong>B</strong> with them and went back in time to the spot where <strong>A</strong> +and <strong>B</strong> diverged. They started to work on <strong>A</strong> using the souvenir from the future as the +<em>base</em>. People that were working on task <strong>B</strong> in the meantime were confused. +<p>When the moment for merge came, the traveller from future just presented their work and said that it's already +merged, so there's no need to do anything. And they spoke truthfully, because in linear time the work looked like this: +</p> +<img src="git_rebase_illustrated_with_time_travel-4.png" alt="rebase in linear timeline"> +<p>But from the perspective of the traveller the whole timeline got distorted and didn't look linear at all:</p> +<img src="git_rebase_illustrated_with_time_travel-5.png" alt="rebase in non-linear timeline"> +<p>From this point of view the sequence is one-lane and completely undisturbed. On the other time the timeline gets +shifted and some parts of it fade away as they never were or are no longer observed by the time traveller. +<p>All of this happens every time you rebase your branches. +<p>I hope you had fun and if you actually had some problems imagining what rebase does, I hope this post at least +pointed you in the right direction. +<p>Who knows maybe next time I'll write about more history rewriting shenanigans. +</article> +<script src="https://stats.ignore.pl/track.js"></script> |