14 Essential GitHub Interview Questions *

By default, master is the main branch. Historically, the gh-pages branch was also treated specially, but not any more.

Any branch can be made the main branch in a repository. All that’s special about the main branch is that it is the default one that will be checked out when a repository is cloned, and the default one where pull requests will be sent.

To keep branches tidy you can delete the ones that are entirely merged into the default branch on the Branches settings page.

Using the Squash and merge option is a good way to preserve a tidy main branch history. Atomic commits are often useful when developing a feature or fixing a bug, but are not always necessary when merging the finished work into the main branch. However, one should really only use Squash and merge when the work being pulled forms a truly cohesive whole.

The Rebase and merge option is also good for a tidy commit history, as some maintainers want to preserve atomic commits made while building a feature, but find merge commits noisy or otherwise unsightly. However, after a Rebase and merge, it may be problematic to merge in any further work done in the feature branch. This may not be a problem, as one can always simply start a new feature bug-fix branch if any issues arise in the merged code.

When in doubt, Create a merge commit is always a fine, safe option. Though it creates an additional commit that some may see as unnecessary, the atomic commits and their hashes will be preserved from the branch.

You can use a personal access token. You should use a unique, well-documented token for each script so that they can be revoked and regenerated separately, if necessary.

GitHub provides APIs with REST and GraphQL layouts.

The need in this question could be met simply by polling either of those APIs, but a proper implementation should use GitHub’s webhooks to trigger an action at some endpoint in your system.

There are two parts to this:

1. Each machine that you use GitHub from will have access to a private key that is connected to your account.
2. GitHub uses the commit’s email address, which is set either on a local repository level, or globally across repositories on a given machine.

Some benefits are:

• It’s free!
• Quick and easy to set up.
• Service is stable and responsive.
• Generous (though not unlimited) limits on usage that make it great for open-source, not-for-profit, or prototype projects.

Limitations include:

• No server-side computation. (This is a limitation but not a strict downside as it enforces separation of concerns for your truly static assets.)
• No control over caching, authorization, or any other HTTP headers
• Various soft limitations that make it potentially unsuitable for commercial applications.

The options are Accept, Comment, or Request Changes. The way these options are used is specific to an organization’s agreed-upon procedures, but generally speaking:

• Comment is for when more discussion is needed or there is no explicit verdict. It’s there to leave unresolved feedback.
• Accept means that there are no changes needed, or only minimal changes that do not require further review.
• Request Changes is generally meant to signify that there are changes needed in order to accept the commit, and that the review should be resubmitted after those changes are made.

For more information, see GitHub’s “Reviewing proposed changes in a pull request” help document.

There are a range of answers that could be provided here, but the answer should definitely mention issues. Issues are for more than bug reports. Developers can use issues to track and share progress on individual units of work. Discussion on those units can happen asynchronously within the issues as well. The client should know that the work will be specified in these issues, and what the expectations around communication should be within the issues.

Additionally, the answer could mention the strengths and weaknesses of each of the projects and milestones features.

A project can be used to plan out and prioritize the work to be done in a given iteration, potentially across repositories.

A milestone can be used to group and prioritize related issues within a given repository. An advantage of milestones is the ability to set expected dates, though projects provide organization and tracking of issues by status. An interviewee may also mention other tools that integrate with GitHub, such as ZenHub, which add features like velocity tracking.

Note that some project owners have differing opinions about whether clients should be invited into the actual internal development planning and tracking tools, or whether there should always be some intermediate project planning communication tools that don’t go into technical detail. That disagreement is okay. This question is meant to serve both as a thought exercise, and to elicit the interviewee’s feelings toward the matter.

The main reasons are around team size or administrative flexibility. You can have collaborators on your personal private repositories, but only up to a certain number of collaborators.

Beyond that amount, you have to upgrade your account. However, a personal account upgraded to have unlimited collaborators is still cheaper than an organizational account.

One of the primary advantages of an organizational account is that you have more fine-grained control over repository access and account security.

Also important is that you can share the administrative burden: For personal repositories, only the owner may alter the repository settings. Organizations can be configured for other team members to be administrators as well.

There are a number of approaches here, but worthwhile candidates will at least mention setting up two-factor authentication (2FA). The candidate may also note that 2FA can be configured as a requirement for organizational collaborators as well.

Other things that may be mentioned are:

• Getting rid of unused key pairs for your account
• Ensuring the security of machines that have key pair access to your account
• Minimizing and regularly reviewing the access tokens and deploy keys connected to your account

GitHub has a number of recommendations as well.

Mention Closes #... anywhere in the commit message, where ... is replaced by the issue number within the repository. If the issue is in a different repository than the commit is being made to, use Closes username/repository#... in the commit message.

Any time a user refers to an issue from a commit message, GitHub links to the commit directly from the issue it mentions. Using mentions can be useful as a way of building an easily traversable “paper trail” of related or affected commits.

There are a variety of answers that could be given here, but some things that should probably be mentioned:

• Git Flow is organized around releases, where there is potentially a significant amount of work in development at any given time that hasn’t been approved for production. On the other hand, GitHub Flow assumes that the main branch is always ready for deployment.
• In GitHub Flow, there is no strict separation between your main branch and your development branch. This makes things like hotfixes redundant, because a hotfix branch is just another branch off main.
• Good development practices around code review and automated testing should be followed regardless of branching pattern but are of particular importance when adopting GitHub Flow. This is because they increase confidence that a particular change won’t wreak havoc on the production branch. GitHub helps with this by encouraging developer adoption of these good practices in two ways: It makes branching and pull request discussions easy and transparent to project participants, and it incorporates continuous integration tools into pull requests.
• Using GitHub does not require the use of the GitHub Flow workflow, nor does it prohibit Git Flow, or any other branching workflow.

You can add collaborators from outside of your organization directly to a repository.

However, it may be better to create teams, as you can administer membership in teams separately from team repository access. Team members are added as members of your organization, so it is important to think carefully about access privileges across the organization overall. For example, in the Member privileges settings, you may want to change the base permissions for an organization member to None, and then add relevant teams to each repository as needed.

Github provides issue templates for repository or organization managers to lay out a specific structure that should be followed when someone submits an issue.

Other things that may help:

• Contributor guidelines
• Generally coherent documentation about where contributions are needed and how they should be made

But often nothing is as good as someone who is familiar with the project and the practices walking a new contributor through the process.