You may not want to change every unpushed commit, but you can change some and leave the rest as-is. You don't want to rewrite what's already been pushed. If you think about it, the commits you haven't pushed yet are usually exactly the ones you want. It changes interactive rebase from something you spend maybe 30 seconds on to something you spend maybe 5 seconds on. But what makes this command so handy is how you don't have to dig through your git log and figure out which commit to rebase from. If you're an experienced Git user, you have probably used interactive rebase before. The list opens in my editor as a Git "interactive rebase", which means I can easily modify the list to rephrase commits, reorder them, and squash multiple commits into one. # If you remove a line here THAT COMMIT WILL BE LOST. ![]() # These lines can be re-ordered they are executed from top to bottom. # x, exec = run command (the rest of the line) using shell # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message # Rebase 39faea5.d37dda8 onto 39faea5 (3 command(s)) pick 3b052b2 New blog post: Interactive rebase against the remote master What does it do? It lists all the commits I made locally but didn't push to the remote master branch yet. In fact, I use it often enough that I made a shell alias: alias grb = 'git rebase -i origin/master' If you fast-forward-merge your local branch-label development to match origin/development, it's even simpler to draw (drop the kink down from B to E and put both development and origin/development to the right of the arrow pointing to G).Here's a Git command I've started to use a lot: git rebase -i origin/master If you run a plain git fetch at this point, or if you have the newer-enough git so that origin/development has moved and if we drop the "abandoned" parts and simplify the drawing, it becomes: A - B <- development We'll call the rebased ones C' and D': C - D Now the rebase will copy your FeatureA commits in the usual method for a rebase, and make FeatureA point to the copies, abandoning the original commits. ![]() It won't really matter for the rebase, it will just change how you'll see the results in a git log -graph view or a graphical commit-tree viewer.) If not, your local copy of their development, stored in your origin/development, lags behind. (If your git is new enough, 1.8.4 or later, origin/development will also be updated at this time, to point at node G. The fetch-from-origin step will pick it up and make FETCH_HEAD point to that, so let's draw it in as node G: C - D <- FeatureA So let's say the commit graph in your local tree looks like this (we'll assume you ran a git fetch at some point that updated origin/development with their commits E and F): C - D <- FeatureAĪnd, let's further assume that on origin, there's one more commit now on their branch named development. then, instead of git merge, use git rebase with that ID.fetch only the development branch and put that in FETCH_HEAD.well, in this case, git rebase rather than git merge. If not, it still works as well as it should, it just might be a bit confusing in a graphical viewer.Īs always, git pull is basically git fetch followed by. ![]() Short version: if the rebase goes well, it works fine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |