Merging a Pull Request4:20 with Jay McGavren
Once a pull request has passed review, it's time to merge it into your repo's primary branch.
GitHub has created a web app that's integrated with their platform called GitHub Learning Lab. It's a series of tutorials that will walk you through various operations on GitHub, including using branches to set up a GitHub Pages site for your project, and resolving merge conflicts in a pull request.
The excellent Pro Git book by Scott Chacon has a chapter dedicated to branches and merging. It's available to read online for free.
It can sometimes take hours or even days to get a poll request review. 0:00 During that time, others have probably been making changes to the repo's master 0:04 branch, changes that might conflict with yours. 0:08 You don't wanna be surprised by these changes when you merge your topic 0:12 branch into master. 0:15 So first, it's a good idea to merge master into your branch. 0:16 If there are no conflicts, GitHub lets you merge master into your branch at the click 0:21 of a button, but it looks like we have a conflict here. 0:25 So we'll need to fix it from the command line. 0:29 So we'll go to our git repo on our computer. 0:32 And first we need to update the master branch with any changes from 0:34 the remote repo. 0:38 So first, we're going to checkout the master branch, git checkout master. 0:39 Then we fetch changes and merge them into master with git pull. 0:44 There are no changes in this case, but 0:49 if there had been, this would ensure that we incorporate them. 0:50 Now, we need to merge the changes for master into our topic branch, so 0:54 that we can resolve any conflicts. 0:58 We check out the topic branch with git checkout add-letters and 1:00 we merge the changes from master end of the topic branch, git merge master. 1:05 Looks like there's a conflict to fix. 1:11 Let's take care of that real quick. 1:13 So it looks like we have some changes both on the add letters branch and 1:16 on the master's branch. 1:20 We're going to go ahead and keep both sets of changes in this case. 1:22 I don't see any problems with them. 1:25 So we'll save this and stage it, 1:29 git add decoder.rb, which will mark the conflicts as resolved. 1:33 And then we'll commit it, with just git commit. 1:38 I won't use -m, so that it uses the default message. 1:42 I don't wanna change this message at all, so I'm just gonna exit 1:46 without making any changes, and that completes the merge commit. 1:50 As always, if you're merging code for an app, you should run your unit test suite 1:54 and compile the app to make sure nothing is broken. 1:58 Ruby test_decoder.rb, looks like all our unit tests are passing. 2:00 Now, that your pull request has been reviewed and 2:06 you've resolved any conflicts, it should be safe to merge your branch into master. 2:08 Again, GitHub offers a shortcut button for this, but we'll show you how to do 2:13 it from the Command line, so you understand what the button does. 2:17 So start by checking out the master branch, git checkout master. 2:21 And we'll check for changes to master one more time, just in case, git pull. 2:25 If it shows further changes, you'll need to repeat the process of merging master 2:31 into your topic branch, but it hasn't been very long, so it probably won't. 2:35 And now, you merge your topic branch into your master branch, git merge add-letters. 2:39 Because we just recently merged master into our topic branch, 2:45 it's able to merge by fast-forwarding. 2:48 Now, you should be able to push your master branch, git push. 2:51 If you refresh the pull request page, you'll see that the changes have been 2:59 merged into master, the same as if you'd pushed GitHub's shortcut button. 3:03 Now, you can safely clean everything up. 3:08 You can click the button to Close pull request. 3:10 You can also click the button to delete the branch of the GitHub repository, 3:13 since it won't be needed anymore. 3:17 And since the changes from your local branch have all been merged in a master, 3:21 you can delete that as well, git branch -d add letters. 3:25 You're still not quite done yet. 3:32 Now it's time to release your software. 3:33 For most projects, the master branch represents what's deployed to production. 3:36 If you're working on a web app, that means the latest version on master is what 3:40 should be set up on the web server for people to use. 3:44 If you're making an app that people install to their computers or phones, 3:47 the latest version of master should be compiled, and 3:50 made available on a server for people to download. 3:53 Most teams choose to write scripts that will automatically pull code from 3:56 the master branch and deploy it for you. 3:59 If you're working on a project that has such a script, 4:01 now would be the time to run it. 4:04 But that's another project to complete using other tools. 4:06 For now, give yourself a pat on the back, 4:09 because you've mastered an important concept Git branches. 4:11 You now know everything you need to be a productive collaborator on Git repos. 4:15
You need to sign up for Treehouse in order to download course files.Sign up