« Previous Tutorial Next Tutorial »

Welcome back! We’re getting close to a point where we can start actually talking about React, which seems like a good thing for a tutorial series named Five Minute React, but there’s a few final things we need to do before we can get to setting up our front-end. First and foremost, we need to clean out all the test crap we’ve littered our application with, because we don’t really want something called “testJSON” lying around in a finished app. Then we need to talk a little bit about git branches and how we want to handle committing our changes.

So, real quick, open /routes/index.js, which should look like this:

const express = require('express');
const router = express.Router();

/* GET home page. */
router.get('/', (req, res, next) => {
res.render('index', { title: 'MusicList Alpha' });
});

const testJSON = [
{
name: 'John Smith',
username: 'CaptainCode'
},
{
name: 'Jane Doe',
username: 'JaneyCakes'
}
];

router.get('/sendjson', (req, res, next) => {
res.json(testJSON)
});

module.exports = router;

And delete lines 9 through 23, getting rid of our testing stuff. The final file should look like this:

const express = require('express');
const router = express.Router();

/* GET home page. */
router.get('/', (req, res, next) => {
res.render('index', { title: 'MusicList Alpha' });
});

module.exports = router;

Then open /routes/api/index.js, which should look like this:

const express = require('express');
const router = express.Router();

router.get('/', (req, res, next) => {
res.json({ text: 'MusicList API Test' });
});

module.exports = router;

And delete lines 4 through 6, leaving you with an extremely barebones file that looks like this:

const express = require('express');
const router = express.Router();

module.exports = router;

That should do it for cleanup, unless you still have that test.html file sitting in your top level directory. If so, delete that, too! All right, we’re looking good. Before we make any further code changes, let’s commit our code to our repository. We can do this by switching to a terminal or command prompt, changing to our musiclist directory, and typing the following:

git status

This shows us a list of files that’ve been changed or added. There are a bunch! We haven’t done any committing since we got the repo set up. In future tutorials, I’m going to remind you to add files and commit them, but won’t walk you through it each time. For now, though, let’s go step-by-step.

If we were to commit and push right now, we’d be sending code to our master branch, which isn’t a great idea for long term development. Master is the top level of the repo, from which one would typically deploy to production, and you don’t want to be in a situation where you push broken code to production!

Git branching, merging, and resolving conflicts is an essential skill for a developer, and one that’s sort of like the ancient Chinese game, Go … easy to learn, difficult to master. We’re going to cover the basics here, which should be fine since you’re just one developer working on one fairly small project. Right now, think of our repo as a single line of code commits. Like this:

Git Single Branch

When you make a branch, you are splitting off from a certain point in the code, and then continuing to develop, like this:

Git Multiple Branches

The “problem” (which is, in truth, an incredibly useful feature) is that other people—or even you—can switch back and forth between the two branches and continue to write code, thus causing them to diverge. Potentially a lot.

That’s OK! Divergence is not an issue. Git has many tools built in to handle that divergence when the time comes that you want to merge the two branches back together. What is an issue, sometimes, is code conflicts. These most frequently happen when a file has been changed in both branches, and especially if the same lines of the file have changed in both branches, which leads to git having no idea which changes it should take. So, when you do merge branches, there are basically two possibilities. This one:

Git Merging - Good (Git auto-merges everything, nothing breaks, angelic music pours forth from the heavens)

Or this one:

Git Merging - Not So Good (Git fails to auto-merge, code conflicts abound, the wails and laments of the damned fill your office)

In the latter case, you’re stuck manually merging code. It’s not the worst thing ever, trust me, and there are several tools out there that can really help. Getting into manual conflict resolution would take this tutorial well over five minutes, so we’ll save it for another time. We’re not going to be merging anything right now.

So let’s switch to a “develop” branch, which we will then periodically merge into master. This is unlikely to ever create conflicts, because we’re not going to be writing separate code in Master. We could go even further and create sub-branches off of develop for individual features we’re adding—and I’ll show you how to do that when we get further along—but to keep things simple, we’ll stick with just one branch for now.

First type:

git branch develop

which will create the new branch, based off of master. Note that if we’d been working in a different branch, our new branch would be based off of that branch, not off of master. At any time you can type:

git branch

to get a list of branches you’ve initialized on your machine. You’ll see that though we created “develop” we’re still in master, so let’s switch by typing:

git checkout develop

Now we want to tell our repo to start tracking this branch. To do this, we can use git push, albeit with some additional information. Type this:

git push -u origin develop

Which is basically saying “push this branch upstream to origin, creating a new branch called develop with which to track any future changes” … origin is an auto-generated alias for our repo so we don’t have to type the URL all the time. So, we’re good. We’ve created develop and told our repo to start tracking it. Now let’s prep all those files we changed to be committed by typing:

git add -A

And then bundle them up in a commit like this:

git commit -m "Initial Express scaffolding"

Reminder that committing packages up your changes into a bundle, but does not send the bundle to your repository. To do that, you have to push the commits with:

git push

There we go. Now our repo has our latest changes, stored in the develop branch. Let’s take a look at the repo on the web, real quick. See how master shows none of our changes? That’s because the last time we pushed to that branch was before we even installed Express. But if we switch to “develop” by using the dropdown in the upper left, we can see all of our express scaffolding, because we just committed it. All right, we’re all set here. In future tutorials when I mention committing your changes, just remember the three commands you’ll need:

git add -A
git commit -m "commit summary"
git push

And you’ll be all set. Next up, we’ll tackle data modeling. We’ll do that using a module called Mongoose, which is going to make our lives a lot easier. Until then!

« Previous Tutorial Next Tutorial »