Git rebase remote11/1/2023 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' The rebase will then replay 'their' commits on the new 'our' topic branch: c-c.x.x.Here's a Git command I've started to use a lot: git rebase -i origin/master \-y-y-y(*) <- set HEAD to this commit, to replay x's on it c-c-x-x-x <- former "current" branch, new "theirs" We don't change the current branch topic, so what we have is still what we were working on (and we merge from another branch) c-c-x-x-x-o(*) MERGE, still on branch topicīut on a rebase we switch sides because the first thing a rebase does is to checkout the upstream branch to replay the current commits on top of it! c-c-x-x-x(*) <- current branch topic ('*'=HEAD)Ī git rebase upstream will first set HEAD to the upstream branch, hence the switch of 'ours' and 'theirs' compared to the previous "current" working branch. Inversion illustrated On a merge: c-c-x-x-x(*) <- current branch topic ('*'=HEAD) That means a merge/diff tool will present the upstream branch as local ( master: the branch on top of which you are rebasing), and the working branch as remote ( topic: the branch being rebased) +-+ With respect to terminologies used by merge tools (not to be confused with local ref or remote ref) => local is master ("ours"), The first thing a rebase does is resetting the HEAD to master before cherry-picking commits from the old branch topic to a new one (every commit in the former topic branch will be rewritten and will be identified by a different hash). Git rebase master # rebase topic branch on top of master branch Tidying up your local and remote repositoryĪ rebase switches the meaning of "ours" and "theirs": git checkout topic.Reflog - Restoring commits not shown in git log. ![]() Setup git-pull for automatically perform a rebase instead of a merge.Rebase: ours and theirs, local and remote.Display commit history graphically with Gitk. ![]() mailmap file: Associating contributor and email aliases
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |