git-rebase | 易学教程

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

Can tags be automatically moved after a git filter-branch and rebase?

阅读更多关于 Can tags be automatically moved after a git filter-branch and rebase?

问题 edit The question boils down to \"Can git rebase be instructed to rebase tags, too?\" But an answer to the original question would also help. Asking How to prepend the past to a git repository? I followed these instructions. < edit >Then I rebased to include a file that was only in the snapshots, see here.< /edit > Since history was rewritten (by git filter-branch or git rebase or both?) all tags are still on the original time line* and I\'d somehow like to move them to the new one. I think I

git remove merge commit from history

阅读更多关于 git remove merge commit from history

问题 My Git history looks like that : I would like to squash the purple commits into a single one. I don\'t want to see them ever again in my commit log. I\'ve tried to do a git rebase -i 1 , but even though 1 is on the blue branch (cf. picture), I still see every commit on my purple branch. How can I completely remove the purple branch (from commit log) ? 回答1: Do git rebase -i <sha before the branches diverged> this will allow you to remove the merge commit and the log will be one single line as

git rebase without changing commit timestamps

阅读更多关于 git rebase without changing commit timestamps

Would it make sense to perform git rebase while preserving the commit timestamps? I believe a consequence would be that the new branch will not necessarily have commit dates chronologically. Is that theoretically possible at all? (e.g. using plumbing commands; just curious here) If it is theoretically possible, then is it possible in practice with rebase, not to change the timestamps? For example, assume I have the following tree: master <jun 2010> | : : : oldbranch <feb 1984> : / oldcommit <jan 1984> Now, if I rebase oldbranch on master , the date of the commit changes from feb 1984 to jun

Remove folder and its contents from git/GitHub's history

阅读更多关于 Remove folder and its contents from git/GitHub's history

I was working on a repository on my GitHub account and this is a problem I stumbled upon. Node.js project with a folder with a few npm packages installed The packages were in node_modules folder Added that folder to git repository and pushed the code to github (wasn't thinking about the npm part at that time) Realized that you don't really need that folder to be a part of the code Deleted that folder, pushed it At that instance, the size of the total git repo was around 6MB where the actual code (all except that folder) was only around 300 KB . Now what I am looking for in the end is a way to

When git rebasing two branches with some shared history, is there an easy way to have the common history remain common?

阅读更多关于 When git rebasing two branches with some shared history, is there an easy way to have the common history remain common?

问题 Suppose we have the following revision graph: A-X-Z--B \\ \\-C with A preceding both B and C. Further suppose I rebase A from upstream, creating a new commit A*, and then rebase both B and C onto A*. The resulting revision graph is the following: A*-X\'-Z\'-B \\ \\-X\"-Z\"-C Note that the shared history is no longer shared. Is there a simple way to fix this, other than, say, rebasing B and then rebasing C onto Z\' explicitly. In other words is there a better way to automatically rebase

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

How to rebase local branch with remote master

阅读更多关于 How to rebase local branch with remote master

问题 I have cloned project from master branch from remote repository remote_repo . I create new branch and I commit to that branch. Other programmers pushed to remote_repo to master branch. I need now to rebase my branch RB onto remote_repo master. How to do this ? What commands to type to terminal ? 回答1: First fetch the new master from the upstream repository, then rebase your work branch on that: git fetch origin # Updates origin/master git rebase origin/master # Rebases current branch onto

What are the practical consequences of rewriting Git history?

阅读更多关于 What are the practical consequences of rewriting Git history?

问题 Our project has been using Git for a week or so now, and we\'re all enjoying it a lot (using it in a tight collaborative group turns out to be quite a different Git experience). To keep things as simple as possible, we do not do any rebasing or history modifications. But we did make a few mistakes in the first week. A few commits were made that shouldn\'t have been done, and we managed to merge a feature branch into the wrong integration branch (1.1 instead of 1.0). And we didn\'t find out

I can't understand the behaviour of git rebase --onto

阅读更多关于 I can't understand the behaviour of git rebase --onto

问题 I have noticed that the two blocks of following git commands have different behaviours and I don\'t understand why. I have a A and a B branch that diverge with one commit ---COMMIT--- (A) \\ --- (B) I want to rebase B branch on the lastest A (and have the commit on the B branch) ---COMMIT--- (A) \\ --- (B) No problem if I do: checkout B rebase A But if I do: checkout B rebase --onto B A It doesn\'t work at all, nothing happens. I don\'t understand why the two behaviours are different.