git-rebase

问题 I'm working with a repository that in theory should be following the Gitflow Workflow (see A successful git branching model by Vincent Driessen). However, the initial commit on the repository was made on the develop branch and there is no master branch to be seen. It's nearing release time and I need to create a master branch that reflects the production-ready state of the project which should've been there from the start. Keep in mind that the develop branch has multiple feature branches

问题 I want to combine my last two commits. Here is the result of git log : Now I want to merge those last two commits (which are into read box) into one commit. How can I do that? 回答1: There are many ways to do it (using rebase or reset ). The approach using git reset: No matter the approach, before anything else make sure the working copy is clean. Use git status to find out. If there are uncommitted changes either save them in a stash (git stash or commit them on a temporary branch. Run git

问题 I have a git project that has run for a while and now I want to throw away the old history, say from start to two years back from now. With throw away I mean replace the many commits within this time with one single commit doing the same. I checked git rebase -i but this does not remove the other (full) history containing all commits from git. Here a graphical representation (d being the changesets): (base) -> d1 -> d2 -> d3 -> (HEAD) What I want is: (base) -> d1,d2 -> d3 -> (HEAD) How could

问题 I have a bit of a messy branch with 20 or so commits, and I'm preparing for a merge back to master. I've rebased it off master, and looking closer, I realise that there are files being modified in ways that are totally irrelevant to this branch, and not ready to be committed. The changes to those files aren't confined to specific commits. So basically, I don't want anything to do with those files to be included in this branch if possible. Is there a good way to go about this? My fall back

问题 Git rerere provides for reuse of previous conflict resolutions during rebase, and can even stage the resolved files by setting rerere.autoupdate = True (as detailed in another question). However, even if all conflicts are resolved and all files staged, I still have to run git rebase --continue to continue the rebase operation. How can I automatically continue if rerere has resolved all conflicts and staged all changes? 回答1: No. Rebase or Merge does not automatically provide a provision for

问题 What is the difference from drop in the Git interactive rebase and just deleting the line of the commit? 回答1: There is no difference by default; it's just another way to say the same thing. But, if you set rebase.missingCommitsCheck to warn or error , then removing a line will trigger a warning (useful for detecting a messed-up cut-and-paste). Then setting the line to drop explicitly tells Git that you want to drop that commit, and no warning is shown for it. 回答2: There is in fact another

问题 I happily use vim as my default editor for commits, and do not wish to change it. However, when it comes to rebasing, I find myself squashing dozens and dozens of commits which I find much easier with an interactive editor like Textwrangler (substituting "pick" with "squash" in all but the top commit). Is there any way to specify an alternate editor for a one-off rebase command? I know in vim I can do: :%s/pick/squash/ but that has its own minor annoyances. EDIT - as stated in the comments,

问题 Here's a common workflow hurdle I encounter often: master is our "stable" branch $ git status # On branch master nothing to commit (working directory clean) Create a module on a branch $ git checkout -b foo $ echo "hello" > world $ git add . $ git commit -m "init commit for foo module" $ git checkout master $ git merge foo Do work on master or other branches Over the next couple weeks, more code will be committed to master directly and by other branches. The foo branch will go untouched for

问题 Originally, I had something like this: C---D (branch1) / A---B (master) Because I needed to work on something else (which was unrelated to branch1 ), I decided to make a new branch (called branch2 ). I made a couple of commits on branch2 and then pushed them. Now, my intention was to have master as a root of branch2 . However, I accidentally did this: E---F--G (branch2) / C---D (branch1) / A---B (master) Is there a clean way to make branch2 stem directly from master , as shown below? E---F--G

问题 Objective : I need to make custom patches to a prior release of an upstream project, and I want to be able to apply those patches to the later version. Problem : Rebasing from the maintenance branch to a later version creates conflicts with files that have not been modified in the maintenance branch. Suspicion : I am applying merging or rebasing incorrectly for what I'm trying to accomplish. Example: This is a logical example of what I want to accomplish, but understand that the commit