rebase | 易学教程

Resolving a 'both added' merge conflict in git?

阅读更多关于 Resolving a 'both added' merge conflict in git?

问题 I'm rebasing in git, and one conflict I get is 'both added' - that is, exactly the same filename has been added independently in my branch, and in the branch I'm rebasing on. git status tells me: # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both added: src/MyFile.cs My question is, how do I resolve this? Must I use a merge tool or is there a way I can do it just from the commandline? If I git rm src/MyFile

Git rebase: conflicts keep blocking progress

阅读更多关于 Git rebase: conflicts keep blocking progress

问题 I have a git branch (called v4), that was made from master just yesterday. There were a couple of changes to master, that I want to get into v4. So, in v4, I tried to do a rebase from master, and one file keeps screwing things up: a one-line text file, that contains the version number. This file is app/views/common/version.txt , which before rebasing contains this text: v1.4-alpha-02 Here's what I'm doing: > git rebase master First, rewinding head to replay your work on top of it... Applying:

How to filter history based on gitignore?

阅读更多关于 How to filter history based on gitignore?

问题 To be clear on this question, I am not asking about how to remove a single file from history, like this question: Completely remove file from all Git repository commit history. I am also not asking about untracking files from gitignore, like in this question: Ignore files that have already been committed to a Git repository. I am talking about "updating a .gitignore file, and subsequently removing everything matching the list from history", more or less like this question: Ignore files that

When will `git pull --rebase` get me in to trouble?

阅读更多关于 When will `git pull --rebase` get me in to trouble?

I understand that when I use git pull --rebase , git will re-write history and move my local commits to occur after all of the commits in the branch I just pulled from. What I don't understand is how this would ever be a bad thing. People talk about getting in to trouble with git pull --rebase where you can end up with a branch that other people can't pull from. But I don't get how that's possible since all you're doing is replaying your local, not-yet-public, commits on top of the branch you pulled from. So, what's the problem there? VonC It is only an issue if you have only published (pushed

How to merge two branches without a common ancestor?

阅读更多关于 How to merge two branches without a common ancestor?

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 into M3 , and then rebase, but I don't know how to delete the I1 and I2 commits and if I can safely

Git commits are duplicated in the same branch after doing a rebase

阅读更多关于 Git commits are duplicated in the same branch after doing a rebase

I understand the scenario presented in Pro Git about the risks of git rebase . The author basically tells you how to avoid duplicated commits: Do not rebase commits that you have pushed to a public repository. I am going to tell you my particular situation because I think it does not exactly fit the Pro Git scenario and I still end up with duplicated commits. Let's say I have two remote branches with their local counterparts: origin/master origin/dev | | master dev All four branches contains the same commits and I am going to start development in dev : origin/master : C1 C2 C3 C4 master : C1

git reword without resolving merge conflicts again

阅读更多关于 git reword without resolving merge conflicts again

问题 Is it possible to change commit messages using git rebase, but without having to re-resolve merge conflicts? I need to bowdlerize an older repo and I don't want to change any of the actual code, just the messages. I've tried --preserve-merges . 回答1: There's a little-known feature of git called "Reuse Recorded Resolutions", or rerere . You can enable it globally by running git config --global rerere.enabled true . If rerere is enabled, git will automatically save conflict resolutions, and will

Rebasing a Git merge commit

阅读更多关于 Rebasing a Git merge commit

Take the following case: I have some work in a topic branch and now I'm ready to merge back to master: * eb3b733 3 [master] [origin/master] | * b62cae6 2 [topic] |/ * 38abeae 1 I perform the merge from master, resolve the conflicts and now I have: * 8101fe3 Merge branch 'topic' [master] |\ | * b62cae6 2 [topic] * | eb3b733 3 [origin/master] |/ * 38abeae 1 Now, the merge took me some time, so I do another fetch and notice that the remote master branch has new changes: * 8101fe3 Merge branch 'topic' [master] |\ | * b62cae6 2 [topic] | | * e7affba 4 [origin/master] | |/ |/| * | eb3b733 3 |/ *

Git rebase subtree

阅读更多关于 Git rebase subtree

问题 Suppose I have the following scenario: o (master) / o--o (WIP1) / / o--o--o--o--o--o (WIP2) (X) \ o--o (WIP3) Is there a git command which creates a new branch so that it contains the subtree after branch X? I want to perform a "large rebase", I want the three WIP branches rebased on master. I know I can do that with some Bash scripting but I'd like to know how to do that using a git command. 回答1: There is no single git command for that. You will have to do some manual work. In your situation

Completely remove (old) git commits from history

阅读更多关于 Completely remove (old) git commits from history

问题 I'm starting a project using git where I'll be committing very large files, but only a few times a week. I've tried to use git as-is and it seems to store the entire file in each commit where it is changed. This will not work for this project, the repository would grow out of control. So, I want to reduce the size of the repository. My first thought was to "simply" remove all commits older than say two weeks, or only keep e.g. five commits in the history (this is probably better :)) I've