diff --git a/_posts/2023-05-20-mediaengagement-technical-docs.md b/_posts/2023-05-20-mediaengagement-technical-docs.md index 0cbbd22..9dbe31e 100644 --- a/_posts/2023-05-20-mediaengagement-technical-docs.md +++ b/_posts/2023-05-20-mediaengagement-technical-docs.md @@ -525,17 +525,25 @@ After your code is reviewed: master - Accepts merges from Features/Issues and Hotfixes + Accepts merges from Features/Issues, Bugs and Hotfixes Features/Issues - topic-* + feature-* Always branch off HEAD of Working + + Bug + + bug-* + + Always branch off Working + + Hotfix @@ -625,25 +633,25 @@ Although likelihood will be less, during the lifespan of the bug development, th If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A bug branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch. ``` -$ git checkout -b bug-id master // creates a local branch for the new bug -$ git push origin bug-id // makes the new bug remotely available +$ git checkout -b bug-id master // creates a local branch for the new bug +$ git push origin bug-id // makes the new bug remotely available ``` Periodically, changes made to `master` (if any) should be merged back into your bug branch. ``` -$ git merge master // merges changes from master into bug branch +$ git merge master // merges changes from master into bug branch ``` When development on the bug is complete, [the Lead] should merge changes into `master` and then make sure the remote branch is deleted. ``` -$ git checkout master // change to the master branch -$ git merge --no-ff bug-id // makes sure to create a commit object during merge -$ git push origin master // push merge changes -$ git push origin :bug-id // deletes the remote branch +$ git checkout master // change to the master branch +$ git merge --no-ff bug-id // makes sure to create a commit object during merge +$ git push origin master // push merge changes +$ git push origin :bug-id // deletes the remote branch ``` ### Hotfix Branches @@ -665,8 +673,8 @@ ___ If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A hotfix branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch. ``` -$ git checkout -b hotfix-id stable // creates a local branch for the new hotfix -$ git push origin hotfix-id // makes the new hotfix remotely available +$ git checkout -b hotfix-id stable // creates a local branch for the new hotfix +$ git push origin hotfix-id // makes the new hotfix remotely available ``` When development on the hotfix is complete, [the Lead] should merge changes into `stable` and then update the tag. diff --git a/_posts/2023-05-21-mediaengagement.md b/_posts/2023-05-21-mediaengagement.md index 554e0f6..c5e0988 100644 --- a/_posts/2023-05-21-mediaengagement.md +++ b/_posts/2023-05-21-mediaengagement.md @@ -102,7 +102,7 @@ location ~ ^/wp-content/uploads/(.*) { git fetch --all git reset --hard origin/master ``` - +For more detail see [Technical Docs - Sync with GitHub](mediaengagement-technical-docs/#syncing-with-github) --- ## Local Development @@ -140,6 +140,7 @@ npm run production ### Git Usage - Always create separate branches for new features or bug fixes. + - For more detail see [Technical Docs - Sync with GitHub](/mediaengagement-technical-docs/#git-usage) - Push to the `master` branch only after code review and testing. For more detailed Git workflows, see [Deployment Workflow](#deployment-workflow).