git-rebase | 易学教程

Remove an unreferenced commit from git repository

阅读更多关于 Remove an unreferenced commit from git repository

问题 I have a git commit history like this: U / A---B---C---D---E master Nothing points to the commit U , but I know its hash. How can I completely remove this commit from my repository as if it never existed? I'm the only person using this repo. I tried using git rebase , but that can either delete parts of a branch or move commits, but doesn't seem to be able to delete a single commit. If I do git checkout <hash> and then git reset --hard HEAD~1 I don't see the the commit anymore. Is it actually

How to combine two unrelated git repositories, preserving history

阅读更多关于 How to combine two unrelated git repositories, preserving history

I don't know git very well. :-/ Background I have two unrelated git-based document repositories that I would like to combine into a single repository. I would like to preserve the original timestamps (dating back to 2005) and individual file histories. The two repos contain no branches, no folders, and there is no overlap in terms of file naming. In ASCII-land, it looks like this: REPO A |-------------------------| REPO B |===============| Where the overlap denotes time. Goal My goal is to "zipper up" the overlapping timestamps so that the two repos look like a single, unbroken history: REPO A

Is there some kind of 'git rebase --dry-run', which would notify me of conflicts in advance?

阅读更多关于 Is there some kind of 'git rebase --dry-run', which would notify me of conflicts in advance?

问题 I'm trying to script rebasing and my script will take different paths depending on if the rebase results in any conflicts. Is there a way to determine if a rebase would result in conflicts before executing the rebase? 回答1: At the time of writing (Git v2.6.1 v2.10.0), the git rebase command offers no --dry-run option. There is no way of knowing, before actually attempting a rebase, whether or not you're going to run into conflicts. However, if you run git rebase and hit a conflict, the process

How to prevent lot of git conflicts when git rebasing lot of commits?

阅读更多关于 How to prevent lot of git conflicts when git rebasing lot of commits?

问题 Story: in the middle of a project my colleague created a new branch from master and started doing her heavy re-factoring work. I created my branch from master and started doing new stuff on the page. We are committing regularly, but only I can rebase code to master (because colleagues changes are too heavy and cannot be deployed from master yet). Unfortunately some of our work rely on the same files. So after few days of work when she finally wanted to rebase her changes to master , she had a

Change timestamps while rebasing git branch

阅读更多关于 Change timestamps while rebasing git branch

问题 I have reorganized the commits in a branch before it is going to be made public causing the timestamps of the commits to be in an mixed up order. I would rather have them be all be today with only seconds in between. Obviously these time stamps won't be correct either, but since this is the time when things go public I prefer that over a mixed up history, time-wise. So how do I tell git to create new timestamps while rebasing? 回答1: git rebase --ignore-date 回答2: In my case rebasing changed

How can I use git rebase without requiring a forced push?

阅读更多关于 How can I use git rebase without requiring a forced push?

问题 In an attempt to achieve git nirvana, I'm spending the day learning how to leverage rebase for situations where I currently merge. When running through what I consider to be a git 101 flow (which I spell out below), I have to push --force when pushing my changes back to the origin. I'm not the only one - I know that this is covered ground (see 1,2,3,4,5), and I understand the technical reasons why a force is necessary. My issue is this --- there are many (many) blog entries singing the

git: what is the correct merging or rebasing workflow to modify a maintenance branch and apply those patches to another branch?

阅读更多关于 git: what is the correct merging or rebasing workflow to modify a maintenance branch and apply those patches to another branch?

Objective : I need to make custom patches to a prior release of an upstream project, and I want to be able to apply those patches to the later version. Problem : Rebasing from the maintenance branch to a later version creates conflicts with files that have not been modified in the maintenance branch. Suspicion : I am applying merging or rebasing incorrectly for what I'm trying to accomplish. Example: This is a logical example of what I want to accomplish, but understand that the commit history between tagged release v1.0 and v2.0 can be hundreds of commits in between. I fork an upstream repo

Git rebase will not continue after a delete/modify conflict

阅读更多关于 Git rebase will not continue after a delete/modify conflict

I'm in the middle of a rebase of my master to a stage branch git checkout stage git rebase master At some time I deleted two files then modified the two files according to GIT. warning: too many files, skipping inexact rename detection CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree. CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test

Git rebase a branch onto master failed, how to resolve?

阅读更多关于 Git rebase a branch onto master failed, how to resolve?

I've been working on a local copy of a remote git repo. I created a branch on my local copy, let's call it 'my_branch'. I've committed a few times on my_branch. I recently pushed 'my_branch' to remote. However I didn't know that someone else added a version to the remote master. So, I fetched it to my local master. So...long story short, my local repo looks like this (I'm trying to use the diagraming convention here ) . --C0--------------C7-- (local master) \ --C1-C2-C3-- (local my_branch) \ --C4-C5-C6-- (local sandbox_branch) I want it to look like: --C0--------------C7-- (local master) \ -

Git rebase loses history, then why rebase?

阅读更多关于 Git rebase loses history, then why rebase?

问题 I've been looking into rebasing with Git over the past couple days. Most of the arguments for rebasing say that it cleans up the history and makes it more linear. If you do plain merges (for example), you get a history that shows when the history diverged and when it was brought back together. As far as I can tell, rebasing removes all that history. Question is this: why wouldn't you want the repo history to reflect all the ways the code developed, including where and how it diverged? 回答1: As