If we check out feature-1 and run git rebase master, git will find feature-1's base-which is b-and change it to be the commit at master- which is f: git-rebase works on the current HEAD (which is almost always the currently checked out branch), so this form takes the current branch and changes its base to be the commit at. The simplest way to do this (and the form everyone knows) is git rebase. In other words, we move it to somewhere else in the history. To rebase, then, is to take a commit (or series of commits) and change its base. A commit's base is its previous (or parent) commit. The important thing here is the word base. If we check the docs for git-rebase, we get the following definition: Reapply commits on top of another base tip The first thing we need to understand is what a rebase even is. Take my hand and let's go on a trip through git rebase and unearth the secrets. How can we get there? Usually, I solve this in a couple of workable but tedious and annoying ways. What we ultimately want to end up with is this: We can't fix it by rebasing feature-2 off feature-1.
We can see j, k, l, and m like we expect, but we still have g, h, and i in there. It has its commits, plus the feature-1 commits that were just rebased. Now, I check my git tree and uh-oh! feature-2 is all busted. When feature-1 is approved, I rebase it off master to prepare for merging. While I'm waiting for approval, I want to start working on a new feature, so I create a new feature branch off of feature-1-let's call that one feature-2. I have a feature branch in code review-let's call it feature-1. Let me tell you about a problem I sometimes have.
0 kommentar(er)
