GIT - Conflict Resolution
- dotsincloud
- Apr 4
- 3 min read
Situation: I have forked a repository. When trying to raise a PR form forked repository to original repository in Bitbucket I am getting a conflict message. Says file modified in both source and destination. How to fix this?
Why is this happening?
Appears that my forked repository is different form the original repo where somebody might have had changes. That is why I am getting Conflict which raising a PR.
The core reason you're encountering conflicts when raising a Pull Request (PR) from your forked repository to the original repository is due to differences in their respective histories. Specifically:
Diverged Histories:
The original repository has likely had changes committed to it since you forked it.
You've also made changes in your forked repository.
When you try to merge these two histories (via a PR), Git finds that the same lines of code have been altered in both places, leading to conflicts.
Changes by Others:
If other contributors have made changes to the original repository, those changes will also contribute to the divergence.
This is especially common in active projects where multiple people are working simultaneously.
In essence, Git is saying, "I don't know which version of these lines to keep because they've been modified independently." Therefore, it requires your manual intervention to resolve the conflict.
Therefore your assumption is correct. The forked repo and the original repo are different.
How to fix this?
To fix the conflict arising from the differences between your forked repository and the original repository, you need to synchronize your fork with the original repository and then resolve any remaining conflicts. Here's a step-by-step guide:
git remote add upstream <original-repository-url>
(Replace <original-repository-url> with the URL of the original repository (e.g., https://bitbucket.org/owner/original-repo.git).)
Fetch Changes from the Upstream Repository:
git fetch upstream
Update Your Local Branch:
Now, you need to merge the changes from the upstream branch into your local branch.
If you are trying to merge into the main branch of the original repo, and your local branch is also main, then:
git checkout main # or the branch you are working on.
git merge upstream/main # or upstream/development if that is your target.
If you are working on a feature branch, and trying to merge that into the original repo's main branch.
git checkout your-feature-branch
git merge upstream/main # or the target branch.
Resolve Conflicts (if any):
If there are conflicts, Git will tell you which files are affected.
Open the conflicted files in a text editor.
Look for the conflict markers: <<<<<<< HEAD, =======, and >>>>>>> upstream/main.
Manually resolve the conflicts by choosing the changes you want to keep.
Remove the conflict markers.
Save the files.
Stage the resolved files:
git add <conflicted-file>
git commit -m "Resolve merge conflicts"
git push origin your-feature-branch # or main.
Update Your Pull Request:
Go to your pull request in Bitbucket.
Bitbucket should automatically detect the changes you pushed to your fork.
The conflicts should be resolved. If they are not, review the previous steps.
Important Notes:
Regularly Sync: To minimize conflicts, regularly sync your fork with the original repository by repeating steps 2 and 3.
Rebase vs. Merge:
Merging (as shown above) creates a merge commit, preserving the history of both branches.
Rebasing rewrites the history of your branch, making it appear as if you started working on it after the latest changes from the upstream branch. Rebasing can make the history cleaner, but it can also make it harder to understand if you're not careful. If you are working on a branch that other people depend on, do not rebase it.
Communication: If you're working on a team project, communicate with other developers to avoid conflicts.
Git GUI Tools: Git GUI tools can simplify the conflict resolution process.
Kommentare