Rebasing selective commits interactively
by Jakub Narębski, Rasmus Voss, Aske Olsson, Ferdinando Santacroce
Git: Mastering Version Control
- Git: Mastering Version Control
- Table of Contents
- Git: Mastering Version Control
- Git: Mastering Version Control
- Credits
- Preface
- I. Module 1
- 1. Getting Started with Git
- 2. Git Fundamentals – Working Locally
- 3. Git Fundamentals – Working Remotely
- 4. Git Fundamentals – Niche Concepts, Configurations, and Commands
- Dissecting the Git configuration
- Configuration architecture
- Configuration levels
- Listing configurations
- Editing configuration files manually
- Setting up other environment configurations
- Basic configurations
- 5. Obtaining the Most – Good Commits and Workflows
- The art of committing
- Adopting a workflow – a wise act
- Summary
- 6. Migrating to Git
- 7. Git Resources
- II. Module 2
- 1. Navigating Git
- 2. Configuration
- 3. Branching, Merging, and Options
- 4. Rebase Regularly and Interactively, and Other Use Cases
- 5. Storing Additional Information in Your Repository
- 6. Extracting Data from the Repository
- 7. Enhancing Your Daily Work with Git Hooks, Aliases, and Scripts
- Introduction
- Using a branch description in the commit message
- Creating a dynamic commit message template
- Using external information in the commit message
- Preventing the push of specific commits
- Configuring and using Git aliases
- Configuring and using Git scripts
- Setting up and using a commit template
- 8. Recovering from Mistakes
- Introduction
- Undo – remove a commit completely
- Undo – remove a commit and retain the changes to files
- Undo – remove a commit and retain the changes in the staging area
- Undo – working with a dirty area
- Redo – recreate the latest commit with new changes
- Revert – undo the changes introduced by a commit
- Reverting a merge
- Viewing past Git actions with git reflog
- Finding lost changes with git fsck
- 9. Repository Maintenance
- Introduction
- Pruning remote branches
- Running garbage collection manually
- Turning off automatic garbage collection
- Splitting a repository
- Rewriting history – changing a single file
- Back up your repositories as mirror repositories
- A quick submodule how-to
- Subtree merging
- Submodule versus subtree merging
- 10. Patching and Offline Sharing
- 11. Git Plumbing and Attributes
- Introduction
- Displaying the repository information
- Displaying the tree information
- Displaying the file information
- Writing a blob object to the database
- Writing a tree object to the database
- Writing a commit object to the database
- Keyword expansion with attribute filters
- Metadata diff of binary files
- Storing binaries elsewhere
- Checking the attributes of a file
- Attributes to export an archive
- 12. Tips and Tricks
- III. Module 3
- 1. Git Basics in Practice
- An introduction to version control and Git
- Git by example
- Repository setup
- Creating a Git repository
- Cloning the repository and creating the first commit
- Publishing changes
- Examining history and viewing changes
- Renaming and moving files
- Updating your repository (with merge)
- Creating a tag
- Resolving a merge conflict
- Adding files in bulk and removing files
- Undoing changes to a file
- Creating a new branch
- Merging a branch (no conflicts)
- Undoing an unpublished merge
- Summary
- 2. Exploring Project History
- 3. Developing with Git
- 4. Managing Your Worktree
- Ignoring files
- File attributes
- Fixing mistakes with the reset command
- Stashing away your changes
- Managing worktrees and the staging area
- Multiple working directories
- Summary
- 5. Collaborative Development with Git
- 6. Advanced Branching Techniques
- Types and purposes of branches
- Branching workflows and release engineering
- Interacting with branches in remote repositories
- Summary
- 7. Merging Changes Together
- 8. Keeping History Clean
- An introduction to Git internals
- Rewriting history
- Amending history without rewriting
- Summary
- 9. Managing Subprojects – Building a Living Framework
- Managing library and framework dependencies
- Managing large Git repositories
- Summary
- 10. Customizing and Extending Git
- 11. Git Administration
- 12. Git Best Practices
- 1. Git Basics in Practice
- A. Bibliography
- Index
- Configuration architecture
- Dissecting the Git configuration
When you are working on a new feature and have branched from an old release into a feature branch, you might want to rebase this branch onto the latest release. When looking into the list of commits on the feature branch, you realize that some of the commits are not suitable for the new release. So, when you want to rebase the branch onto a new release, you will need to remove some commits. This can be achieved with interactive rebasing, where Git gives you the option to pick the commits you wish to rebase.
To get started with this example, you need to check the previously created branch, rebaseExample; if you don't have this branch, follow the steps from the Rebasing a few commits section and use the following command:
$ git checkout rebaseExample Switched to branch 'rebaseExample' Your branch is ahead of 'origin/stable-3.1' by 109 commits. (use "git push" to publish your local commits)
Notice that because we are tracking origin/stable-3.1, the Git checkout will tell us how far ahead we are in comparison with that branch.
We will try to rebase our current branch, rebaseExample, on top of the origin/stable-3.1 branch by performing the following steps. Remember that Git will apply the commits that are not available on the branch we are rebasing to; so, in this case, there will be a lot of commits:
- Rebase the branch onto
origin/stable-3.1by using the following command:$ git rebase --interactive origin/stable-3.1 - What you will see now is a list of all the commits you will be rebasing onto the
origin/stable-3.1branch. These commits are all the commits between theorigin/stable-3.1andrebaseExamplebranches. The commits will be applied from top to bottom, so the commits will be listed in reverse order, at least compared to what you would normally see in Git. This actually makes good sense. The commits have the keywordpickto the left and then the abbreviated commit hash, and finally the title of the commit subject.If you scroll down to the bottom, you will see a list like the following one:
pick 43405e6 My brand new fishtank pick 08d0906 Feed the fish # Rebase da6e87b..08d0906 onto da6e87b # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
So, if we only want our fishtank commits to be based on top of the
origin/stable-3.1branch, we should remove all the commits except for our two commits. - Remove all the lines except for the two commits at the bottom; for now, leave
pickas the keyword. Save the file and close the editor, and you will get the following message from Git:Successfully rebased and updated refs/heads/rebaseExample. - Now, with
gitk, try to check whether we accomplished what we predicted. The next screenshot shows our two fishtank commits on top of theorigin/stable-3.1branch. The following screenshot is what we expected:
The same thing could actually be achieved with a single small Git command. We have been rebasing commits from the origin/stable-3.2 branch to the rebaseExample branch onto the origin/stable-3.2 branch. This can also be achieved in the following manner:
$ git rebase --onto origin/stable-3.1 origin/stable-3.2 rebaseExample First, rewinding head to replay your work on top of it... Applying: My brand new fishtank Applying: Feed the fish
The --onto origin/stable-3.2 flag tells Git to rebase onto origin/stable-3.2, and it has to be from origin/stable-3.1 to the rebaseExample branch. So, we end up having rebaseExample branch to the branch of the origin/stable-3.1 and the like. The next diagram shows before the rebase example where we have our two commits on top of origin/stable-3.2, then after the rebase where our commits are on top of origin/stable-3.1 as we wanted:
-
No Comment