So, you’re a developer or coordinator on a codeplex project. And while you where working on some brilliant new feature, another developer tumbled over a minor glitch in your code. Since he read my previous post on how to contribute to a codeplex project that’s on Git, he will fix the bug and send you a pull request.
But then what? Well, you will have to review what he’s done, and either accept or decline the pull request. Since Codeplex itself has some pretty decent document on Applying Pull Requests, I’ll just point you there.
You just go right ahead and read that, while I listen to some intermission.
Alright, good to have you back. So, when I go back to NB_Store on Codeplex, I’ll see what I got from my last post: An accpeted pullrequest:
When I accepted the pull request, codeplex already mentioned that I wasn’t done yet:
Note: Accepting this pull request will not merge the changes. You will need to do this manually by running the following commands locally:
1. Pull the changes into your local repository. We recommend that you create a new branch to test out the changes first.
- git checkout -b superska/nbstore master
- git pull https://git01.codeplex.com/forks/superska/nbstore backoffe-lowercase-url
2. If you’re satisfied, merge the changes and push them back to your repository on CodePlex.
- git checkout master
- git merge superska/nbstore
- git push origin master
But, to be honoust, I’m not really into those git command line things. So, let’s see what we need to do with TortoiseGit.
Switching to the master
To be able to merge my changes in, I need to make sure I’m merging the changes in the right version of the code. So now, I need to forget about the origin repository for a while and make sure I’m working the master branch of NB_Store itself.
Please note that normally, the person sending the Pull request, will probably not be same one merging the changes in. But it doesn’t really matter from which repository you are switching. It just matters that you’re switch to the right one.
Since I was working on a fork of NB_Store, the assumption is, I can’t work directly on NB_Store. Which makes sense, because if I could, I wouldn’t need to fork it. Unless of course, I’m writing a blogpost about that process and… oh well, you get the point. So what I need to do now to get my working folder linked to the master branch of NB_Store itself, is of course clone it in 3 simp[le steps.
To be able to easily switch to using my fork again later on, I just renamed my original folder. Since all the Git information is stored inside it, this works brilliantly. I’ll just rename it back later on. To clone the NB_Store master branch…
Wait a bit ‘till everything’s downloaded and we’re done.
Pulling in the changes
Next task is to pull in the changes this “superska” guy sent me in his pull request. Since CodePlez already allowed me to view the changes in the pull request, I’m perfectly fine pulling them right in the master branch.
If I wasn’t, I’d just create a feature branch for it, pull the changes there, test them and later on, merge that branch back into master.
But now, I use TortoiseGit—> Pull to pull in the changes from the request:
The status window gives me a button “Pulled Diff” to review the changes once again. Now I should test the code and make sure I want to
Merge that new stuff in!
To merge the new code into the NB_Store master branch, I need to chackout that master branch again first: TortoiseGit, Switch/Checkout, chose branch “remotes/origin/master”.
To merge the changes in, chose TortoiseGit, Merge. Select the Commit radio button in the dialog.:
The only way I found to get a hold on that changeset SHA-1 key, is to go to NB_Store on codeplex, go to Source Code, Pull Requests, and take it from the URL here:
The master demands commitment
The merge is already committed to my local repository, so I didn’t see the red icons I expected at first. Since it’s committed locally, I need to push it to origin/master (because I’m working on the NB_Store project now, and not on a fork, origin is now nb_store/master):
And since the proof of the pudding is always in the eating:
Hope this helps understanding (and working with) git a bit. I know it helped me to figure things out.