intersystems · isc-tleavitt · Oct 16, 2024 · Oct 15, 2024 · Oct 15, 2024 · Oct 15, 2024
diff --git a/README.md b/README.md
@@ -34,6 +34,13 @@
 
 ## Basic Use
 
+### Source Control
+
+For those with less experience using source control, we recommend this [page](/docs/scintro.md) for a quick introduction to source control / change control basics.
+
+### Health Connect Cloud
+git-source control is the recommended source control for Health Connect Cloud. [This page](/docs/hcc.md) covers HCC specific usage of git-source-control, including the recommended development workflow, initial setup, and CICD pipelining.
+
 ### Studio
 Add a file for tracking by right-clicking on it in the workspace/project view and choosing Git &gt; Add.
 This same menu also has options to remove (stop tracking the file), discard changes (revert to the index), or commit changes.

diff --git a/docs/expert.md b/docs/expert.md
@@ -0,0 +1,42 @@
+### Feature branches
+
+The first step in making changes in Health Connect Cloud using git-source-control is making a feature branch. In order for changes to be tracked by source control properly, each change (also called a feature) should be made on it's own branch, so as to not interfere with other changes, and allow for testing of its effects on the production environment. To create a new feature branch, navigate to the Git UI in the namespace you plan on doing development. 
+
+First, make sure that you are in the development branch. It should be bolded and at the top of the Local Branches in the sidebar. If it is not, as pictured below, click on the "development" branch and press checkout branch.
+
+![Development branch in Git UI Sidebar](images/hcc/developmentsidebar.png)
+
+Once you are in the development branch, press the "+" next the the Local Branches tab, and create a new branch by typing out a name for it. (No spaces or special characters are allowed in branch names).
+
+![Creating a new via sidebar](images/hcc/newbranch.png)
+![Naming new branch](images/hcc/newbranchnaming.png)
+
+Finally, you should click on the new branch you just made in the sidebar, and then press "Push".
+
+![Push your new branch](images/hcc/pushbranch.png)
+
+This makes sure that your branch will be tracked in Gitlab, so that other users can checkout your branch to test your changes on their own namespaces.
+
+After this, you can start working on the change.
+
+### Merge Requests
+
+Once you have made all the changes for the specific feature you are working on, and have tested in your namespace, it will be time to merge all of these changes into the development branch. To start, make sure that all your changes have been commited to your feature branch. To do this, navigate to the Git UI, and after making sure you are in the right feature branch, press the "Workspace" tab at the top of the sidebar. 
+
+![Workspace tab in the sidebar](images/hcc/sidebar.png)
+
+This will bring you to the workspace view. All the changes you made to files should be in the bottom left of the workspace view. ![Changed files in workspace](images/hcc/workspacechanges.png)
+
+Clicking on one of these files will bring up a line by line view of the changes that have been made. Make sure that these are the changes you want to make, and then select all the files. Next, enter a commit message that should describe that changes that have been made. 
+
+![Enter commit message](images/hcc/commitmessage.png)
+
+You can enter more details below, and then press the commit button underneath. This will commit the changes you have made to your feature branch. Once all of your changes have been committed, you should be ready to merge into the development branch.
+
+In the Git UI, first checkout the development branch, by selecting it from the Local Branches and pressing "Checkout branch". Next, find the feature branch that you have been working on, select it from the local branches, and press "Merge Branch". 
+
+![Merge Branch](images/hcc/mergebranch.png)
+
+
+
+
diff --git a/docs/hcc.md b/docs/hcc.md
@@ -0,0 +1,39 @@
+# git-source-control for Health Connect Cloud Overview
+
+## Development Workflow
+
+git-source-control has two main use modes: Basic and Expert. For Health Connect Cloud, we recommend beginning with basic mode, since it includes all of the necessary functionality for proper source control development while being easy to use for those with little development / source control experience. The recommended workflow for Health Connect Cloud is to create interface branches, create merge requests into development, and then pull the changes into the shared development namespace. The rest of this section explains this workflow more in depth for those with less source control experience. 
+
+
+### Interface branches
+
+The first step in making changes in Health Connect Cloud using git-source-control is making an interface (feature) branch. In order for changes to be tracked by source control properly, each change (also called a feature) should be made on it's own branch, so as to not interfere with other changes, and allow for testing of its effects on the production environment. To create a new feature branch, use the source control menu and select "Create new branch".
+
+![Creating a new branch](images/hcc/newbranchmenu.png)
+
+You will be prompted to enter a name for your new branch (no spaces or special characters), after which your environment will switch to that new branch. All new branches are fresh copies of the development branch.
+
+### Making changes
+
+Now that you are in your new branch (you can see which branch you are in in the source control menu), you can start making changes. As you make changes to different business processes, rules, and productions, make sure that all of these changes are saved properly before you try to sync and merge.
+
+### Syncing and Merge Requests
+
+Once you have made all the changes for the specific feature you are working on, and have tested in your namespace, it will be time to merge all of these changes into the development branch.
+
+To start, press the sync button from the source control menu. 
+
+![Sync option in menu](images/hcc/sync.png)
+
+This will bring up the sync interface, where you are able to see all the of the files you have changed, as well as add a descriptive comment for the changes you made. When you sync, these changes will be pushed to the git remote.
+
+![Sync Interface](images/hcc/syncinterface.png)
+
+Use the link in the output of the sync in order to create a merge request in the git remote (don't worry if you close out of the sync tab, you can also navigate to GitLab manually). Here, you should make sure that you are merging your interface branch into the development environment, and notify / add the relevant reviewers. Once this merge request is approved, it will be merged into the development branch, so that all of your changes will now be a part of development.
+
+### Pull
+
+In for the changes in development to be reflected in your namespace, you should swicth to the development namespace from the GitUI, and then access the git pull page (from the favorites bar), and pull any changes. You should see the changes you made now reflected in your local namespace again. It is good practice to git pull every once in a while to make sure that your local development branch is up to date with all of the changes made to the remote development.
+
+
+
diff --git a/docs/images/basicmodesetting.png b/docs/images/basicmodesetting.png
diff --git a/docs/images/hcc/commitmessage.png b/docs/images/hcc/commitmessage.png
diff --git a/docs/images/hcc/developmentsidebar.png b/docs/images/hcc/developmentsidebar.png
diff --git a/docs/images/hcc/mergebranch.png b/docs/images/hcc/mergebranch.png
diff --git a/docs/images/hcc/newbranch.png b/docs/images/hcc/newbranch.png
diff --git a/docs/images/hcc/newbranchmenu.png b/docs/images/hcc/newbranchmenu.png
diff --git a/docs/images/hcc/newbranchnaming.png b/docs/images/hcc/newbranchnaming.png
diff --git a/docs/images/hcc/pushbranch.png b/docs/images/hcc/pushbranch.png
diff --git a/docs/images/hcc/sidebar.png b/docs/images/hcc/sidebar.png
diff --git a/docs/images/hcc/sync.png b/docs/images/hcc/sync.png
diff --git a/docs/images/hcc/syncinterface.png b/docs/images/hcc/syncinterface.png
diff --git a/docs/images/hcc/workspacechanges.png b/docs/images/hcc/workspacechanges.png
diff --git a/docs/scintro.md b/docs/scintro.md
@@ -0,0 +1,22 @@
+# A Brief Introduction to Source Control
+
+Source control, or change control, is a system that helps teams manage and track changes to their work, with particulaar relevancy to software development. It helps produce a definitive record of the hostory of the product, as well as allow for revisiting earlier versions and previous changes. This means that multiple people can work on the same thing together without getting in each other's way. You can see who made changes, when they were made, and what these changes were addressing. If any change leads to issues, this allows teams to quickly roll back to a previous version that is working, as well as identify which specific change may have caused the issue.
+
+## Key Concepts
+
+### Versioning
+
+Each change or batch of changes is saved as a new version. This allows users and developers to reference or revert to previous versions when necessary (git-source-control is itself versioned)
+
+### History Tracking
+
+Since every change is logged, source control provides users with a complete history of a project, allowing anyone to track its evolution, as well as pinpoint causes and the nature of issues that may arise
+
+### Branching
+
+Branching involves creating distinct copies of the same product, so that changes can be made and tested in isolation, without affecting other users and changes. These "branches" can be merged to bring changes back to the main product.
+
+
+### Example of source control
+
+A teammate and I are working on an article. I am focusing on the introduction and conclusion, while they focus on the main paragraph. To avoid conflicts, we create seperate copies (branches) of the article to work on. When I am finished with my work, I can merge the changes I have made back into the main article. Others can see the exact changes I have made, and if anyone else is working on the same section we won't run into problems because I have my own separate copy.