Working with GitHub: Accounts, Plans, the GitHub Flow, Markdown, Desktop and Mobile (GitHub Foundations GH-900)

GitHub has three types of account. A personal account (also called a user account) is the identity a person signs in with; an organization account is a shared account that owns repositories for a group; and an enterprise account sits above organizations so one company can manage policy and billing for many of them in one place.

The key consequence of an organization is ownership that does not depend on one person. If a group's repositories live in one member's personal account, that person controls them and can leave with them; other people can only be added as collaborators to individual repositories. Moving the work into an organization means the organization owns it, several people can be owners, and access is managed through teams.

Nobody shares a login on GitHub. A shared "team login" or a shared machine user for people to work through defeats per-person accountability; machine users exist for automation, not for humans.

GitHub recommends that each person keeps one personal account for everything they do on GitHub, open source and paid work alike, and it provides a way to merge extra personal accounts. Access to an employer's code comes from being added to the employer's organization, not from a separate work account.

This works because membership is something that can be granted and removed without touching the account itself:

• Joining an employer: an organization owner invites your existing personal account; once you accept, you get access to whatever repositories your teams and roles allow.
• Leaving an employer: an organization owner removes you. Your personal account, its repositories and your public contribution history stay as they are. You lose access to the organization's private repositories, and your private forks of those private repositories are removed too. Commits you already made stay in the organization's history.
• Next job: the same personal account joins the new employer's organization.

Because access lives in membership, one personal account can belong to several organizations at once, and changing employers never needs a new account.

The exception: managed user accounts. Some enterprises use Enterprise Managed Users, where the company's identity provider creates and controls the accounts its people use for company work. Those accounts are separate from a person's own personal account by design. How they are configured belongs to the security and administration domain; for this topic, remember that the "one personal account" recommendation applies to ordinary organizations.

GitHub's plans split by account type: a personal account chooses between GitHub Free and GitHub Pro, while an organization chooses between GitHub Free for organizations, GitHub Team and GitHub Enterprise. The free plans give the full feature set on public repositories; the paid plans mostly add advanced tools for private repositories, and Enterprise adds identity, governance and deployment options.

Features follow the repository owner's plan

A repository gets the features of the plan of the account that owns it. Two decisions follow directly:

• A private repository owned by a personal account gets the advanced tools when that personal account is on Pro. Team and Enterprise are organization plans and do not apply to personal accounts.
• A private repository owned by an organization gets the organization's plan; the plans of individual members' personal accounts do not carry over to it. Among organization plans, Team is the lower-cost one that adds required reviewers, protected branches and code owners; Enterprise is the step up when the needs include SAML SSO, SCIM provisioning, internal repositories or managing many organizations together.

Because public repositories already have the full feature set on every plan, the paid plans matter mainly for private work; GitHub Free for organizations still provides shared ownership and teams. Prices, minute allowances and storage quotas change over time, so learn what each plan is for rather than its numbers.

GitHub Enterprise comes in two deployment options: GitHub Enterprise Cloud, which GitHub hosts, and GitHub Enterprise Server, which the customer installs and runs on its own infrastructure. Enterprise Cloud can also be bought with data residency, which stores the company's code and data in a chosen region on its own subdomain of GHE.com.

Both Enterprise Cloud and Enterprise Server use an enterprise account to manage several organizations together. The organizations keep their own repositories, members and teams, while enterprise owners apply policies and billing across all of them from one place: it is the layer GitHub designed for managing many organizations as a group.

Two names that sound related do different jobs. GitHub Connect links an Enterprise Server instance to an Enterprise Cloud account so they can share selected features and data, such as license usage. Self-hosted runners are machines you provide to run GitHub Actions jobs; they decide where workflow jobs execute, not where GitHub itself is hosted.

The GitHub flow is GitHub's lightweight, branch-based workflow for collaborating: you make every change on a branch, propose it with a pull request, get it reviewed, merge it into the default branch and delete the branch. The default branch stays deployable because nothing reaches it without a pull request.

1. Create a branch from the default branch, with a short, descriptive name (for example increase-test-timeout or add-code-of-conduct), so collaborators can see what is in progress. People with write access branch in the repository itself; people without write access fork it first and branch in the fork.
2. Make changes: commit to the branch and push it to GitHub. Each commit should be an isolated, complete change with a descriptive message, so it is easy to review or revert.
3. Create a pull request asking collaborators to review the branch. Describe what changed and why, and link related issues.
4. Address review comments. Reviewers comment on the pull request or on specific lines; you respond by pushing more commits to the same branch, and the pull request updates automatically.
5. Merge the pull request once it is approved (and any required checks and branch protection rules pass). This brings the branch's changes into the default branch.
6. Delete the branch. Its commits are now in the default branch, so deleting it loses nothing and signals that the work is done. A deleted branch can be restored from the pull request page if it is needed again.

The order matters: review happens before merge. A sequence that merges first and reviews afterwards, or that commits to the default branch and only then creates a branch, is not the GitHub flow. Opening a pull request before any branch or commit exists is not the starting point either: the flow starts with a branch.

Good GitHub flow habits keep each pull request small, focused and easy to review: one branch per unrelated change, draft pull requests for early feedback, follow-up commits for review fixes, and a revert pull request when a merged change must be undone.

Separate branches for unrelated changes

Each unrelated change gets its own branch, created from the default branch, and its own pull request. A pull request should do one thing: reviewers can then judge it on its own, and it can merge as soon as it is ready without waiting for, or depending on, other unfinished work.

Draft pull requests for early feedback

When you want comments and checks on unfinished work, open a draft pull request. It has the full pull request experience (conversation, line comments, status checks) but cannot be merged until you mark it ready for review. That block is enforced by GitHub itself, so it does not rely on everyone noticing a convention. Draft pull requests are available on public repositories on every plan; on private repositories they depend on the owner's plan (for example GitHub Team or Enterprise).

Updating a pull request

To act on review feedback, commit the fixes and push them to the branch the pull request already uses. The pull request picks up the new commits automatically, so the code, the comments and the checks stay together in one review history.

Undoing a merged pull request

To undo a merged pull request, use Revert on it. GitHub creates a new pull request containing a revert commit, which is reviewed and merged like any other change. The principle is to undo by adding history, never by rewriting it: rewriting a shared branch bypasses review and breaks the copies other people have already pulled.

GitHub Flavored Markdown is the plain-text formatting syntax GitHub renders in issues, pull requests, comments, discussions, wikis and .md files; it lets you write clear, structured descriptions with headings, lists, code, links, images and checklists without leaving the text box.

Relative links and images

For files inside the repository, GitHub recommends relative links such as ![Flow](docs/flow.png) rather than absolute URLs. A relative path is resolved against the branch or fork being viewed, so each branch shows its own copy of the file; an absolute URL that names one branch keeps showing that branch's version everywhere. A path that starts with / is resolved from the repository root.

Pick the syntax by what the reader needs: inline code for a word, a fenced block for anything that spans lines, and a quote only for prose you are quoting.

GitHub turns short references into links: #number links an issue or pull request in the same repository, owner/repo#number links one in another repository, and @username or @organization/team-name mentions a person or a team so they are notified.

The rule of thumb: # is for issues and pull requests, @ on its own is for people and teams, and @ after a repository name is followed by a commit SHA.

Who actually gets notified

A mention notifies someone only if they have read access to the repository and, when an organization owns the repository, are a member of that organization. This stops private content leaking through notifications, while everyone who can already read the repository, public or private, is notified normally. A team mention notifies the team's members on the same terms.

Beyond the basics, GitHub Markdown supports alerts for callouts, collapsed sections for long content, Mermaid diagrams drawn from text, footnotes, and HTML comments that are kept in the source but never rendered.

The near-twins to keep apart: a collapsed section hides until clicked but is still part of the rendered issue, an HTML comment is never shown to readers, and a footnote or code block always shows its content. Because a Mermaid diagram is text, changing it is an ordinary edit that shows up in the diff.

GitHub Desktop is a free, open source graphical app for Windows and macOS that does everyday local Git work without typing commands; GitHub Mobile is the Android and iOS app for staying on top of GitHub away from your computer. Desktop works with repositories on your machine; Mobile works with GitHub itself.

GitHub Mobile with GitHub Enterprise Server

GitHub Mobile can connect to a GitHub Enterprise Server instance only when an enterprise owner enables mobile support for the enterprise (and the instance runs a supported version).

When neither fits: GitHub CLI and the browser

Recognising when to use Desktop or Mobile includes recognising when not to. Scripting and unattended automation need a command-line tool: GitHub CLI (gh) exposes pull requests, issues, labels and more as commands that run in scripts and CI jobs. Quick edits in the browser can use the github.dev editor, and a full cloud development environment is GitHub Codespaces; both are covered in their own lessons.