Welcome to today’s blog.
Today I will show you how, using Git bash you can resolve a common problem that may occur while using Git for Visual Studio 2017 plugin.
I will show you how to deal with the “Merge in Progress” message that so often pops-up after you have opened the Team Explorer tab in VS 2017 to view outstanding changes to your current branch.
Below is an example of the error I get during when attempting a merge from the Git plugin within VS 2017:
Open Git bash console.
Change to the source folder you are attempting to merge source.
You wills see the folder showing a merging state and source files yet to be committed:
On scrolling down further you will see the following source files that are modified and not staged for commit:
In VS 2017, the corresponding files will be the project source changes that are un-staged:
Running the following command will commit all staged and un-staged changes within the local git repo:
git add -A
You will notice the un staged files are now staged.
Note: The following command will all achieve the same goal as staging all files for commit:
git add --all
Returning back to the VS IDE and you will see there are no more un-staged files, they have all been staged for a commit.
Now go back to Bash and enter the following git command to commit the staged changes:
git commit -m "Claims authorisation handling additions. Error handling additions."
Note also that the following git commands achieve the same goal:
git coa -m "some message"
git commit -A -m "some message"
Once the commit has been run, the folder will show the “merging” status has gone from the source folder:
Notice the “MERGING” label has gone from the Git source folder.
Check Team Explorer in CS IDE and there are no longer any staged files, they have been committed!
Now sync changes to the repository.
To apply a sync (or push) to the remote repository, run the command:
git push --set-upstream origin claims_identity_feature
In VS 2017 Team Explorer, in Synchronization, you will notice there are no longer any outgoing commits:
Check GitHub (the remote) repository that the branch has been pushed remotely:
Expanding the master branch, verify the new branch has been created within your repository:
As a last task, within the new branch, check the timestamp of the files that have been pushed to your remote repository.
After checking in the branch, you may wish to merge the changes from the feature branch into the master branch. This was discussed my previous blog on merging in Git.
That’s all for this post.
I hope you found it useful.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.