We are in the homestretch with our git workflow walkthrough. I knew we could do it! Last time, we looked at a few ways to review pull requests. In this final (for now!) installment, we will merge our reviewed changes back into
Once your pull request reviewer is satisfied with the changes, you’ll get the coveted
+1 (or equivalent affirmative emoji), which means it’s time to get this thing merged!
Additional suggestions, if you feel the scope is small enough, can be dealt with in a separate PR or added as another commit to the existing one. I typically like smaller PRs to bigger ones, so if I can justify splitting out additional suggestions into separate issues, I go that route. A good rule of thumb is to have one PR per issue.
If you are lucky, the PR can be auto-merged, and you can do it right inside GitHub with just a few clicks!
However, sometimes (and not often, honestly) the magic doesn’t quite work, and you need to return to the command line one final time for the merge.
Luckily, the instructions for getting started are right there and just a click away.
First, make sure you have the latest master in your local repo.
git checkout master git pull origin master
Then switch back to the feature branch and merge in master
git checkout docs git merge master
This should fail, and it should tell you which files you need to look at to resolve the conflict.
Here, I just have one file that needs attention:
After opening it up in my text editor, I look for the <<<< indicating a merge conflict.
I modify the code until all of the conflicts are dealt with.The top section, before the equals chain is what was on the remote master branch before your changes came in. The bottom section is your local stuff. Picking out what to keep is a decision only you can make – but I know you’ll make the right one.
Then I add the file to staging.
git add gruntfile.js
The rest of the merge is already in staging, so now I can commit the merge
git commit -m 'merged master'
Once all of the conflicts have been resolved and the commits are made, it’s good practice to double check that none of the conflicts resulted in broken code. This step is particularly important if someone was modifying the same area of code as your PR.
Now, we can switch back to master to merge this PR into the main master branch.
git checkout master git merge --no-ff docs git push origin master
This is more work than the auto-merge, but with small feature changes, this manual process is typically the exception to how merging works and not the rule.
An easier approach
Ok, so we went through how GitHub suggests you tackle the problem of merge conflicts. When talking through this process with my co-worker Yannick, he provided a slightly simpler process that he uses to get his pull requests into a mergeable state.
He makes sure the local
master is synced up with the remote one, then on the local branch used to generate the pull request, he just merges in the latest version of
git fetch origin master git checkout docs git merge master
This will cause the merge conflict, same as before. So deal with that as you see fit. Now, after the merging is done, we can push back up to the same
docs feature branch, and update our pull request with the merge already dealt with. This means we can use the GitHub functionality to merge it from the website!
The alternative process has the added benefit of being able to easily test your changes after the merge locally. This gives you greater confidence that the merge went as expected and everything is cool.
Delete remote branch
Either way, once the PR is merged into master, we can remove the remote branch to keep our GitHub project cleaned up.
You can also remove the remote branch via the command line by running:
git push origin :docs
: prefixing the name of the branch. The
: separates the name on your local repository from the name on the remote repository, so :docs means “push nothing to docs” which deletes it.
And we are done!
We’ve covered a lot of ground here. Now you have the full picture of the mighty Pull Request. You can make ‘em, and you can knock ‘em down!
Remember, these processes and workflows are all suggestions and tips rather than hard rules to help you communicate better with collaborators when building new things together. The technical details of the tools we use can obfuscate the fact that, at the end of the day, we are people just trying to communicate with other people in meaningful and effective ways.
With these tutorials, I’ve broken down some of that technical complexity to encourage users to do more with their existing tools and engage in these conversations with their collaborators. I hope these walkthroughs give you the confidence you need to start using feature branches and pull requests to take your Git collaboration skills to the next level.
We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.
How do you go about keeping a clean commit history? For instance, lets say I’m working on a photo gallery feature, and usually when working on a feature branch, you have commit messages such as \”Fixed typo\”, \”Added better documentation\”, etc. This commits mean nothing in the master branch commit history, what I would like to read in the master branch instead is \”User profile has photo gallery lightbox\”. What I like to do is to rebase the feature branch with the master branch and squash the commits into a single one which describes the goal of the feature branch. The only issue with doing this is that at the end I have to force push the feature branch, which \”destroys\” other teammates local branch. Do you have any suggestions for this situation?
Rebasing a branch before a merge is generally acceptable — If you had other collaborators working with you on it, just inform them ahead of time.
You also might want to look into the `git commit –fixup SHA` or `git commit –squash SHA` and `git rebase -i –autosquash` technique: http://fle.github.io/git-ti…
GitHub now has ability to squash and merge a PR with the green merge button, without having to force-push to the branch. So you can keep the commits in the PR and still have a single squashed commit merged to master. See https://help.github.com/en/…
If you want to create and manage your pull requests from the command line, the git-pull-request CLI tool is kinda great for that!
Can someone please explain why \”git merge master\” SHOULD FAIL?!
I would rather not use a workflow that depends on a certain step always failing…
I am also missing some explanation on how to – easily – apply the same changes (the new feature or bug-fix) to a non-master branch (for example a separate branch for a test-server)? I can figure out non-easy ways to do that, but am hoping that Git delivers a better way!