0-readme edit
git-usage edit
Git Process & Walkthrough
Branch Overview
prod- Deploys to the live Prod site (https://www.wm.edu). Gets pushed to GitLab then manually deployed from GitLabtest- Deploys to the Test site (https://test-www.wm.edu) automatically when pushed to GitLab. Used to accurately review pending updates to the Prod site. Needs to be (ideally) identical toprod+ the feature to be reviewed.atomic-docs-dev- This entire Atomic Docs app and W&M test site is also on the creative-test server so features can be reviewed without needing to merge/deploy to the Test site. It used to deploy automatically when pushed but that is currently broken so I have been manually uploading to the server using SFTP.- development branches - Created as-needed for work on updates or features, see Development Steps
Development Steps
I highly, highly recommend the VS Code extension GitLens.
-
Create a new feature/update/bugfix branch
-
Start on
prodbranch. Make sure you have the latest code:git pull origin prod -
Use this code to create a new branch and check it out at the same time.
git checkout -b tempDevBranchTip: I name my branches this way:
mmdd-parentBranch-taskDescriptionUsingVerb
for example: 0218-prod-updateHeadingSpacing
-
-
Make updates on new branch
- If coming from another branch, switch to the new one first:
git checkout tempDevBranch -
Commit any time you have completed a cohesive " chunk" of work. Committing frequently makes it easier to go back and fix things if necessary.
DO NOT commit the prod/main.css or prod/main.css.map files.
These files tend to cause the most conflicts when merging and get rewritten by Scout when switching to a new branch anyways. Only commit them after a merge into test or prod so they will get deployed.To keep them from being commited, unstage them, then commit the rest. When leaving to switch to another branch, they can safely be discarded since they will be created again by Scout when switching back to the branch.
To add all changed files and commit them all at the same time:
git commit -am "short description of work done"If you have made multiple changes that should go in different commits, you can add them separately and then commit.
git add path/to/file path/to/another/file
git commit -m "Message for this commit"
or you could use the awesome VS Code GitLens extension and add/commit using that. - (Recommended) At the end of each work day push your dev branch(es) to GitLab. That way there is a record of your work off of your computer in case something were to happen. Both the dev branch and remote dev branch can be deleted when they are no longer needed.
- If coming from another branch, switch to the new one first:
-
Review changes on Test site or Atomic Docs Dev site
- Test site
The
testandprodbranches deploy to AWS. There is generally not a caching issue, but if there is you can go into /_theme/formats/head_base and change the query number on the link to the main.css stylesheet and then publish head_base.
git checkout test
git merge tempDevBranch
Resolve any conflicts and QA locally, if necessary.
git push origin test
You can go to Atomic Doc GitLab Pipelines to watch the deploy status. - Upload to Creative Test site (optional)
If necessary, for code review outside of a Cascade server, you can manually upload to the creative-test server:
sftp://uwad-php72-00.it.wm.edu/var/www/creative-test.wm.edu/public_html/atomic-docs-dev.
- Test site
- Once approved, send changes to Prod
-
To update the live site, we start by merging the
testbranch intoprodand deploying. -
git checkout prod
git merge test
Resolve any conflicts and QA locally, if necessary.
git push origin prod - Go to Atomic Doc GitLab Pipelines and click on Skipped -> Deploy, to deploy to Prod site.
- QA Prod site
When something is caught by QA, create a temporary branch off ofprodto fix, then use that branch to repeat these steps from the start (merging intotest, etc).
-
- Delete the temporary development branch
git branch -d tempDevBranch
GitLab
Configuration of how the code gets deployed in Gitlab is set up in the /gitlab-ci.yml file. IT can help with this, if needed.
Git Conflicts
Sometimes you will run into a conflict with the main css file. It will look somethink like this:
This happens when the css has been saved in a different format, expanded vs compressed for example. The solution is to add a space in a scss file and save which will cause Scout to recompile the files. Then git commit -am "css conflict fix" will fix it.
Most of the time, however, I simply don't include the main.css and .map files when commiting on branches other than test and prod.