Why is GitHub the second pick and not the first for git workflows?

Because the workflow starts on disk, and the local Git server owns that, staging and committing on the checkout. GitHub adds the hosted layer of pull requests, reviews, and Actions on top. They cover different halves, so the two pair up.

Can GitHub's server take a change from commit to merge?

Yes, on the hosted side. push_files and create_or_update_file record changes, create_branch isolates them, and the server's pull-request handling opens and moves the change through review. The local commit step itself is the Git server's job.

GitHub for git workflows

Pick 2 of 4 for git workflowsOfficialGitHub30,334

For git workflows, GitHub's official server is the second of four picks, and it adds the hosted layer that turns a commit into a merged change. It covers pull requests, issues, code search, reviews, and Actions, so an agent can take work from a commit all the way to a reviewed, merged PR.

It ranks second behind the local Git server, which owns the on-disk mechanics. GitHub is what happens after: the platform where review and merge live.

How GitHub fits

get_file_contents reads repository files, and create_or_update_file, delete_file, and push_files write changes, with push_files batching a multi-file change into one commit. create_branch and list_branches manage the branches a workflow runs on, and list_tags reads release points. create_repository and fork_repository stand up or copy a project, while get_me, get_teams, and get_team_members resolve who is acting. With the server's pull-request and issue management on top, an agent can open a change and move it through review.

The siblings cover the layers GitHub does not. The local Git server ranks first because the workflow begins on disk, staging and committing on the checkout, which GitHub's hosted surface cannot do. GitLab and Bitbucket are the picks when your code and reviews live on those platforms instead of GitHub. Reach for GitHub's server when GitHub is your forge and the job is taking a change from commit to merged PR; pair it with the local Git server for the on-disk steps.

Tools you would use

Tool	What it does
get_me	Gets the authenticated user's profile.
get_teams	Gets the teams a user or organization belongs to.
get_team_members	Lists the members of an organization team.
get_file_contents	Gets the contents of a file or directory from a repository.
create_or_update_file	Creates a new file or updates an existing one in a repository.
delete_file	Deletes a file from a repository.
push_files	Pushes multiple files to a repository in a single commit.
create_repository	Creates a new repository.
fork_repository	Forks a repository into your account.
create_branch	Creates a new branch in a repository.

Full GitHub setup and config →

FAQ

Why is GitHub the second pick and not the first for git workflows?: Because the workflow starts on disk, and the local Git server owns that, staging and committing on the checkout. GitHub adds the hosted layer of pull requests, reviews, and Actions on top. They cover different halves, so the two pair up.
Can GitHub's server take a change from commit to merge?: Yes, on the hosted side. push_files and create_or_update_file record changes, create_branch isolates them, and the server's pull-request handling opens and moves the change through review. The local commit step itself is the Git server's job.