Skip to content

Advanced Editing

Jump to bottom
Luna edited this page Dec 3, 2019 · 1 revision

This is the more cut-and-dry, techie-oriented doc around editing the site. Is it useful to have as part of the docs?

Editing

If you haven't already gone through the Basic Editing and Files & Directories Guide, and Building & Serving the Site docs, you should probably do read those the first.

Main Workflow

Now that we're set up, we can work on the changes locally, push them to staging, and then once all is good, push to the production site.

  1. Run git fetch --all to get a record of any changes that were made to the branches currently on your local environment. This will show you something like the following:
Fetching origin
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.

## Here's the part we're looking for ##
From https://github.com/pgpglobal/PGPGlobal
   06e5b6e2..7c70bbb3  master     -> origin/master
   06e5b6e2..7c70bbb3  gh-pages   -> origin/gh-pages
Fetching staging
From https://github.com/pgpglobal/staging
   8423748e..7c70bbb3  gh-pages   -> staging/gh-pages

Whichever branches have been changed will show up here. So in the example above, the following have changed:

  • origin/master
  • origin/gh-pages
  • staging/gh-pages

Most of the time after doing this, you should just be able to git pull (fetch and merge changes). The exception will be if you have changed a file locally and the file has separately been changed on the remote repo. If you run into that, see Using Git - Solving Merge Conflicts.

  1. Create a branch for the feature you're working on. Ex: if you're working on a post, you might type git checkout -b abbrev-post-name. If you're making changes to the menu, you might type git checkout -b luna-nav-menu or nav-menu-fix, etc.
  2. Once you've made your changes, run bundle exec jekyll serve to test it out locally
  3. If everything looks good, then switch to staging, merge the new changes, and push to staging/gh-pages. Example:
# Let's say we named our branch new-feature

# Go back to the main staging branch
git checkout -b staging

# Bring in the new changes
git merge new-feature

# Push the changes to the staging site.
# If you set push.default earlier, then simply git push
# Otherwise:
git push staging HEAD:gh-pages

Alternate Workflow

Note: If you think you're going to have multiple people working on new staging features at the same time, and are worried about running into merge conflicts, then instead you can do as follows:

  1. Make the new feature branch git checkout -b new-feature
  2. Make your changes
  3. Test locally via bundle exec jekyll serve
  4. Push the new-feature branch to the remote staging repo. Ex: git push new-feature staging/new-feature
  5. Sign into the GitHub Repo and make a Pull Request to integrate the new feature into the main branch. You'll need a maintainer to do this.

I think this alternative workflow may ultimately be redundant, as long as everyone is running git pull and/or git fetch properly

Finalize Changes

After everything looks great on the staging site, and you've incorporated everything into the (local) staging branch, then push those changes to the (remote) staging/master branch. This serves as a backup, so that if something gets messed up later with the gh-pages branch, we have a stable working version of the site.

Incorporate Changes to Production Site

  1. Return to your (local) master branch git checkout master
  2. Merge the changes from the staging site git merge staging
  3. Test that the changes are working correctly via bundle exec jekyll serve
  4. If everything's working correctly then git push origin master, and setup a pull request on GitHub
  5. The project maintainer can then pull those changes into the (remote) master branch, and once that's ready can push them to the gh-pages.

If you want to make this less redundant, then people can simply do git push origin master and the maintainer can git pull origin master, make sure everything's working fine and then git push origin gh-pages

Clone this wiki locally