rebase

问题 I have a master branch in my project, that I use to pull changes from other people. From that, I usually have several topic branches on which I\'m currently working. My question is: Is there a way for me to pull new changes into my master and then rebase ALL of my topic branches onto that at once? This is the situation: D--E topic1 / A--B--C master \\ F--G topic2 And I want to accomplish this with one single command (H came from upstream) : D\'--E\' topic1 / A--B--C--H master \\ F\'--G\'

问题 I made some changes in my master branch and want to bring those upstream. when I cherry-pick the following commits however I get stuck on fd9f578 where git says: $ git cherry-pick fd9f578 fatal: Commit fd9f57850f6b94b7906e5bbe51a0d75bf638c74d is a merge but no -m option was given. What is git trying to tell me and is cherry-pick the right thing to be using here? The master branch does include changes to files which have been modified in the upstream branch, so I\'m sure there will be some

问题 Suppose you have a history containing the three commits A, B and C : A-B-C I would like to combine the two commits A and B to one commit AB : AB-C I tried git rebase -i A which opens up my editor with the following contents: pick e97a17b B pick asd314f C I change this to squash e97a17b B pick asd314f C Then Git 1.6.0.4 says: Cannot \'squash\' without a previous commit Is there a way or is this just impossible? 回答1: Use git rebase -i --root as of Git version 1.7.12. In the interactive rebase

问题 We have all heard that one should never rebase published work, that it’s dangerous, etc. However, I have not seen any recipes posted for how to deal with the situation in case a rebase is published. Now, do note that this is only really feasible if the repository is only cloned by a known (and preferably small) group of people, so that whoever pushes the rebase or reset can notify everyone else that they will need to pay attention next time they fetch(!). One obvious solution that I have seen

问题 When doing a git rebase, I often have difficulty working out what is happening with the \'local\' and \'remote\' when resolving conflicts. I sometimes have the impression that they swap sides from one commit to the next. This is probably (definitely) because I still haven\'t properly understood. When rebasing, who is \'local\' and who is \'remote\'? (I use P4Merge for resolving conflicts) 回答1: TL;DR; To summarize (As Benubird comments), when: git checkout A git rebase B # rebase A on top of B

问题 This question already has an answer here: Edit the root commit in Git? 5 answers I want to change something in the first commit of my project with out losing all subsequent commits. Is there any way to do this? I accidentally listed my raw email in a comment within the source code, and I\'d like to change it as I\'m getting spammed from bots indexing GitHub. 回答1: As mentioned by ecdpalma below, git 1.7.12+ (August 2012) has enhanced the option --root for git rebase : " git rebase [-i] --root

问题 I\'ve asked before about how to squash the first two commits in a git repository. While the solutions are rather interesting and not really as mind-warping as some other things in git, they\'re still a bit of the proverbial bag of hurt if you need to repeat the procedure many times along the development of your project. So, I\'d rather go through pain only once, and then be able to forever use the standard interactive rebase. What I want to do, then, is to have an empty initial commit that

问题 During git rebase origin/development the following error message is shown from Git: fatal: refusing to merge unrelated histories Error redoing merge 1234deadbeef1234deadbeef My Git version is 2.9.0. It used to work fine in the previous version. How can I continue this rebase allowing unrelated histories with the forced flag introduced in the new release? 回答1: The default behavior has changed since Git 2.9: "git merge" used to allow merging two branches that have no common base by default,

问题 Does anybody know how to easily undo a git rebase? The only way that comes to mind is to go at it manually: git checkout the commit parent to both of the branches then create a temp branch from there cherry-pick all commits by hand replace the branch in which I rebased by the manually-created branch In my current situation this is gonna work because I can easily spot commits from both branches (one was my stuff, the other was my colleague\'s stuff). However my approach strikes me as

问题 I\'m new to git and I\'m trying to understand the difference between a squash and a rebase. As I understand it you perform a squash when doing a rebase. 回答1: Both git merge --squash and git rebase --interactive can produce a "squashed" commit. But they serve different purposes. git merge --squash abranch will produce a squashed commit on the destination branch, without marking any merge relationship. (Note: it does not produce a commit right away: you need an additional git commit -m "squash