Set up your workspace
Git keeps workspaces organized by branches, and that organization will help simplify the process of submitting to Push. Fortunately, once you’ve created and checked out a branch, you don’t have to think too much about branches (except when it’s time to create your next submission or fix).
On Your Computer
You’ll do this each time you want to start work on a new submission/contribution.
Once you have your copy of Push, change into the directory where it’s stored on your computer (
~/Projects/push/, if you’re following the instructions here):
$ cd ~/Projects/push
git branchcommand to learn which branch you are on, and which other branches are in your copy of the Push repository:
$ git branch * master
In Git, work always takes place on a particular branch. Branches function like separate timelines or alternate universes for the files that make up a project, like Push. When you first clone Push, you’ll have access to its
masterbranch. Think of the
masterbranch as the official, approved version of Push.
To prepare a submission, you’ll create your own branch to work on. Don’t do any work on the
masterbranch itself; it’ll simplify your life if you leave it to only contain the official version of Push. For example, to set up your workspace to begin writing an article submission to Push, you’ll set up a
submissionbranch for yourself to work on:
$ git branch submission
git branchagain, and you’ll see that Git now lists a
$ git branch * master submission
To actually do work on your
submissionbranch, you’ll need to check the branch out. “Checking out a branch” is just Git’s phrase for switching to a branch:
$ git checkout submission Switched to branch 'submission'
You can always see which branch you’re currently working on by running
$ git branch master * submission
Just look for the branch with an asterisk (
*) next to its name.
Branches for Blog Posts or Features/Fixes to Push
If you’re working on a blog post for Push, you would want to create a branch just for that purpose. Always create your branches off of the
masterbranch, so that you’re working with only the official copy of Push. First, checkout the
$ git checkout master Switched to branch 'master'
You can then create a branch for your blog post:
$ git branch blogpost $ git checkout blogpost Switched to branch 'blogpost'
Or, to create and checkout a branch at the same time, just run
git checkout -b blogpost:
$ git checkout -b blogpost Switched to a new branch 'blogpost'
If you’re planning to submit a fix or new feature to the core files of the journal (layouts, stylesheets, etc.), use the same procedures described above, but keep the name of your branch descriptive of the change you’re making. For example, if you’re making some fixes to the typographic styles of Push’s pages, you might do something like this:
$ git checkout master $ git checkout -b typography Switched to a new branch 'typography'
Be sure to keep each feature fix in its own branch, and always create any new branch off of
master. Read how to keep
masterup to date with the main Push repository.
With a branch created and checked out for you to work, you can begin writing in YAML and Markdown for your blog post or article submissions.