git-rebase

问题 I started a git rebase in my repository a day ago and never finished it. I forgot about and did a lot of modifications while I was still in the rebase. Today I accidentally did a git rebase --abort without putting those modifications in a commit. Now it looks like all my modifications are gone. Is there any way to recover them? My git reflog looks like this: 57d731c HEAD@{0}: rebase: aborting d2d3738 HEAD@{1}: rebase -i (start): checkout david 57d731c HEAD@{2}: commit: My commit message 回答1:

问题 by now, I know that there is a nice way how to combine commits and change the commit message by using 'git rebase --interactive' Having the following situation: $ git rebase --interactive HEAD^^^^ pick 5b7c140 commitA pick 40ffd7c commitB pick 5e7647d commitC pick 78bea2d commitD Rebase [...] Is there also a possibility to handle the following requirements: Combining commitA and commitC and commitB and commitD to new commits cAC and cBD? 回答1: It is possible - you can also rearrange the order

问题 I have a Git repository with a branch that hardly ever changes (nobody else is contributing to it). It is basically the master branch with some code and files stripped out. Having this branch around makes it easy for me to package up a leaner version of my project without having to strip out the code and files manually every time. I have been using git rebase to keep this branch up to date with the master but I always get this warning when I try to push the branch after rebasing: To prevent

问题 A bunch of questions ask how to rewrite ( rebase ) some commits so that they appear on a branch, but these all seem to assume that rebase is actually necessary, i.e. that the commits wanted for the branch are interspersed with commits wanted on master (whether made by “you” or others). This question is simpler: I have a clone of a repository on the master branch, and I made a bunch of commits intending to create a GitHub pull request. Normally I would have run git checkout -b new-feature

问题 I am working on a branch, foo . I have no unstaged changes, no working changes, perfectly clean state, where HEAD == foo == origin/foo according to my box. $ git status # On branch foo # Untracked files: # (use "git add <file>..." to include in what will be committed) # # some_irrelevant_file_here $ git log --pretty=... * 456520c 2015-02-13 (HEAD, origin/foo, foo) Commit A * 23bfcd1 2015-02-11 Commit B * b0bdd18 2015-02-12 Commit C I am then asked to look at some changes that a colleague

问题 Suppose I've got the following history, where the top line is the master branch, the lower one is a feature branch that's merged with master at one point, and D just reverts C (which means that the working directory is the same in B and D ). A---B---C---D master \ \ E---F---G feature I want to add C and its reversion D to the history before the merge in F , like this: A---B---C---D master \ \ E-----------F'--G' feature I don't want to change E (which is actually a long series of commits). git

问题 Say I have local branch A off of origin/master. I am continuously making changes to branch A, fetching the remote master, and rebasing. Then I have local branch B off of A. I am continuously making changes to branch B and rebasing. I am the only one working on branches A and B. Is this a bad setup since A's commit IDs (hashes) may be changing frequently? Does that destabilize branch B in any way or make conflicts more likely? In fact, how does Git even implement this setup? What is B's HEAD

问题 I have a repo in which I have two branches, master and master-old , which was created as an orphan branch. Now I want to rebase the entirety of master onto master-old , but the tree of each commit should stay unchanged, i.e. the working copies of each commit on master and master-old should look exactly the same way before and after the rebase. Current state ------------- A - B - C - D <--- master E - F - G - H <--- master-old Desired state ------------- E'- F'- G'- H'- A'- B'- C'- D' <---

问题 I think I understand git pull and this is how I explain it in, what I call, "simple terms": Generally speaking, git pull is about merging a "remote" branch into a "local" branch. In more detail, git uses the content of the "remote" branch to "update" / "modify" content of the "local" branch. In even more detail, if a file has been modified in the "local" branch but not in the "remote" branch, then after the merge, the content of the file will be the same as the content in the "local" branch.

问题 When it happens that a useful commit is accidentally skipped during a rebase operation, is there any hope that Git keeps a reference of it that could be reapplied? It was a non-interactive rebase with lots of binary files where I went too long into a happy-trigger mood using git rebase --skip , so there were no error messages at all, just a lousy attitude. This seems a hard-disk crashing recovery scenario, but instead of chasing phantom inodes, there should be a way to filter lost tree