Merging and Creating a Pull Request

Merging and Creating a Pull Request

As you add new features or make updates to Framework or Foundation, there is a chance others will be working on the branch you originally cloned from to make your branch, and it will fall behind. To fix this, you'll need to merge the new changes into your branch.

Update your local copy of the original branch

In Tower, checkout the original branch you cloned (usually develop or master), then click "Pull" to get all the changes from Github. You'll want to use Merge (do not check the item that asks if you want to rebase instead).

What's the difference between rebasing and merging? Rebasing is useful when you need to blow away all your local changes to a branch because something really went wrong. A merge lets you keep any local changes you might have, and in general is what you'll want to choose. In this case, it probably doesn't matter anyway, since you're working in your own branch and you probably don't have any commits to the branch you're updating.

Merge the new changes into your branch

In Tower, make sure you've checked out the branch you're working on, and then click on the "Merge" button at the top. Select develop and leave the "Squash commits" and "Always generate merge commit" checkboxes unchecked.

Afterwards, you'll see a warning icon next to Working Copy. Clicking on this, you'll see what files have merge conflicts, if any.

Resolving merge conflicts

Some merge conflicts can be resolved automatically by Tower. You may also be able to use Kaliedoscope to resolve a merge conflict piece by piece, comparing your chunk of code to the new chunk of code and picking one to discard. For the very hairy problems, you can manually resolve merge conflicts in your favorite text editor.

At each conflict, if you open the file in a text editor, you will see conflict resolution markers. They will show your changes first, a marker to divide the chunks of code, and then the changes from the branch your merging into your branch, like so:

<<<<<<< HEAD

(your code)

=======

(the branch you're merging's code)

>>>>>>> (branch name)

You'll see this pattern multiple times. Each HEAD to (branch name) is one conflict that you need to resolve.

To resolve a conflict, it's important to know the original intent of both your code and the code you're merging so you can edit and update the code appropriately. In some cases, you can choose an entire block of code to get rid of. In others, you'll need to figure out which direction the code needs to take based on everyone's intent, and pick and choose the lines to keep or toss.

This is a big part of why your commit messages - especially on projects with multiple people - are crucial. With a good commit description, you can tell a developer's original intent, and make merging much easier.

In the case they didn't do that, feel free to go to their desk and make them answer all your questions until you know exactly what they did and why with each commit.

Once you've resolved all conflicts, if you've done so manually, select "Use modified file" in Tower to resolve the conflict and commit and push your changes.

Creating a Pull Request

A pull request is a request for someone to review a set of changes you made for possible integration into a project - to merge your branch into the branch you're requesting to change. Once you've resolved any conflicts, updated, and pushed, you're ready to create your pull request.

• Go to your branch's URL and look for the little green icon that says "Pull Request"
• Since you've brought your branch up to date, it will be able to merge automatically. If it didn't, you'd want to go back and update so that it can. Don't make another developer resolve your merge conflicts!
• Set "base" to the branch you're requesting to update.
• Click "Create Pull Request"

So a pull request comes with a title and a description Write a short summary of the change in title Write a good description of what the branch changes, and why we did it in description You'll notice that you can actually see all of your commits in the PR screen If you click on "Files" you can also see all of the files that are changing All of this combined makes this an ideal way for us to review changes For extra awesome, we can comment on the PR, which is good for discussion (You can even comment on specific lines in the files) So go ahead and create it. If the pull request is for a child theme, send a review request to #code-reviews in Slack if you are a BU WebTeam member. If you are an outside contributor working on Responsive Framework or Foundation, request a review from Ashley Kolodziej, who will facilitate getting your pull request reviewed.