Rebase Onto – When Dropping Commits Makes Sense: Git In Practice – Part 3

In the previous articles of this series, I showed you some of the capabilities of interactive rebase. I mentioned that you can also drop commits when rebasing. In this article, I would like to demonstrate scenarios in which that makes sense and a short-cut to achieve what we want.

In diesem Artikel:

YB_300x300
Yannick Baron ist Architekturberater bei Thinktecture mit einem Fokus auf Angular und RxJS.

Article series:

  1. Part 1: Demystifying git Rebase 
  2. Part 2: Interactive Rebase
  3. Part 3: Rebase Onto – When Dropping Commits Makes Sense

Associated Screencast: Rebase Onto: Git in Practice

Automatically Dropped Commits

Imagine the following graph:

				
					```
      A---B---C (feature)
     /
D---E---A---G (main)
```
				
			

As you can see, we have made change A on feature. Let’s say we added a line to a configuration file. We can also see main has moved further and also introduced the same change A.

If we now rebase feature onto main, commit A of feature would be empty and therefore will automatically be skipped for you, resulting in a graph as such:

				
					```
              B'--C' (feature)
             /
D---E---A---G (main)
```
				
			

When rebasing, changes that are already in the base might result in empty commits, which git skips.

Branching off a Feature

Sometimes, when developing a feature, you are reliant on a recently developed addition to your codebase. Assume that the changes you need are in a feature branch that has not been integrated into main yet.

What you can do in this case is to base your branch off of the feature branch you are waiting on:

				
					```
                        X---Y---Z (feature)
                       /
              A---B---C (feature-base)
             /
D---E---F---G---H---I (main)
```
				
			

But what do we see here? main has moved ahead of feature-base. It is not unusual for the person in charge of feature-base to now rebase onto main, to integrate the changes, and ready the feature for a merge:

				
					```
                A---B---C---X---Y---Z (feature)
               /
              /       A'--B'--C' (feature-base)
             /       /
D---E---F---G---H---I (main)
```
				
			

feature-base is now based on main, and commits A through C have been re-applied.

If the rebase of feature-based went smoothly without any conflicts, and we rebase feature onto it, we will not run into problems, and git skips the empty commits as explained above.

That is not always the case. Also, imagine feature-base also moved a little further and was integrated into main already. Either way, our goal would be to only take the commits of our feature branch, in this case, X, Y, and Z, to a new base.

When using interactive rebase, to rebase feature onto feature-base, we see something like this:

				
					pick 9a56133 A
pick bf1de76 B
pick 5bc89ff C
pick bebdada X
pick 4ab9db0 Y
pick 47ff725 Z
				
			

We now have the option to drop commits A, B, and C, by either removing the lines in the editor or changing the command to drop, resulting in applying commits X through Z to where we need them to be.

				
					```
                                X'--Y'--Z' (feature)
                               /
                      A'--B'--C' (feature-base)
                     /
D---E---F---G---H---I (main)
```
				
			

Using an interactive rebase, dropping some commits is quite simple, even when they are in the middle of a series. If we want to omit some commits at the beginning only, there is a shorter form built into the rebase command.

Rebase --onto

Let’s assume to be in the same situation as before:

				
					```
                        X---Y---Z (feature)
                       /
              A---B---C (feature-base)
             /
D---E---F---G---H---I (main)
```
				
			

Imagine that this time, we simply want to transplant X, Y, and Z, onto main. Using the rebase command, we can achieve this by doing the following:

				
					$ git rebase --onto <base> <upstream> [<branch>]

$ git rebase --onto main feature-base feature
				
			

Executing the command will get us this graph:

				
					```
                A---B---C (feature-base)
               /
              /       X'--Y'--Z' (feature)
             /       /
D---E---F---G---H---I (main)
```
				
			

As you can see in the onto-form of the rebase command, we need to provide the upstream from which we want to pluck the commits.

In the above example, we still have a reference to that in the form of the feature-base branch. Let’s look back at the situation we encountered before:

				
					```
                A---B---C---X---Y---Z (feature)
               /
              /       A'--B'--C' (feature-base)
             /       /
D---E---F---G---H---I (main)
```
				
			

Here, we do not have that reference.

But fear not! Instead of the upstream reference, we can just use the SHA hash of commit C. Assuming that feature is the current branch, the shortest form would be:

				
					$ git rebase --onto feature-base 5bc89ff
				
			

Now we replicated our interactive rebase from before, resulting in:

				
					```
                                X'--Y'--Z' (feature)
                               /
                      A'--B'--C' (feature-base)
                     /
D---E---F---G---H---I (main)
```
				
			

Conclusion

In this article, we looked at dropping commits when rebasing and introduced the --onto flag, the rebase command provides. I am using this way of rebasing frequently, so I wanted to demonstrate it here and hope that you can benefit from it as much as I do.

Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren
.NET
pg

Pattern Matching with Discriminated Unions in .NET

Traditional C# pattern matching with switch statements and if/else chains is error-prone and doesn't guarantee exhaustive handling of all cases. When you add new types or states, it's easy to miss updating conditional logic, leading to runtime bugs. The library Thinktecture.Runtime.Extensions solves this with built-in Switch and Map methods for discriminated unions that enforce compile-time exhaustiveness checking.
26.08.2025
.NET
pg

Smart Enums: Adding Domain Logic to Enumerations in .NET

This article builds upon the introduction of Smart Enums by exploring their powerful capability to encapsulate behavior, a significant limitation of traditional C# enums. We delve into how Thinktecture.Runtime.Extensions enables embedding domain-specific logic directly within Smart Enum definitions. This co-location of data and behavior promotes more cohesive, object-oriented, and maintainable code, moving beyond scattered switch statements and extension methods. Discover techniques to make your enumerations truly "smart" by integrating behavior directly where it belongs.
29.07.2025
.NET
pg

Discriminated Unions: Representation of Alternative Types in .NET

Representing values that may take on multiple distinct types or states is a common challenge in C#. Traditional approaches—like tuples, generics, or exceptions—often lead to clumsy and error-prone code. Discriminated unions address these issues by enabling clear, type-safe modeling of “one-of” alternatives. This article examines pitfalls of conventional patterns and introduces discriminated unions with the Thinktecture.Runtime.Extensions library, demonstrating how they enhance code safety, prevent invalid states, and improve maintainability—unlocking powerful domain modeling in .NET with minimal boilerplate.
15.07.2025
.NET
pg

Handling Complexity: Introducing Complex Value Objects in .NET

While simple value objects wrap single primitives, many domain concepts involve multiple related properties (e.g., a date range's start and end). This article introduces Complex Value Objects in .NET, which group these properties into a cohesive unit. This ensures internal consistency, centralizes validation, and encapsulates behavior. Discover how to implement these for clearer, safer code using the library Thinktecture.Runtime.Extensions, which minimizes boilerplate when handling such related data.
01.07.2025
.NET
pg

Smart Enums: Beyond Traditional Enumerations in .NET

Traditional C# enums often fall short when needing to associate data or behavior with constants, or ensure strong type safety. This article explores the "Smart Enum" pattern as a superior alternative. Leveraging the library Thinktecture.Runtime.Extensions and Roslyn Source Generators, developers can easily implement Smart Enums. These provide a robust, flexible, and type-safe way to represent fixed sets of related options, encapsulating both data and behavior directly within the Smart Enum. This results in more maintainable, expressive, and resilient C# code, overcoming the limitations of basic enums.
17.06.2025
.NET
pg

Value Objects: Solving Primitive Obsession in .NET

Overusing primitive types like string or int for domain concepts ("primitive obsession") causes bugs from missed validation, like invalid emails or negative monetary values. This article explores Value Objects as a .NET solution. Learn how these self-validating, immutable types prevent entire classes of errors, make code more expressive, and reduce developer overhead. We'll demonstrate creating robust domain models with minimal boilerplate, improving code quality without necessarily adopting full Domain-Driven Design, and see how Roslyn Source Generators make this practical.
03.06.2025