Version Control / GitHub
Training Links:
| Training Name | Link | Training Type | Author |
|---|---|---|---|
| Getting Started with GitHub | https://docs.github.com/en/get-started | Background information, links, | GitHub |
| Branch what? And another git/BitBucket/github terms | https://github.com/USACE/cwms-data-api/wiki | Background information, links, | Mike Neilson |
| Intro to GitHub Session 1 of 2 | 2023-06-12_Intro_to_Git_GitHub_Part1of2 | basic introduction and demo of working with GitHub | Charles Graham |
| Intro to GitHub Session 2 of 2 | 2023-06-20_GitHub_WorkingSession_Part2of2 | basic introduction and demo of working with GitHub | Charles Graham |
Git Information Sharing 1 |
| Intro to Git and Git workflow | YouTube Video |
Git Information Sharing 2 |
| Intermediate and advanced Git topics | |
| Source Code Version Control | Intro to using version control for Water Management Web Sites | Charles Graham |
Common GitHub / Git Workflow
- Create an issue about it on the issues page of a given remote repository (repo)
- Solicit the issue to parties/teammates for discussion (link to it)
- Decide who works on this and assign it to yourself/that person in GitHub so others do not also work on it
- Click the "create branch" button on the right side of the issue to link a branch to the issue for tracking purposes
- Pull that branch down to your local system. Commit. Make changes. PUSH to GitHub (remote repo) as needed, especially if you work on other computers too
NOTE: Normally one person works on one issue at a time and in one branch. This avoids conflicts. You can work in the same branch if you chose. But circles back to conflicts - Once changes are done, or needing guidance or review, create a Pull Request (PR) to merge the feature/bug branch you made INTO
dev (MAIN branch)
NOTE: SQUASH and MERGE INTO dev (MAIN branch) to reduce number of commits in the primary 3 branches (dev > test > prod)
NOTE 2: DELETE the branch once you are done with the PR as to not pollute branches on GitHub with orphaned branches. You can always make new branches. (You can also delete the branch locally in VSCode, up to you)
NOTE 3: DRAFT PR - If you want to submit work to show you've done it but you are not ready for it to be fully reviewed. Create a DRAFT PR and mark it as ready when the time comes! - Confirm working in CWBI DEV
- Then make a PR to CWBI-TEST if all is well, otherwise go back to step 1 (DO NOT SQUASH AND MERGE for TEST or PROD MERGES)
- Test changes in CWBI-TEST (against that CDA with more real-world data)
- If issues, go back to step 1 and complete the process through to Step 9 again
- Create a PR from CWBI-TEST to CWBI-PROD
The PR in between dev and test and test and prod are purely just to test the various environments on the WAY to production.
Your major changes can happen frequently in alternate branches.
The fourth "environment" is called your LOCAL. Each of these environments can target specific files which can set environment variables for that given place in the pipeline.
To read more about environment variables for water management district offices visit: Environments