Introduction to Git and GitHub

Session - Pull Requests

Zoë Turner

Pushing to the remote (GitHub)

We want to push the copy branch to GitHub, make a pull request to merge into main

usethis::pr_push()

This open the pull request in GitHub/a browser, select the Create Pull Request button

Draft pull requests

For public repositories it’s possible to change the pull request to a draft.
In GitHub click on the down arrow on the green button for Create pull request and select Draft
Click the green button again to make the pull request

Extra unnecessary step?

Creating a pull request to the main branch can be seen as an extra step, particularly when you are working alone
But if you are working with others or the main is a clean working branch you need to protect it
Pull requests will be where your merge conflicts will be highlighted
People can see you are working on things
You have a remote copy of your work if anything were to happen to your local computer!
Reverting (undoing) a pull request is really easy in GitHub, even more so if you have a lot of commits

Options to merge - default

There are three options the default being

Create a merge commit creates a new merge commit which isn’t very descriptive in the name

Merge pull request #1 from Letxuga007/new_work

but is recommended as an easier way to debug for when things get muddled

Squashing

Squash and merge details multiple commits in one

New work (#1) * First commit for quarto document * Removed author

which is a nice way to keep all the commit messages but messages can get long

Squashing

Atomic committing is a practice in Git versioning where each distinct step is committed
Squashing is only used in this this practice if things are very closely related:
# updated titles
# renamed titles
# correct spelling in title

Rebase

Rebase and merge keeps all the commits as you created them in a linear way

The history is more readable but can be tougher to resolve conflicts

Screenshot of the commits from a rebase merge

Let’s pause!

Sometimes you need to go back to main to get changes from colleagues or create a new branch:

usethis::pr_pause()

This does a few things

✔ Setting active project to '/cloud/project'
✔ Switching back to the default branch.
✔ Checking that local branch 'new_work' has the changes in 'origin/new_work'
✔ Switching back to default branch ('main').
✔ Pulling changes from 'origin/main'

Resuming your PR

First find the PR to work on:

usethis::pr_fetch()

Gives you details of what is open as a PR:

✔ Setting active project to '/cloud/project'
ℹ No PR specified ... looking up open PRs.
Which PR are you interested in? (0 to exit) 

1: #1 (@Letxuga007): 'New work'

To resume then select the number or if you know the PR before then

usethis::pr_fetch(1)

Finish with the PR

If the PR is set to Draft then, in GitHub, set to review
If the PR was not a Draf the button Merge pull request will be available straight away
Return to RStudio and type

usethis::pr_finish()

Several things gets tidied up all in one function

✔ Switching back to default branch ('main').
✔ Pulling changes from 'origin/main'
✔ Deleting local 'new_work' branch.
✔ PR 'Letxuga007/project/#1' has been merged, deleting remote branch 'origin/new_work'

You might want to discard a PR

If you are working on something and change your mind

usethis::pr_forget()

when in the branch you want to discard:

✔ Switching back to default branch ('main').
✔ Pulling changes from 'origin/main'
✔ Deleting local 'mistake-branch' branch.

PR needs to be tidied in GitHub

Because local is different to remote you will need to close any PR on GitHub

Local and remote branches

Local and Remote branches are distinct things so although new_work branch has been deleted and the remote has been merged, the connection in RStudio remains

Screenshot of the drop down of branches in the RStudio git pane where under the greyed out (REMOTE: ORIGIN) new_work can be seen

To tidy, in the Terminal type:

git remote prune origin

End session

Acknowledgements

Happy Git and GitHub for the useR by Jenny Bryan