Github Workflow + Pull Requests
This article is intended to help provide a basic understanding of contributing to forked repositories on github, including forking, updating your local copy, and making Pull Requests.
Quick Reference for Newcomers to git or github
For the basics of learning git, see: https://help.github.com/categories/bootcamp/
For the basics of learning github, see: https://help.github.com/articles/good-resources-for-learning-git-and-github/
To collaborate by sharing your code suggestions, you will need to “fork” our public repository. For the basics of understanding forking and how to manage that fork, see: https://help.github.com/articles/fork-a-repo
If you’re looking for paid training courses on using git/github, see: https://training.github.com/
Glossary of common terms in git and github: https://help.github.com/articles/github-glossary
Client Applications to Interact with git
To interact with git, you can use the command line or you can use a desktop application. (There are also mobile/tablet apps, but we won’t cover that here.)
We recommend working with one of the following first two options.
command line. Purists will use the command line, for reasons they will pine eloquently about if asked. There are hundreds of resources online showing how to use all the git features via command line, starting with the links at the top of this page.
SourceTree for Windows and Mac - this is another good free desktop application which does a good job of giving you access to all the power of git/github/bitbucket/mercurial in an easy visual interface. We highly recommend using SourceTree due to its simplicity.
When you first set up SourceTree, it will ask you to log in to your Atlassian account. The account is free, and no side-effects, and no personal information needs to be provided besides name/email.
There’s another option, which we’re NOT recommending here, as its UI is very complicated. Also (at the time of this writing) it has an important limitation when working with forked repositories: It doesn’t support multiple remotes, which means you’ll need to use the command line to keep your checkouts up to date with our central repository’s branches else you’ll have problems when issuing pull requests. That other option is github’s own application: Github Desktop for Windows or Mac - these are free desktop applications written by Github, and make visual interaction easy when working only with your own repositories but not when regularly contributing to someone else’s projects.
While you won’t find us documenting how to use them, there are several other git GUI client apps
Here’s the workflow you’ll want to use as a collaborator with Zen Cart® and probably most other open source projects:
CLA - Contributor License Agreement
First, before you can contribute code, you must sign the Contributor License Agreement, basically saying that you willingly offer your contributions for use without compensation or restriction and that your contributions are entirely yours and not copyrighted or licensed by someone else under restrictive rules.
If you have not signed the CLA using the email address or username you use for github, we cannot accept your pull request.
(LINK TO SIGN CLA WILL BE ADDED HERE SHORTLY)
- github account
- Create a github account at www.github.com
- Fork the Repository
- On the github site, fork the project’s repository (at the time of this writing, the main ZC repository is at https://github.com/zencart/zencart). This makes a copy of that repository into your own github account, which is where you will upload your changes since you only have “write” permissions in your own repository.
- Clone the repository to your own computer. (see below)
Cloning a repository
- Get the URL for the repository you’re cloning
- Go to your github account page
- Go to your fork of the Zen Cart repository:
- Halfway down the right side of the page you’ll see a URL in a textbox, with a clipboard icon next to it. It probably says “HTTPS clone URL” above it. You’ll want to click the clipboard to copy that URL to your computer’s clipboard.
Now switch to your desktop application of choice and use that URL to clone the repository locally:
- pick a working directory on your PC
- cd into that directory
git clone PASTE-THAT-URL-HERE .(note the
.at the end, which says “put it in the current directory”)
- Choose File, New Clone…
- In the Source Path/URL, paste the URL you copied from github
- For the destination path, pick a folder on your PC
- For the bookmark name, call it whatever friendly name you want to remember this repo by. It will show up in SourceTree’s bookmarks list of repositories you’ve got.
- Click Clone or OK to have it start the clone. It will take a few seconds for it to download the repository contents to your computer.
Add an upstream remote
To keep your own fork up-to-date, you’ll need to periodically merge updates from the main Zen Cart repository. This involves telling your own local (on your PC) git repository about the main Zen Cart repository location. To do this you must add what’s called an “upstream remote”. (See the glossary link above for what a “remote” is.)
- cd into the directory of the repository you’re adding the remote to
git remote add upstream https://github.com/zencart/zencart.git
git fetch upstream
- Choose Repositories from the main menu
- Choose Repository Settings…
- Click Add
- For Remote Name, use: upstream
- For the URL use:
- For the github username, enter your own github account name
- Click OK
- Click Fetch
Making a working-branch
Any time you’re going to contribute code changes, you’ll want to first make a working branch. (For more on branches, see the glossary and other git references at the top of this page.) Branches are how git keeps different versions of changes separate from each other until such time as someone approves merging them together into the main branch.
Pick a branch name
Decide on a new branch name. (The branch name should be brief, but meaningful; ideally a max of 6 words, all hyphenated, no spaces.)
Make the branch
Now use that name for name-of-your-branch-here, below:
- cd into the directory of the repository you’re intending to make changes to
- In this example we’ll be branching from the develop branch
git branch name-of-your-new-branch-here develop
git checkout name-of-your-new-branch-here
- First, make sure you’re in “History View” (View, History View)
- Find where it shows
upstream/develop, and right-click on that row. Choose Branch… from the pop-up menu
- Give it the new branch name
- Leave the “checkout new branch” box checked
- Click Create Branch or OK
Make your code changes
- Edit or create whatever files are applicable to the changes you wish to submit for consideration.
- Test your code. Test to make sure your changes work, and that you’ve not broken anything else in the process.
- Once your code is ready for submission, you’ll need to commit the changes, and push them to your github account and then create a Pull Request. Those steps are described below.
- MAKE SURE YOUR CODE COMPLIES WITH ZEN CART CODING STANDARDS, else it may be rejected.
- If your code can be tested with phpunit, be sure to include those tests in your commits and pull request.
To commit your code, you must first “stage” the files which are to be included. See the git docs mentioned at the top of this page for more detailed explanation of what this means.
Once you’ve staged the files, then you commit them, which saves that group of changes together.
You can make multiple commits (that is, stage the files and commit them) towards any given issue. This allows you to make numerous smaller commits which are easily described in connection with the specific files that relate to those smaller changes.
- cd into the directory of the repository you’re committing from
- this will give you a list of changed/added/deleted files
git add filename1.php filename2.php(and any other files, etc)
- This will pop up your text editor where you can supply a commit message. See explanation of commit messages in the sub section below.
- Save the message using whatever method your text editor uses to save-and-exit
- This will have the commit saved locally. You can continue working and making more commits until you’re ready to push them all up to github (see pushing commits below)
- First, go into File Status view. Click on “Working Copy” in the left nav menu under File Status. Or, use the View menu and choose File Status View.
- Here you’ll see a list of files on-screen which have changed in some way (edits, adds, deletes)
- You can also see exactly what’s changed by clicking on those files and viewing the “diff” on the other side of the screen.
- For each file that you wish to include in the current commit, highlight it in the bottom part of the window, and click the Stage Selected button on the button-bar. It may ask you to confirm that you wish to Add it. (The Windows version has a tiny up-arrow that lets you do the staging as well, instead of using the Add from the top button-bar).
- Once your files are all staged, click the Commit button in the button bar
- This will open a dialog where you can supply a commit message. See the guidance around commit messages in the next section below.
- Click the commit button in the bottom right.
- Your commit is now saved locally on your PC. You can continue making more commits until you’re ready to push them all to github, as described below.
ABOUT COMMIT MESSAGES
- The “subject” or “first line” of a commit message should be no more than 50 characters.
- The next lines can have as much detail as you like. Consider using Github Markdown syntax for any formatting you might wish to include in the message. Feel free to use blank lines, and even use hyphens to create bulleted lists (hyphen plus a space)
- If you’re contributing code to help with an “Issue” that’s already listed on the Zen Cart github Issues page, include that issue number in your commit message, with the hashtag in front of it, like this: #101 for issue number 101.
- Further to the point above, if your commit “fixes” or “closes” or “resolves” an existing open issue then include the word “Fixes” before the issue number, ie: “Fixes #101” somewhere in your commit message. This will cause Github to close the “issue” ticket when your pull request is merged, and helps keep things tidy.
- If you’re committing code that addresses a bug reported on the Zen Cart support forum, include the URL for that bug from the forum, so we can cross-reference it.
Suggested reading: 7 Principles for Good Commit Messages
Pushing Commits To Github
Now that you’ve made some commits to git on your local PC, you must push them to (your account on) github in order to prepare to share them.
- again, cd into the directory of your working repository
git push origin name-of-my-working-branch
- Click the Push button in the top button bar.
- From the pulldown for “Push to repository”, be sure that “origin” is selected. That’s your github repository, and you must push to there.
- Next make sure you check the box next to the branch you’ve been making your commits in. Uncheck all the others.
- Click OK
- That’s it! Now all the commits you’ve made in that branch on your PC will show up in your Github account.
(You’ll also see
Pull Request referred to as a
After you’ve pushed your working branch (ie: containing your new commits) to your own Github account, you will need to create a Pull Request in order to ask the Zen Cart developer team to review it and consider it for inclusion in core code.
You’ll do this from your browser:
- Go to your Github account in your browser.
- Go to your zencart repository.
- You will see a green “Compare and Pull Request” button. Click it. (If it’s been several hours since you did the push, it might not show the green bar. In that case, click the ‘Branches’ link, where you will see a Pull Request button next to each of your branches. Click the one next to the branch you want to do the pull request from.)
- Now you can review the collection of commits and file changes, and add a descriptive message to the pull request. If you’re fixing something that’s already got an open issue for it, be sure that the issue number is included in your Pull Request message. ie: #101. If you believe your Pull Request fully fixes the open issue, then say “Fixes #101”, as the keyword “Fixes” helps do proper cleanup of tickets once closed.
- TIP: If you are contributing to Zen Cart develop, be sure that your pull request “compare” is indeed being compared against the
- Click the next green button to Create Pull Request
- Now you wait for others to review your code. The Zen Cart developers (and anyone else who has clicked “Watch” on the Zen Cart main repository) will get an alert about the pull request. Anyone wishing to reply with their opinions of what you’ve submitted can engage in dialog with you and one another while the code is reviewed.
- If your code hasn’t complied with the coding standards, or has bugs or is incomplete, you may be asked to submit more commits to rectify the problems. In that case, you will repeat the steps above for making code changes, making commits, and pushing those commits to github. As long as you push to the same branch on github, then all those commits will automatically be included in the pull request, so reviewers can see the updates you push.
- Once the core team decides what to do with it, they have basically three options: to accept it (merge the pull request) or defer it (until a later date) or reject it (not merge it and close the pull request). Github will automatically email you about all updates and comments made about your Pull Request. (NOTE: Your PR won’t be merged until you have signed the CLA.)
Keeping Your Local Branch Current
When you or others make pull requests that are accepted into the Zen Cart core repository, that will make your own local copy be outdated. To keep current, you must periodically bring in the changes from the “upstream remote” we created earlier. (see: https://help.github.com/articles/syncing-a-fork/)
git fetch upstream
git checkout develop(ie: if you’re going to pull changes from the
git merge upstream/develop(merges your local copy with the upstream remote)
git push(brings your forked repository up-to-date)
- Click the Pull button in the top button bar
- For Pull From Repository, choose “upstream” from the pulldown menu
- For Remote Branch To Pull, choose “develop”
- Leave the “commit merged changes immediately” box checked, and the others unchecked.
- Click OK
Cleaning up old branches, or grabbing new branches
From time to time you and others will add or remove branches from the github repositories, and you will want to keep your PC in sync with those.
git fetch upstream
- Click the Fetch button on the button bar
- There are 3 checkboxes. Check them all. (You could opt to not prune/delete any local branches you’ve created, if you want to preserve them to understand your own work history, by unchecking the corresponding box.) (You could also fetch from individual remotes manually, and prune only when fetching from upstream, but never prune when fetching from your own github master)
- Click OK
There are many more great resources explaining how all of this works. Some which you might wish to review include:
© 2014-2018 Zen Cart® Creative Commons 3.0
The SourceTree name is copyright Atlassian. Zen Cart receives no compensation or consideration for recommending SourceTree; we simply find it to be an extremely capable and useful app for beginners and experienced developers alike.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.