How to pull from github to

How to create a pull request in GitHub

So, you know how to use git. You have a GitHub repo and can push to it. All is well. But how the heck do you contribute to other people’s GitHub projects? That is what I wanted to know after I learned git and GitHub. In this article, I will explain how to fork a git repo, make changes, and submit a pull request.

When you want to work on a GitHub project, the first step is to fork a repo.

Use my demo repo to try it out.

Once there, click on the Fork button in the top-right corner. This creates a new copy of my demo repo under your GitHub user account with a URL like:

The copy includes all the code, branches, and commits from the original repo.

Next, clone the repo by opening the terminal on your computer and running the command:

Once the repo is cloned, you need to do two things:

Create a new branch by issuing the command:

Create a new remote for the upstream repo with the command:

In this case, «upstream repo» refers to the original repo you created your fork from.

Now you can make changes to the code. The following code creates a new branch, makes an arbitrary change, and pushes it to new_branch:

Once you push the changes to your repo, the Compare & pull request button will appear in GitHub.

Click it and you’ll be taken to this screen:

Open a pull request by clicking the Create pull request button. This allows the repo’s maintainers to review your contribution. From here, they can merge it if it is good, or they may ask you to make some changes.

In summary, if you want to contribute to a project, the simplest way is to:

If the reviewers ask for changes, repeat steps 5 and 6 to add more commits to your pull request.

choosealicense.com and GitHub’s license picker

In a previous article, I discussed the complaints that have been leveled against GitHub during the past year and a half concerning the purported problem of public, seemingly.

Making science more open at GitHub

Arfon Smith works at GitHub and is involved in a number of activities at the intersection of open science, open source, and online research. He has worked on several.

Pull Request Tutorial

A Visual Guide to Pull Requests

Pull Request Tutorial

What is a Pull Request?

Pull requests let you tell others about changes you’ve pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Pull Requests are commonly used by teams and organizations collaborating using the Shared Repository Model, where everyone shares a single repository and topic branches are used to develop features and isolate changes. Many open source projects on Github use pull requests to manage changes from contributors as they are useful in providing a way to notify project maintainers about changes one has made and in initiating code review and general discussion about a set of changes before being merged into the main branch.

Here’s an example pull request from jQuery’s github repo.

Creating a Pull Request

There are 2 main work flows when dealing with pull requests:

Here we are going to focus on 2.

Creating a Topical Branch

First, we will need to create a branch from the latest commit on master. Make sure your repository is up to date first using

Note: git pull does a git fetch followed by a git merge to update the local repo with the remote repo. For a more detailed explanation, see this stackoverflow post.

Creating a Pull Request

To create a pull request, you must have changes committed to the your new branch.

Go to the repository page on github. And click on «Pull Request» button in the repo header.

Pick the branch you wish to have merged using the «Head branch» dropdown. You should leave the rest of the fields as is, unless you are working from a remote branch. In that case, just make sure that the base repo and base branch are set correctly.

Enter a title and description for your pull request. Remember you can use Github Flavored Markdown in the description and comments

Finally, click on the green «Send pull request» button to finish creating the pull request.

You should now see an open pull request.

Using a Pull Request

You can write comments related to a pull request,

view all the commits by all contained by a pull request under the commits tab,

or see all the file changes from the pull request across all the commits under the «Files Changed» tab.

You can event leave a comment on particular lines in the code change simply by hovering to the left of a line and clicking on the blue note icon.

Merging a Pull Request

Once you and your collaborators are happy with the changes, you start to merge the changes back to master. There are a few ways to do this.

First, you can use github’s «Merge pull request» button at the bottom of your pull request to merge your changes. This is only available when github can detect that there will be no merge conflicts with the base branch. If all goes well, you just have to add a commit message and click on «Confirm Merge» to merge the changes.

Merging Locally

If the pull request cannot be merged online due to merge conflicts, or you wish to test things locally before sending the merge to the repo on Github, you can perform the merge locally instead.

You can find the instruction to do so by clicking the (i) icon on the merge bar.

However, there’s an alternative that may be better for long standing branches.

Squash, Rebase, and Cherry Pick

In long standing branches, merging can often cause lots problems when updating if changes in a given branch conflict with changes recently merged into the master branch. If there are many commits to the same file, git merge may force you to fix the same merge conflicts over and over again, causing a real headache. While there are many ways to mitigate this issue, such as enabling git rerere to reuse recorded resolution of conflict merges, squashing a series of related changes into 1 commit and cherry-picking it into the master is a great solution, especially for topic branches and isolated features.

There are several advantages of performing merges this way. First, you only have to deal with merge conflicts once, since all commits are compressed into 1. Second, each commit represents an entire set of changes required for a feature or task, which makes it easy to pin point bugs and other problems when they arise and to remove a change set when it’s no longer necessary.

There are also disadvantages of squashing commits. First, you will lose the details and information for each change, as all changes squashed are compressed together. So the net effect is the same. Second, it can be dangerous and problematic if used incorrectly, such as squashing commits that have been pushed to the remote server and others depend on for their work. Because squashing is changing the git history, you can cause many conflicts that way. However, if you are using this locally or you are the only person working on your branch and you know exactly what you are doing.

To perform this, use the following command

-i stands for interactive mode and HEAD

10 means to examine the 10 latest commits.

If you see an fatal: Needed a single revision error, this usually means that there are not that many commits left. Try a lower number.

This will open up an editor with git commit messages that looks something like this:

There are many options available at this stage. These are detailed in this github help page. Here, I’m going to simply squash all changes in this pull request into one. Save and close the editor.

The next screen will pop up asking you to edit your commit messages. You can choose to edit them or simply continue. Save and close the editor.

Once your squash completes, you can push it to the remote repo. In this case, these squashed commits have been pushed to the server. However, I’m the only user of this branch and can safely force push the commit to update the git repo.

You are done! Github should detect the changes and update the pull request. You can then marked the pull request as merged and optionally delete the branch.

Closing a Pull Request

You can simply click on the «Close» button on the pull request to close it. Optionally, you can delete the branch directly using the «Delete this branch» button.

Pull Request Tutorial is maintained by yangsu
This page was generated by GitHub Pages. Tactile theme by Jason Long.

How to pull from github to

Как сделать pull request

Регистрация на GitHub

Если у вас нет аккаунта на Github – регистрируемся по ссылке http://github.com/join

Если есть – просто входим по ссылке http://github.com/login

Как сделать pull request прямо на GitHub

Шаг 1. Заходим в основной репозиторий задачи https://github.com/urfu-2015/verstka-tasks-1
И делаем форк задачи к себе. Для этого жмём «fork» в правом верхнем углу.

Форк (fork) можно расматривать, как личную копию основного репозитория.

Шаг 2. Заходим к себе https://github.com/gogoleff/verstka-tasks-1. Вместо gogoleff свой логин.

Шаг 3. Нажимаем на файл, который хотим изменить. Затем кнопку редактирования.

Шаг 4. Редактируем файл до готовности прямо здесь (или вставляем код из любимого редактора)

Шаг 5. Когда всё готов создадим коммит.
Для этого внизу в поле «summary» вводим поясняющий текст, и нажимаем «Commit changes».

Коммит (commit) – можно рассматривать, как утверждение кода, создание версии (как в wiki). К каждой версии можно вернуться. Каждый новый коммит – новая версия вашего кода.

Шаг 6. Создаём pull request. Для этого выбираем пункт меню справа «Pull requests».
И нажимаем кнопку «New pull request».

Шаг 7. Нажимаем кнопку «Create pull request»

Шаг 8. Вводим своё ФИО и нажимаем кнопку «Create pull request»

Готово!

Если нужны правки, просто повторяем шаги со 2 по 5.

Как сделать pull request в windows

Шаг 1. Заходим в основной репозиторий задачи https://github.com/urfu-2015/verstka-tasks-1
И делаем форк задачи к себе. Для этого жмём «fork» в правом верхнем углу.

Форк (fork) можно расматривать, как личную копию основного репозитория.

Шаг 2. Затем скачивание приложение по ссылке https://desktop.github.com/

Шаг 3. Устанавливаем. После установки приложение попросит настроить его. Вводим логин и пароль.

Шаг 4. Затем полное имя и электронную почту (обычно уже верно заполнены).

Шаг 5. После настройки вы попадёте в приложение. Теперь клонируем репозиторий с задачей.
Для этого нажимаем «+» в левом верхнем углу, выбираем свой логин слева, и репозиторий verstka-tasks-1 справа.

Клон (clone) можно расматривать, как локальную копию личного репозитория.

Шаг 6. Выбираем рабочую директорию (обычно уже подходящая).

Шаг 7. Теперь заходим в директорию (там должны быть файлы index.html и README.md).

Шаг 9. Решаем задачу, редактируем файлы в любимом редакторе до полной готовности. В приложении видим изменения.

Шаг 10. Когда всё готов создадим коммит.
Для этого внизу в поле «summary» вводим поясняющий текст, и нажимаем «Commit to master».

Коммит (commit) – можно рассматривать, как утверждение кода, создание версии (как в wiki). К каждой версии можно вернуться. Каждый новый коммит – новая версия вашего кода.

В результате видим сообщение:

Шаг 11. Таким образом мы утвердили наши изменения в локальном (склонированном) репозитории. Теперь необходимо отправить ветку с изменениями в удалённый личный (форк) на github.com и сделать pull request. В качестве название пулл-реквеста вводим своё ФИО и нажимаем «Send Pull Request».

В результате видим сообщение:

Готово!

Если нужны правки, повторяем шаги 9 и 10. Затем нажимаем «Sync» в правом верхнем углу. Приложение отправит коммит в удалённый личный репозиторий (форк), что автоматически обновит pull request.

Как сделать pull request в windows, используя Git Shell

Здесь два варианта:

После установки, запускаем Git Bash
(ярлык для запуска можно найти в меню Пуск).

Устанавливаем вместе с приложением Git Shell.
Для этого выполняем шаги со 2 по 4 раздела Как сделать pull request в windows

После установки приложения, запускаем Git Shell
(ярлык для запуска можно найти на рабочем столе).

Далее смотрим shell команды в разделе как сделать pull request в linux.

Как сделать pull request в linux

Заходим в основной репозиторий задачи https://github.com/urfu-2015/verstka-tasks-1
И делаем форк задачи к себе. Для этого жмём «fork» в правом верхнем углу.

В linux уже установлен git и обычно настроен.

Шаг 1. Выполняем следующие команды в терминале:

Шаг 2. Заходим в к себе в репозиторий.

Шаг 3. Создаём pull request. Для этого выбираем пункт меню справа «Pull requests».
И нажимаем кнопку «New pull request».

Шаг 4. Нажимаем кнопку «Create pull request»

Шаг 5. Вводим своё ФИО и нажимаем кнопку «Create pull request»

Готово!

Если нужны правки. Вносим их в любимом редакторе, и снова делаем коммит.

How to pull from github to

Copy raw contents

Concepts, guidelines and advanced usage

This document covers terminology, how the action works, general usage guidelines, and advanced usage.

Pull requests are proposed changes to a repository branch that can be reviewed by a repository’s collaborators before being accepted or rejected.

A pull request references two branches:

Events and checkout

This action expects repositories to be checked out with the official GitHub Actions checkout action. For each event type there is a default GITHUB_SHA that will be checked out.

The default can be overridden by specifying a ref on checkout.

How the action works

Unless the base input is supplied, the action expects the target repository to be checked out on the pull request base —the branch you intend to modify with the proposed changes.

The following git diagram shows how the action creates and updates a pull request branch.

Providing a consistent base

For the action to work correctly it should be executed in a workflow that checks out a consistent base branch. This will be the base of the pull request unless overridden with the base input.

This means your workflow should be consistently checking out the branch that you intend to modify once the PR is merged.

In the following example, the push and create events both trigger the same workflow. This will cause the checkout action to checkout inconsistent branches and commits. Do not do this. It will cause multiple pull requests to be created for each additional base the action is executed against.

There may be use cases where it makes sense to execute the workflow on a branch that is not the base of the pull request. In these cases, the base branch can be specified with the base action input. The action will attempt to rebase changes made during the workflow on to the actual base.

Events which checkout a commit

The default checkout for the majority of events will leave the repository checked out on a branch. However, some events such as release and pull_request will leave the repository in a «detached HEAD» state. This is because they checkout a commit, not a branch. In these cases, you must supply the base input so the action can rebase changes made during the workflow for the pull request.

Workflows triggered by pull_request events will by default check out a merge commit. Set the base input as follows to base the new pull request on the current pull request’s branch.

Workflows triggered by release events will by default check out a tag. For most use cases, you will need to set the base input to the branch name of the tagged commit.

Restrictions on repository forks

GitHub Actions have imposed restrictions on workflow runs triggered by public repository forks. Private repositories can be configured to enable workflows from forks to run without restriction.

The restrictions apply to the pull_request event triggered by a fork opening a pull request in the upstream repository.

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

The GITHUB_TOKEN has read-only access when an event is triggered by a forked repository.

These restrictions mean that during a pull_request event triggered by a forked repository, actions have no write access to GitHub resources and will fail on any attempt.

A job condition can be added to prevent workflows from executing when triggered by a repository fork.

For further reading regarding the security of pull requests, see this GitHub blog post titled Keeping your GitHub Actions and workflows secure: Preventing pwn requests

Triggering further workflow runs

Pull requests created by the action using the default GITHUB_TOKEN cannot trigger other workflows. If you have on: pull_request or on: push workflows acting as checks on pull requests, they will not run.

Workarounds to trigger further workflow runs

There are a number of workarounds with different pros and cons.

Use the default GITHUB_TOKEN and allow the action to create pull requests that have no checks enabled. Manually close pull requests and immediately reopen them. This will enable on: pull_request workflows to run and be added as checks. To prevent merging of pull requests without checks erroneously, use branch protection rules.

Use a repo scoped Personal Access Token (PAT) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and recommended by GitHub. However, the PAT cannot be scoped to a specific repository so the token becomes a very sensitive secret. If this is a concern, the PAT can instead be created for a dedicated machine account that has collaborator access to the repository. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.

Use SSH (deploy keys) to push the pull request branch. This is arguably more secure than using a PAT because deploy keys can be set per repository. However, this method will only trigger on: push workflows.

Use a machine account that creates pull requests from its own fork. This is the most secure because the PAT created only grants access to the machine account’s fork, not the main repository. This method will trigger on: pull_request workflows to run. Workflows triggered on: push will not run because the push event is in the fork.

Use a GitHub App to generate a token that can be used with this action. GitHub App generated tokens are more secure than using a PAT because GitHub App access permissions can be set with finer granularity and are scoped to only repositories where the App is installed. This method will trigger both on: push and on: pull_request workflows.

From a security perspective it’s good practice to fork third-party actions, review the code, and use your fork of the action in workflows. By using third-party actions directly the risk exists that it could be modified to do something malicious, such as capturing secrets.

Alternatively, use the action directly and reference the commit hash for the version you want to target.

This action uses ncc to compile the Node.js code and dependencies into a single JavaScript file under the dist directory.

Creating pull requests in a remote repository

Checking out a branch from a different repository from where the workflow is executing will make that repository the target for the created pull request. In this case, a repo scoped Personal Access Token (PAT) is required.

Push using SSH (deploy keys)

Deploy keys can be set per repository and so are arguably more secure than using a repo scoped Personal Access Token (PAT). Allowing the action to push with a configured deploy key will trigger on: push workflows. This makes it an alternative to using a PAT to trigger checks for pull requests. Note that you cannot use deploy keys alone to create a pull request in a remote repository because then using a PAT would become a requirement. This method only makes sense if creating a pull request in the repository where the workflow is running.

How to use SSH (deploy keys) with create-pull-request action:

Push pull request branches to a fork

Instead of pushing pull request branches to the repository you want to update, you can push them to a fork of that repository. This allows you to employ the principle of least privilege by using a dedicated user acting as a machine account. This user has no access to the main repository. It will use their own fork to push code and create the pull request.

Authenticating with GitHub App generated tokens

A GitHub App can be created for the sole purpose of generating tokens for use with GitHub actions. These tokens can be used in place of GITHUB_TOKEN or a Personal Access Token (PAT). GitHub App generated tokens are more secure than using a PAT because GitHub App access permissions can be set with finer granularity and are scoped to only repositories where the App is installed.

Create a minimal GitHub App, setting the following fields:

Create a Private key from the App settings page and store it securely.

Install the App on any repository where workflows will run requiring tokens.

The following example workflow shows how to use tibdex/github-app-token to generate a token for use with this action.

GPG commit signature verification

The action can use GPG to sign commits with a GPG key that you generate yourself.

Add the public key to the user account associated with the Personal Access Token (PAT) that you will use with the action.

Copy the private key to your clipboard, replacing email@example.com with the email address of your GPG key.

Paste the private key into a repository secret where the workflow will run. e.g. GPG_PRIVATE_KEY

Create another repository secret for the key’s passphrase, if applicable. e.g. GPG_PASSPHRASE

The following example workflow shows how to use crazy-max/ghaction-import-gpg to import your GPG key and allow the action to sign commits.

Note that the committer email address MUST match the email address used to create your GPG key.

Running in a container or on self-hosted runners

This action can be run inside a container, or on self-hosted runners, by installing the necessary dependencies.

The following examples of running in a container show the dependencies being installed during the workflow, but they could also be pre-installed in a custom image.

git pull

Git pull usage

How it works

The git pull command first runs git fetch which downloads content from the specified remote repository. Then a git merge is executed to merge the remote content refs and heads into a new local merge commit. To better demonstrate the pull and merging process let us consider the following example. Assume we have a repository with a main branch and a remote origin.

In this scenario, git pull will download all the changes from the point where the local and main diverged. In this example, that point is E. git pull will fetch the diverged remote commits which are A-B-C. The pull process will then create a new local merge commit containing the content of the new diverged remote commits.

In this diagram, we can now see that a rebase pull does not create the new H commit. Instead, the rebase has copied the remote commits A—B—C and rewritten the local commits E—F—G to appear after them them in the local origin/main commit history.

Common Options

Similar to the default invocation, fetches the remote content but does not create a new merge commit.

Gives verbose output during a pull which displays the content being downloaded and the merge details.

Git pull discussion

You start out thinking your repository is synchronized, but then git fetch reveals that origin’s version of main has progressed since you last checked it. Then git merge immediately integrates the remote main into the local one.

Git pull and syncing

git pull is one of many commands that claim the responsibility of ‘syncing’ remote content. The git remote command is used to specify what remote endpoints the syncing commands will operate on. The git push command is used to upload content to a remote repository.

Pulling via Rebase

Git Pull Examples

The following examples demonstrate how to use git pull in common scenarios:

Default Behavior

Executing the default invocation of git pull will is equivalent to git fetch origin HEAD and git merge HEAD where HEAD is ref pointing to the current branch.

Git pull on remotes

Git pull rebase instead of merge

The following example demonstrates how to synchronize with the central repository’s main branch using a rebase:

This simply moves your local changes onto the top of what everybody else has already contributed.