git-rebase

问题 TL;DR: Is it possible to rename a commit from a merged (no fast forward merge) branch - without destroying history? I want to rename a commit. Something like rebase --interactive HEAD~5 . But I want to keep the HEADs in their current position. Rebase will flatten the log. I'm using feature branches * c3cb3ad - Merge branch 'featureX' into develop (15 minutes ago) <FOO> |\ | * d945c71 - Did stuff (17 minutes ago) <FOO> | * d4356f4 - inline commits are aweosm <FOO> (27 minutes ago) <LSC> |/ *

问题 My git branches look like this: master-*-*-*-*-*-*-implement_x \ \-*-further_foo_fixes_that_depend_on_x \ \-*-*-further_bar_fixes_that_depend_on_x \ \-implement_x_rebased It ended this way, because I thought my branch implement_x would be merged upstream as it is, but I was asked to squash it to a single commit, thus implement_x_rebased . However, I already started several branches for further fixing and developing that depend on my work, while waiting for the implement_x to get merged. Now I

问题 I have a project which I am working by myself (no team). I have tagged some commits like v0.0.1 , v0.0.9 ... v0.9.1 and so on. Now, I would like to rebase them leaving only those version tagged commits, but I have two problems: When I do git rebase -i v0.0.1 (the first version, more than 2000 commits since then) I dont know how to show the tags inside the 'rebase screen', that is where I define squashs; Even if I was be able to see the tags inside the rebase screen it would be so time

问题 I've discovered that I have a file committed to my repo year ago, which I never wanted to be there. Before I make my repo public I'd like to revert, or actually remove commit which introduced this file so no one will be able to access this file. I've used interactive rebase so I was able to delete unwanted commit. It looked promising but after applying ~400 commits from 800 there is a conflict. The conflict is caused by nonlinear history - there was a branch and one file was modified in both

问题 I have a git repository with about 3500 commits and 30,000 distinct files in the latest revision. It represents about 3 years of work from multiple people and we have received permission to make it all open-source. I am trying hard to release the entire history, instead of just the latest version. To do this I am interested in "going back in time" and inserting a license header at the top of files when they are created. I actually have this working, but it takes about 3 days running entirely

问题 I have some history rewriting to do for which I'd like to keep my original tree intact for now. The rewritten tree should however copy the tags previously used as well. Is there any less manual option than e.g. prepending tag names with the branch name? 回答1: No, there is nothing like a per-branch tag in git. All branches and tags are just kinds of refs in Git; a ref is just a name that points to a particular revision in the revision history. For instance, if you have devel and master branches

问题 Recently I had a lot of success rebasing a local-only repository while changing commit messages and after that only the commit messages had been changed but the history itself hasn't. Now I have my repositories - remotely and locally. I made several commits on several branches and already pushed them. Due some reasons I need to change some commit masseages over several branches and tried to use rebase interactive like before. But the commits appeared at the end of the current checked out

问题 Based on this: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase git rebase will make it possible to maintain a linear history (a merge "always" results in a fast-forward) But if I want to enforce a linear history and require developers to always rebase their feature branches on latest master will that not result in collaboration/sharing feature branches going out the window? See: Don't rebase public history so is it possible to enforce linear history using git rebase and

问题 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

问题 We recently completed a conversion from Mercurial to Git, everything went smoothly, we were even able to get the transforms needed to make everything look / work relatively correctly in the repository. We added a .gitignore and got underway. However we're experiencing some extreme slowdowns as soon as we encorporate/work with any of our old feature branches. A little exploring and we found that since the .gitignore was only added to the develop branch when we look at other commits without