In this guide we finish up the data flow set of features, update the project management dashboard and merge the feature branch into the master branch on GitHub.

With our custom action fully built out we can click that task as completed and now we have finished all 6 of the 6 tasks. We can click on Finish, Deliver, and Accept to close out this item and be ready for the next step. You can see in our Icebox that we are going to discuss Data Management in the next section. However, before we move on we need to go to GitHub so we can merge in our feature branch.

Merging a Branch on GitHub

This time I will do the merging right here in GitHub. This way can get in the habit of merging in the branch, and I also like the visuals provided here on GitHub.

If you click on the branches tab (just to the right of the commits tab).

You can see portfolio-feature. This shows that it is 12 commits ahead of the master branch. If you remember back to our deep dive into git this means, we have performed 12 different code pushes since we have updated our master branch.

First, click on a button called "New Pull Request". Let’s add some content that indicates what we implemented on this branch. As a frame of reference, if you scroll down a bit, you can see the different commit messages you made.

- Updated the app to have sample data
- Implemented the full CRUD functionality for portfolio items
- Added buttons for CRUD
- Implemented custom routes
- Implemented custom actions

You can indicate the broad functionality created, instead of listing every commit messages. For example, on one commit we implemented the new and create action, on another we built edit and update. We can sum this up with CRUD functionality.

Why Comments are Beneficial

The reason I wanted to go thru and show you myself typing this list out, which may or may not be needed for an App of this size, is that these comments are actually really important. For example, imagine you're working on a project with several other developers, and you are working for a Senior developer. Whenever you send them a pull request, you do not want to have to force them to go through and look at every single one of your commits just to have an idea of what your feature should do. The comments should explain and be a nice, concise summary of the items you would like to merge in with master.

This isn't a big deal when you are working on your own projects, but I wanted to show you this how you can be in the practice of doing this when working with teams.

Click on the button called "Create pull request", and will will show my comments which summarize what I have built along with each commit message.

As you scroll down, you'll see a message - "This branch has no conflicts".

So, click on "Merge pull request" and then “Confirm merge". This will merge all your code.

Deleting Merged Branches

Typically, in a production environment, once you do the merge, you'll want to delete the branch because in large projects, the number of branches can add up quickly. For example, imagine you were working on a really large application, that took two years to build out completely, and you are managing it. If that was the case and you didn’t delete your branch, you would have hundreds of branches to handle and that would become a bit unwieldy. This is why it's a good idea to delete a branch after you merge it with the master.

I'm not going to delete the branches in this course because at the end of each video, I give you a link that shows the code at that particular stage. So, you can follow along and check the code.

If I delete the branches, it would break all those links and it would take you a lot time to locate a specific commit. So I am going to leave the branches there.

For your own practice, you can delete the branch because after you’ve merged it into master, the master branch will have all your changes. To test this out, check our db/schema.rb file and you should be able to see the blog has a status attribute, we have our friendly ids, our portfolio is there, so we are good to go!

Next, we'll go into the deep dive section where we will analyze the Rails routing engine.

Resources

• Source Code