Getting Started with Git

So far, you’ve covered the basics of how to use Git with the GitHub Desktop app. It can help to know a little bit about how Git works and what the GitHub Desktop app is doing on your behalf.

In the recipes-book example, it’s pretty simple in nature. But in real-world development, you’re often working on many things at once, and your local working area has many different changes, but only some are for the feature you’re building.

For example, let’s say you start creating a new recipe for your book.

Create a new branch titled “brisket-recipe.” Select “Branch,” then “New branch.” Name the branch “brisket-recipe” and click “Create branch.”

You start adding the steps for brisket.

Create a new file titled “brisket.txt,” and I’ll copy and paste some make-believe recipe.

Before you commit this change, your manager is reviewing the book, and she says, “It would be really helpful if you can add a little more to the assemble tacos step.”

So you open the “carnitas-tacos.txt” and replace the assemble tacos with additional info.

Next, she says, “Can you add when the pork shoulder should be done?” So you add more information on that line. Just like that, you have three different workstreams for your book. In the real world, these could have been you investigating various bug fixes in subsystem A while you’re working on the new features to subsystem B. Either way, you wouldn’t want to commit all three of these changes to one branch and make one single pull request. These changes would not be related to each other, and it’s often much easier for the reviewer of your code to review changes that are related to one single task. Otherwise, you’ll run into the problem where the pull request is so big, and you’re not getting a proper code review because the reviewer just wants to get their work done, so they might not look closely at all of your changes. Or more commonly, they’ll ask you to break the pull request into smaller, more related chunks.

This is where the staging area comes in handy. You only add the changes you want in your commit to the staging area. Any other changes can be left in your working directory and not committed.

In the GitHub Desktop app, both files are selected for the commit. First, deselect the new “brisket-recipe.txt” file. This removes that file from the staging area so it will not be committed.

Next, look at the “carnitas-tacos.txt” file. Notice how there are two changes here. Let’s say we want to commit each of these changes separately because each of these were a separate bugfix. You can do that by selecting the blue in the margin here. This removes that change from the staging area, and only changes that are staged make it into the commit. Your changes are still in the file if you switch back to your text editor, but the change won’t be in the commit.

Ideally, we’d want these also to be on separate branches so we could make separate pull requests to be reviewed by our team. You can do the pull requests on your own, but we’ll show how to separate these three changes into three separate commits on different branches.

Go to branch, new branch. Name the branch, assemble-tacos-fix. Now git asks you what you want to do with the other changes. I’ll bring the changes with me onto the new branch. We won’t commit all of the changes just yet, just the ones in the staging area. Select Switch Branch.

Add a commit message: “Added additional info to assemble tacos step.”

If you look at the changes tab again, you can see your changs are still there because we brought them with us onto the branch. You might also notice the changes are not in the staging area to be committed.

Next, you want to repeat these steps for the done temperature of the carnitas tacos recipe. You can check the carnitas-tacos.txt file to add that to the staging area. Next, select branch, new branch. Name the branch “carnitas-done-temp-fix.” Select Create Branch. In the next dialogue, select to bring your changes with you to the new branch. On this new branch, make sure to only have the single carnitas-tacos change selected. Then add the commit message, “added done temp for carnitas.” Commit that change.

You’ll repeat the steps one more time for the original feature you were working on. Switch back to the original brisket-recipe branch. Add the commit message, “added brisket recipe” and commit that change. Now you can see that you have three separate changes all on three separate branches. You did this by leveraging the staging area in Git to take a working directory where you had multiple changes and separated each of those changes out into their individual workstreams.