rebase | 易学教程

How to rebase one Git repository onto another one?

阅读更多关于 How to rebase one Git repository onto another one?

I had one Git repository (A) which contains the development of a project until a certain point. Then I lost the USB stick this repo A was on. Luckily I had a backup of the latest commit, so I could create a new repository (B) later where I imported the latest project's state and continue development. Now I recovered that lost USB stick, so I have two Git repositories. I think I just have to rebase repo B onto repo A somehow, but I have no idea how to do that, maybe using fetch/pull and rebase? Josh Lee If A and B are not the same repo (you created B by using the latest working copy you had),

git rebase and git push: non-fast forward, why use?

阅读更多关于 git rebase and git push: non-fast forward, why use?

I have a branch that should be available to other contributors and that should constantly stay up to date with the master. Unfortunately, every time I do 'git rebase' and then try to push, it results in 'non-fast forward' message and abortion of pushing. The only way to push here is to use --force. Does that mean I should use 'git merge' instead of rebasing if my branch went public and others are working on it? A few notes on how git works (non technical): When you rebase, git takes the commits in question, and "recommits" them on top of a clean history. This is to prevent the history from

How do I use git rebase -i after git merge without messing things up?

阅读更多关于 How do I use git rebase -i after git merge without messing things up?

问题 I have the following situation: I made some commits to my local repository, and then a huge merge of another branch (~150 commits) into the master - it had a lot of conflicts in it. Now, I want to move a commit I made before the merge to be after it before pushing. Normally, I would use "rebase -i" for it. Unfortunately, the default behavior is to break the one-merge-commit I did that actually added 150 more commits to master into separate commits (I understand it's like if I would use rebase

git rebase after previous git merge

阅读更多关于 git rebase after previous git merge

问题 I have the following situation: I created a clone (Y) from a main repository(X), because there were many people working on Y we didn't do any rebase but only merge s. When we want to deliver( push ) Y to X we would like to do a rebase in order to have things nice and clean The problem is that when doing rebase we are asked to do all the merges that we already did in the previous merge steps. Is there a solution to this, beside the one that means actually re-doing the merges? I expected it to

Can I make fast forwarding be off by default in git?

阅读更多关于 Can I make fast forwarding be off by default in git?

I can't really ever think of a time when I would use git merge rather than git rebase and not want to have a commit show up. Is there any way to configure git to have fast forwarding off by default? The fact that there's an --ff option would seem to imply that there's a way, but I can't seem to find it in the documentation. Yes, there is --no-ff . You can configure merge options per branch, e.g. git config branch.master.mergeoptions "--no-ff" adds the following to your $(REPO)/.git/config file: [branch "master"] mergeoptions = --no-ff Footnote: speaking of my experience, I eventually found

git pull --rebase lost commits after coworker's git push --force

阅读更多关于 git pull --rebase lost commits after coworker's git push --force

问题 I thought I understood how git pull --rebase was working, but this example is confusing me. I would have guessed that the following two scenarios would produce identical results, but they differ. First, the one that works. # Dan and Brian start out at the same spot: dan$ git rev-parse HEAD 067ab5e29670208e654c7cb00abf3de40ddcc556 brian$ git rev-parse HEAD 067ab5e29670208e654c7cb00abf3de40ddcc556 # Separately, each makes a commit (different files, no conflict) dan$ echo 'bagels' >> favorite

Git push rejected “non-fast-forward”

阅读更多关于 Git push rejected “non-fast-forward”

问题 I am fairly new to git yet currently using it to manage our code in a team environment. I had some rebasing issues and I fixed them using git checkout --ours filename.txt git add filename.txt git rebase --continue Now I wish to push my changes, and so running the following command $ git push origin feature/my_feature_branch gives me the following error: To ssh://git@coderepo.com:7999/repo/myproject.git ! [rejected] feature/my_feature_branch -> feature/my_feature_branch (non-fast-forward)

Git: How to rebase many branches (with the same base commit) at once?

阅读更多关于 Git: How to rebase many branches (with the same base commit) at once?

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' topic2 Now, I know I can accomplish this by rebasing topic1 and topic2 onto master, and I could even write a

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

git cherry-pick says “…38c74d is a merge but no -m option was given”

阅读更多关于 git cherry-pick says “…38c74d is a merge but no -m option was given”

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 merge conflicts but those aren't too bad to straighten out. I know which changes are needed where. These