My solution is stored on GitHub and I'm using the built-in features of Visual Studio to check code in and out. Currently, I'm the only one working on my project. But I've started switching between different computers.

Every time I get to where both computers have pending changes, I am unable to continue.

I'm trying to push my changes on one computer and it gives me an error:

Unable to push the remote repository because your local branch is behind the remote branch. Update your branch by pulling before pushing.

[Pull then Push] [Pull] [Cancel]

If I select [Pull then Push], I get a different error.

The pull operation failed. See the Output window for details.

And the Output window shows the following.

Pushing master
Hint: You have divergent branches and need to specify how to reconcile them.
Hint: You can do so by running one of the following commands sometime before
Hint: your next pull:
Hint: 
Hint:   git config pull.rebase false  # merge
Hint:   git config pull.rebase true   # rebase
Hint:   git config pull.ff only       # fast-forward only
Hint: 
Hint: You can replace "git config" with "git config --global" to set a default
Hint: preference for all repositories. You can also pass --rebase, --no-rebase,
Hint: or --ff-only on the command line to override the configured default per
Hint: invocation.
Git failed with a fatal error.
Git failed with a fatal error.
Need to specify how to reconcile divergent branches.

Both systems show the current branch is master. I was expecting the changes to be merged so I'm not sure why this is a problem.

Is there any way to get Visual Studio to merge the changes and allow me to deal with any conflicts?

Note: I'm trying to read up on this but I am not using a command line for this. I would far prefer to just use the IDE. And it seems like it should support what I'm trying to do. What I've read seems to indicate I need to set the Rebase local branch when pulling setting, but I'm not sure what I should set it to or why.

CodePudding user response：

If you're on Visual Studio 2019 or above, you should be able to follow these instructions to set the git pull strategy for your project.

This answer gives a thorough explanation of the warning that you're seeing from Git. Basically, git wants you to set a configuration to tell it how to handle situations where you're attempting to update a remote branch that has diverged from your local branch. Setting it to False will give you the behavior that you're probably used to, but I prefer True personally.

Setting the configuration in Visual Studio (or at the command line, as suggested by git), will resolve the error. As for which option you should choose for the configuration, that's really up to you. But I'll give a brief overview of each option:

• "True: Rebase current branch on top of upstream branch after fetch."
  • Slightly more advanced option that's preferred by more experienced Git users. It will rewrite the history of your local branch to appear as if you made these changes after any changes on the upstream branch. This will give you a cleaner git history, if you care about that. The downside is that if you like to make many small commits locally, you may run into situations where you need to resolve merge conflicts on each individual commit rather than resolving all of your conflicts once.
• "False: Merge the current branch into the upstream branch."
  • The "default" option. It's what you and most devs expect to happen. It first creates a merge-commit on your branch locally, allows you to resolve any conflicts at once, regardless of how many commits you have locally that are not yet on the upstream branch, and then it pushes.
• "Unset (default): Unless specified in other configuration files, merge the current branch into the upstream branch."
  • The docs are outdated here: newer versions of git require that you have this config set. So this will not automatically use the default behavior unless you explicitly set it to False.
• "Interactive: Rebase in interactive mode."
  • Slightly more advanced version of True. Useful in the case where you tend to make a lot of small commits locally, since it will give you an opportunity to rewrite your local commit history.
• "Preserve: Rebase without flattening locally created merge commits."
  • Equivalent to rebasing with the merges option. You're unlikely to need this unless you commonly perform local merges.