rebase | 易学教程

Edit a merge commit with git rebase

阅读更多关于 Edit a merge commit with git rebase

问题 In Git when I have commits eg. A - B - C and I want to edit the B commit, I use git rebase -i <A-commit-hash> , in the list I write edit command in front of B commit, git rebase stops right after B commit so I can fix anything I want using git commit --amend , and then I continue using git rebase --continue . As far as I know this is the best practice how to do this. With this method I can edit any commit in the past (as long as it hasn't been pushed to remote branch yet), and moreover with

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_foods.txt dan$ git commit -am "Add bagels to favorite_foods.txt" brian$ echo 'root beer' >> favorite

Change old commit message on Git

阅读更多关于 Change old commit message on Git

问题 I was trying to edit an old commit message as explained here. The thing is that now, when I try to run rebase -i HEAD~5 it says interactive rebase already started . So then I try: git rebase --continue but got this error: error: Ref refs/heads/master is at 7c1645b447a8ea86ee143dd08400710c419b945b but expected c7577b53d05c91026b9906b6d29c1cf44117d6ba fatal: Cannot lock the ref 'refs/heads/master'. Any ideas? 回答1: It says: When you save and exit the editor, it will rewind you back to that last

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) error: failed to push some refs to 'ssh://git@coderepo.com:7999/repo/myproject.git' hint: Updates were

How rebase result may differ from result of a merge?

阅读更多关于 How rebase result may differ from result of a merge?

问题 In one of GitHub's articles I read the following: You aren't able to automatically rebase and merge on GitHub when: Rebasing the commits is considered "unsafe", such as when a rebase is possible without merge conflicts but would produce a different result than a merge would. It isn't clear for me how a rebase may produce a different result than a merge. Can anyone explain how is it possible? Link to the original article: https://help.github.com/articles/about-pull-request-merges/ 回答1: Here's

How to squash/rebase in a single shot

阅读更多关于 How to squash/rebase in a single shot

问题 How can I, with minimum effort, squash all my commits (even with merges and conflict resolutions) to a single one on a feature branch and then rebase on top of the branch where I started developing from? Don't want to redo conflict resolution that's already done . Keep hassle to a minimum. Suppose the branches we are talking about are master and featureX. 回答1: First check with git branch , what's your current working branch. Next, if it isn't featureX already, switch to it, using git checkout

git commit --amend in detached HEAD state

阅读更多关于 git commit --amend in detached HEAD state

问题 I understand that the correct way of amending an old GIT commit is to use rebase --interactive , but just to get clear on the concepts, I would like to understand what happens when I do git checkout <commit> change something in a file add the changed file to the index and then git commit . --amend When I do this, instead of amending the commit, it branches a new commit off of the PARENT of that same commit. Is this just GIT's way of telling me that I cannot amend a commit that already already

Is there a way to squash a number of commits non-interactively?

阅读更多关于 Is there a way to squash a number of commits non-interactively?

I'm trying to squash a range of commits - HEAD to HEAD~3. Is there a quick way to do this, or do I need to use rebase --interactive? Make sure your working tree is clean, then git reset --soft HEAD~3 git commit -m'new commit message' n8tr I personally like wilhelmtell's solution: git reset --soft HEAD~3 git commit -m 'new commit message' However, I made an alias with some error checking so that you can do this: git squash 3 'my commit message' I recommend setting up aliases that actually run scripts so that it is easier to (a) code up your scripts and (b) do more complex work with error

Rebasing and what does one mean by rebasing pushed commits

阅读更多关于 Rebasing and what does one mean by rebasing pushed commits

It is often said that, you should not rebase commits that you have already pushed. What could be meaning of that? The ProGit book has a good explanation . The specific answer to your question can be found in the section titled " The Perils of Rebasing ". A quote from that section: When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work

git - setting a commit's parent without rebase

阅读更多关于 git - setting a commit's parent without rebase

问题 I used git-svn to create a git mirror of an SVN repository. The structure inside the SVN was a little off-standard, so git created a branch that has no common commit with the master branch. A---B---C topic D---E---F---G master I know that commit A is based off commit E and I'm pretty positive that I've fixed the issues causing git not to recognize that fact (using filter-branch ). What I want to do is re-attach topic to the master branch, setting E as the parent of A : A---B---C topic / D---E