Writing and Committing Code in GitHub: Committing Code with GitHub Desktop

Even though committing from the terminal is pretty straightforward, many peo­ple prefer to use a GUI application to commit code. Using a GU has a few benefits:

» A GUI can provide guidance on conventions with commit messages, such as keeping the summary to 50 characters and separating it from the description by new lines. A GUI can simply present two fields: summary and description.

» A GUI can provide support for GitHub specific conventions, such as the one where you can specify that a commit resolves an issue.

GitHub Desktop (which we refer to as Desktop for short) is a GUI created by GitHub that is great for committing code.

1. Tracking a repository in Desktop

Choose a repository that you have never opened in Desktop, but that you have locally on your computer. (See Chapter 2 if you haven’t worked with Desktop yet.) If you need an example, use the best-example repository that you can create in the section “Creating a Repository,” earlier in this chapter. When you launch Desktop, the best-example repository isn’t listed in the list of repositories. Desk­top doesn’t scan your computer for Git repositories to manage. Instead, you have to tell Desktop about each repository you want to manage.

As expected, if you use Desktop to clone or create the repository, it’s already tracking it. But sometimes you have a repository that you cloned or created out­side of Desktop — for example, we created best-example using the terminal. Now you need to tell Desktop to track the repository you have chosen. Fortunately, this task is easy from the terminal.

The Desktop command line tool allows you to launch Desktop from your terminal, which allows you to easily integrate Desktop as much or as little as you want into your existing terminal-based Git workflow.

On Windows, you don’t need to install the command line tool; it’s done automati­cally. On the Mac, you have to take a separate step.

To install the command line tool on a Mac:

  1. Make sure Desktop is the active application and then, in the application menu bar, choose GitHub Desktop o Install Command Line Tool.
  2. From the terminal, make sure that you’re in the repository you want Desktop to track.

For this example, we are in the best-example.

  1. Run the following command:

$ github .

The . in the command represents the current directory. It could, instead, be a fully qualified path to a directory.

GitHub Desktop launches (if it’s not already running) and opens the specified directory. Because the current directory is already a Git repository, Desktop adds it to the list of repositories that it tracks. It then sets this repository as the current repository so that you can browse the repository’s history, switch branches, and create commits, as shown in Figure 7-3.

If the current directory wasn’t a repository, Desktop prompts you to create a Git repository in that directory. How convenient!

2. Publishing a repository in Desktop

To experience the full power of Desktop’s integration with GitHub, you need to publish this repository to GitHub:

  1. Clicking the Publish repository button.

A dialog box to publish the repository appears (see Figure 7-4).

  1. Fill in the details and click the Publish Repository button.

The repository is created on your GitHub.com account.

Desktop provides a keyboard shortcut to open the browser to the repository: ^ + Shift + G (Ctrl+Shift+G on Windows).

If you want, you can create a few issues in the repository. (see Chapter 3 to find out how to create issues.) For this example, we create five issues:

» Provide more details on the README.

» Mention in the README that this is a collaborative efforts.

» Add a contribution section to README.

» Do not use an alert message.

» Set up website alerts.

You can also see these issues on our repo at https://github.com/FakeHaacked/ best-example/issues.

3. Committing in Desktop

Desktop is used only for Git operations. To edit the files in the repository, you still need to use your editor of choice.

Make some changes so you have something to commit. In the example for this chapter, you can make some changes to index.html shown in bold.

<!doctype html>

<html lang=”en”>

<head>

<meta charset=”utf-8″>

<title>The Best Example</title>

<script src=”js/script.js”></script>

</head>

<body>

<h1>The Best Cod3z!</h1>

<div id=”message”></div>

</body>

</html>

Update script.js to populate the new DIV element, like civilized people would, rather than pop up an alert message. Changes are in bold:

document.addEventListener(

“DOMContentLoaded”, function(event) {

var message = document.getElementByld(‘message’)

message.innerText = ‘The script ran!’

}

);

Switch back to Desktop and click the Changes tab, shown in Figure 7-5.

The left pane lists the set of changed files. If you select a file, you can see the spe­cific changes to that file in the right pane, which is called the diff view.

You can commit all the changes as a single commit, but sometimes you will have unrelated changes. In this example, we have two unrelated changes:

» The change to the title in index.html

» The message changes to both index.html and script.js

Each of these changes should be in their own commit. How do we do that when index.html contains two unrelated changes? Fortunately, Desktop provides a nice way to commit a portion of the changes in a file. This process is known as a partial commit:

  1. Deselect all changes.

In the left pane, uncheck the check box next to the label 2 changed files to deselect all changes.

  1. Select index.html in the left pane.

Click the filename in the left pane to display the changes for index.html.

  1. Select the title changes.

In the diff view, click the line numbers in the gutter to select the changes you want to keep. To select a whole code block, click the thin line just to the right of the line number. Select the code block next to line 5 by clicking on the thin line next to line 5. After you select the code block, both lines labeled line 5 should be selected (selected lines show up as blue), as shown in Figure 7-6.

You may be confused about why two lines are labeled 5 in the diff view. The numbers on the left represent what the file was originally named before you made the changes. The lines on the right represent the lines of the changed lines. Because we changed line 5, it’s listed twice. Line 10 is a new line that didn’t exist before, so it is listed only on the right.

  1. With those lines selected, enter a commit message and then click the Commit to master button.

As you can see in the bottom left portion of Figure 7-6, Desktop provides two fields for commit messages. Go ahead and enter “Change the title” into the summary and click the Commit to master button.

Notice that the diff view updates to have the change only on line 10 (see Figure 7-7). That’s because we committed the change on line 5.

If you’re following the example in this chapter, make sure all the remaining changes are selected by clicking the check box next to the label 2 changed files until the check box is selected.

Source: Guthals Sarah, Haack Phil (2019), GitHub for Dummies, Wiley.

Leave a Reply

Your email address will not be published. Required fields are marked *