rebase

问题 I'm using git rebase -i to rewrite history — in this case, make a small alteration to an earlier commit's change set. In other words, A---B---C master ---> A---B'--C master I know C is implicitly changing, too, but you get the idea. Here's my progress so far: git rebase -i HEAD~2 Change B from keep to edit . Edit the file. git commit -a --amend git rebase --continue "Could not apply [C]..." I've resolved the conflicted lines in C , but am unsure how to mark it as resolved so that the rebase

问题 I'm looking for a good description of what happens if one commits during rebase and how this could be 'reverted' in an easy way. Let's consider a scenario, where a large commit is rebased. During rebase a conflict appears and user begins merging changes. Now, imagine a scenario where you were almost done, but you didn't call git rebase --continue - for whatever reason (be it long weekend or such). The next week you just resumed working, stil during rebase. Finally, you call git commit --amend

问题 Using git v1.7.1 I'm trying to do a rebase with both the --preserve-merges and --onto features at the same time. The end results seems to be without the merge commits, and so appears linear. I'd rather preserve the merge commits, for the same reason that people would often use --preserve-merges (easier to see the group of commits that was logically a separate feature and developed in its own branch). My master branch (the destination for the rebase) is boring: A-B-C The feature branch I want

问题 I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has it's master branch rebased nightly from the upstream SVN, and we are working on feature branches. For example: remote: master local: master feature I can successfully push my feature branch back to the remote, and end up with what I expect: remote: master feature local: master feature I then re-setup the branch to track the remote: remote:

问题 There're few question about "flattening merge" on StackOverflow, with an answer usually being "git rebase". These answers though miss one crucial point - order of commits. Suppose there's a branch A with commits of Jun 1 and Aug 1, and branch B with commit of Jul 1 ( UPDATE to reinstate the usecase described below: branches are fully independent and don't have common ancestry, for example coming from 2 different repositories). When merging B into A, there will be following history (per git

问题 I have started using Git in the middle of my project, where the first two commits are just some initial settings (.gitignore and .gitattributes), and the third commit M2 adds the content of the SVN trunk: I1 -- I2 -- M2 -- N -- .. -- Z I have imported the SVN history in a branch named svn , where M1 is the SVN trunk (with the same content as M2 , except .gitignore and .gitattributes): A -- B -- ... -- K -- L -- M1 Q: What is the best approach in merging both branches? I could merge M1 and M2

问题 I have started using Git in the middle of my project, where the first two commits are just some initial settings (.gitignore and .gitattributes), and the third commit M2 adds the content of the SVN trunk: I1 -- I2 -- M2 -- N -- .. -- Z I have imported the SVN history in a branch named svn , where M1 is the SVN trunk (with the same content as M2 , except .gitignore and .gitattributes): A -- B -- ... -- K -- L -- M1 Q: What is the best approach in merging both branches? I could merge M1 and M2

问题 In Git I can do this: 1. Start working on new feature: $ git co -b newfeature-123 # (a local feature development branch) do a few commits (M, N, O) master A---B---C \ newfeature-123 M---N---O 2. Pull new changes from upstream master: $ git pull (master updated with ff-commits) master A---B---C---D---E---F \ newfeature-123 M---N---O 3. Rebase off master so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ git rebase master master A---B---C---D--

问题 In Git I can do this: 1. Start working on new feature: $ git co -b newfeature-123 # (a local feature development branch) do a few commits (M, N, O) master A---B---C \ newfeature-123 M---N---O 2. Pull new changes from upstream master: $ git pull (master updated with ff-commits) master A---B---C---D---E---F \ newfeature-123 M---N---O 3. Rebase off master so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ git rebase master master A---B---C---D--

问题 Need to push existing git repo to Gerrit however have issues doing this: remote: ERROR: missing Change-Id in commit message footer because repo did not contain .git/hooks/commit-msg . Now I have the script installed, however need to change hundreds of commit messages to add Change-Id everywhere. How to make it automatically in the best and easiest way? Possible solutions: I see some topics here suggest to use git rebase -i , however it is interactive and mostly manual process. Others to use