I’ve been using GitHub since October 2012 but until recently I’ve had very little understanding of any working process that enables me to contribute to other projects using Pull Requests ( PRs ).
But now I’ve started to try to work with branches. Two reasons:
- To enable me to contribute to Gutenberg- for Full Site Editing improvements.
- To help others to learn about version control system by collaboratively developing repositories on wppompey.
In this post I’ll document the process I’m using for developing PRs against Gutenberg issues.
I read the instructions on WordPress.org. They all made sense, but I couldn’t work out how to create a PR that only contained the changes I’d intended to make. While the overall effect of my PRs were the change I intended, every Pull Request consisted of multiple commits, not just the one I wanted to apply. Obviously I was doing it wrong.
I read some Stack Overflow items ( thanks Angel for directing me to them ) and discovered the git commands that appear to do the job.
I’ve now created 4 or 5 PRs using this method. And so far I’ve not had any problems. This is a good thing. I’ve just re-read the Git Workflow process and realised it’s almost exactly the same.
Preparation – per repository
- Fork the repository in GitHub.
- Clone to the directory where you’re going to make your changes.
- Add the upstream repository.
- Fetch the latest versions.
cd \apache\htdocs\wordpress\wp-content\plugins git clone https://github.com/bobbingwide/gutenberg.git gutenberg-source cd gutenberg-source git remote add upstream https://github.com/WordPress/gutenberg.git git fetch --all
For each Issue / PR
Work in a new branch (
git checkout -b fix/%1 upstream/trunk
Now make and test changes in the new branch. Add files and commit as often as necessary, with a nice commit message, referencing the issue number each time?
git commit -m "good commit message 50-70 characters
When ready push the changes to your fork of the repository (
git push -u origin fix/%1
Theoretically this should work for any repository.
Then change back to the main branch
git checkout trunk
To keep the local repository up to date use
fetch --all. I believe this has to be done in
C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-source> git checkout trunk git fetch --all Fetching origin Fetching upstream remote: Enumerating objects: 3248, done. remote: Counting objects: 100% (3248/3248), done. remote: Compressing objects: 100% (273/273), done. Receiving objects: 100% ( Receiving objects: 100% (4749/4749), 51.99 MiB | 3.85 MiB/s, done. Resolving deltas: 100% (3648/3648), completed with 996 local objects. From https://github.com/WordPress/gutenberg ...
What I was doing wrong
For the 150 or so GitHub repositories under
bobbingwide I developed all my changes in the
main branch. It’s still called
master for many of them. Then I pulled the changes to a local version in
C:\github\bobbingwide\repository-name and pushed them from there.
I had two copies of each repository. One reason for this was protection against having the repository destroyed accidentally by WordPress updates or unpacking
.zip files into other development enviroments.