Learning Version Control with GitHub

• Part 1: Why Use Version Control?
• Part 2: Using GitHub
• Part 3: Working with Repositories
• Part 4: Markdown and Code
• Part 5: Managing Repositories

---

Managing Repositories

This series started with reviewing version control. It moved into using GitHub and creating a repository through forking an existing project. In the last two parts, pulling and pushing changes was discussed, ending on changing the text of the README file through writing new markdown code.

Generally, interactions with GitHub consist of those common actions: forking an existing project; making changes and then pushing them to a repository; writing markdown in files; and having an understanding of how these processes and tasks related to each other.

In this section, three more advanced areas of functionality will be covered: issues, pull requests, and branches.

Issues

When a project is created (and not forked), it gets a tab on GitHub called Issues. This is an area where other members of the community who are not contributors on the project can submit problems and make suggestions.

Anyone with a GitHub account can make an issue on other projects (unless this functionality is turned off). Initially, an issue is a title and some content.

For projects which a user is an admin or was granted admin access, Issues can also be given an assignee (who on a team should work on or address this issue), labels (version, system, or other grouping), Project (if part of larger changes or functionality changes), and a Milestone (usually next version or release).

Just as any user can make an Issue, the admins of the project can also Close, Comment (reply), or choose to incorporate the issue through using labels, projects, and other details.

Pull Requests

All projects, even those forked from an original project, have a tab for Pull Requests. A pull request, as might be guessed from its name, is a request from another project to pull changes into the current project.

GitHub was created to work on open source projects and a common part of that philosophy is that others will help improve projects through contributing Issues and new code.

The Pull Request functionality works between projects that are forks (clones) of a project and its original or parent project. The “pull” goes from the new project back to the older or original one.

When creating a pull request using the website, GitHub will check the code to make sure the requests can happen. If so, it will mark it as “Able to merge” and present a button “Create a pull request” to continue in the process.

Creating Branches

Similar to pull requests is a functionality for creating branches. In Git and GitHub vocabulary, a branch is a separate collection of files created from the original in the same project. Think of it as forking within a single project.

Moving between branches in a project while looking at it on the GitHub website is as easy as clicking on “Branch” and choosing the branch to view.

Merging Branches

Just like a pull request can work across projects, branches can also be merged. When a branch has new changes that are not found in the parent branch, GitHub will show a notification that the branches can be merged together, syncing the original with the new changes in the different branch.