CODEWITHSUNDEEP
gitazure-devops
laurisvr
laurisvr

Reputation: 2822

Split up single commit into multiple commits in existing git history

Recently I migrated an existing code base from tfs to azure devops git. Due to a number of obstacles the last ~20 commits did not migrate successfully. Because of time constraints I decided to simply copy the latest code base onto the last successfully migrated git commit and commit this as a new commit. Since then we have been working on top of this commit.

Now however I have managed to retrieve the commits that were skipped during this migration process.And I am hoping to fix the history of the git commits. I am however aware of the golden rule of git, that you should not mess with history once it has been committed.

My questions therefore are:

Upvotes: 1

Views: 283

Answers (1)

ianinini
ianinini

Reputation: 680

Will you be able to push these changes to origin?

That depends how origin is configured. The syntax you would use is 

git push -f origin <commit id>:master

to do a forced push. However some servers prohibit this for non-admin roles, for obvious reasons.

When these changes are pushed to origin, will they automatically be retrieved when others do a pull?

They'll be retrieved. The real question is whether their local commits will apply. The answer to this is less clear to me. I believe it may depend on the nature of the original commit.

You can test this for yourself locally of course. Set up a local branch mastertmp that's a copy of the old master's HEAD. 

git checkout -b mastertmp <commit id of current master>

Set up another branch that tracks it:

git checkout -b worktmp -t mastertmp

(Maybe add some more commits to worktmp for authenticity. Not necessary.)
Now "rework" mastertmp by pointing it at your proposed new history

git checkout mastertmp
git reset --hard <commit id of reworked master>

Now change branch back to worktmp and pull.

git checkout worktmp
git pull --rebase

If this works, then there is no reason why it will not work for your colleagues. It doesn't matter to the logic whether you worktmp is tracking a local or a remote branch.

Note: To keep track of which branch is tracking which, use the command git branch -vv.

Upvotes: 2

Related Questions