help understanding conflict handling during git rebase
I am working out how to use git rebase. I created a repository and did these steps.
- I created index html and then commited it on main branch.
- I created a branch called modify and in it i added a blank line to index html and commited. I created index.css and commited that to the same branch.
- I created another branch called delete and deleted index.html then commited it.
now I want you guys to think that delete is my feature branch I am using to do something and modify is upstream that has been updated while I was working on delete.
I checkout the delete branch and do this command.
git rebase modify
to my understanding this will take the commits from modify then apply them on top of delete's commits? I get a merge conflict obviously because delete branch has deleted index.html while modify has modified it. I choose to do
git rm index.html
git rebase --continue
to solve the confict. this makes it so my delete branch commit history looks like the screenshot below. The commit for deleting is above the commits from modify I am unsure of the details of this. I though the branch we are passing as argument to rebase will have it's commits on top because we're taking the unique commits from modify and putting em on delete branch(the commit hashes are new). unless the conflicted commits go last?
14 Replies
I'm pretty sure rebase just slots the commits in based on their timestamp
I think if you'd deleted index in your delete branch, committed that, then modified it in the modify branch, you might see something different?
though you might then end up with a delete branch with uncommitted changes, than you'd then have to recommit
so you mean commit on delete first then commit on modify then try to rebase?
yeah
cause rebase should affect HEAD, and not necessarily any of the previous commits
alright let me try
no it gave the same result
oh, wait, I'm misremembering
rebase shoves changes in before the first commit of the branch
by design
you're trying to update the code you're editing based on (usually) a development branch that others also commit into, so you want all those changes to be there at the start
so add the unique commits from modify first on top of the shared commits and then at the end goes the commits i made on this delete branch?
actually what do you mean by first commit of the branch.
does it mean the latest commit on the branch even if branch has multiple commits? or does it mean the very first commit created after creating the branch
I assume this means first ancestor commit that is same in both branches
basically this
the commit that creates the branch
Yes, the most recent commit that is the same for both branches
alright got it thanks this cleared up things
one last question. Is the way I currently did rebasing acceptable for a pull request?
This is assuming the file that was deleted in the delete branch was redundant and a leftover
hmm, I think? I'm not sure, it really depends on the culture of the repo too I think
check with whoever's maintaining how they want their pull requests to look, but generally rebasing is considered necessary if there's changes to the branch you're merging into
alright gotcha. Thanks again for the help