![]() Option 3: reclone your project and copy files over It had somehow rewound history and didn't recognize the shared commit history between master and the branch. When I started to fix merge conflicts on master, I noticed that it was starting with the initial commit history, all the way back at the start of the project. I recently experienced that myself when trying to merge my local branch onto local master. ![]() But as the post states, "it has the potential for problems when you have more than one stream of development". This second option was recommended in this StackOverflow post and uses the -ours flag to ignore any changes in master that would conflict with changes in the branch. Option 2: git merge -ours (USE WITH CAUTION) If you want to recreate your branch again to do more work on it, just create and checkout that branch again with git checkout -b branchName. Git push origin master -f //push new master to origin master with force Git branch -m branchName master //rename your branch to master Here's how to do that: git branch -m master old-master //-m to rename we are renaming master to old-master If trying to merge your branch onto master looks like it will be another half hour or more, consider renaming your branch to master. In reality, your branch now has your best and most up-to-date code and furthermore, after rebasing you have a history of all the commits on the shared group repo. The problem is I often forget to do that before I rebase. This will likely help you avoid many merge conflicts after you rebase. Option 1: Merge back into master before rebasingĪfter you commit and are ready to rebase the group repo's commit onto your own, remember to first switch to master and do a git merge to merge your branch onto local master. Here are some techniques to help you avoid this problem and solutions if you do come up against it. But I've just spent an hour (sometimes) rebasing my teams work onto my local branch and now I have to do the same again with my local branch onto my local master. My best case scenario is that it merges fine and doesn't scream at me that there are merge conflicts. We always want master to have the latest good code. My next step would be to merge my local branch that I've been working on and now has my latest code onto my local master branch. Merging local branch onto local master with merge conflicts That's all fine and dandy (although generally never is find and dandy). Once I've rebased, I do a git push origin and then from my GitHub repo (the one that resulted from forking the team repo), I do a pull request (PR) and another team member reviews and merges in my PR. This is invariably the hard part since I have to understand and make decisions about the code my partners have written that may conflict with what I have in local files. I do a bunch of work (git committing frequently) and then when I'm ready to share, I do a git pull -rebase upstream master which rebases the latest commit on the shared project repo. I create a local branch to work on some new feature or bug fix. We clone down our forked repo and work from that. We have a central project GitHub repo that we've all forked. However, the last thing you want to do is deal with merge conflicts on a local git branch that you rebase from a shared Git repo and then deal with those same merge conflicts again when you go to merge your branch into your local master. Anybody who has been working with Git long enough knows that they are to be lived with but certainly not appreciated. When working on a team project, merge conflicts are invariably going to happen.
0 Comments
Leave a Reply. |