CTD Git Workflow: Sharing Project Work When Each Developer has a Fork of the Code

For many CTD projects, we will use a specific Git workflow. Each developer will have a fork of the code to which they have write access. Write access to the master repository is limited. This workflow is similar to ones used by many companies. The flow is triangular:

1. You receive changes to your repository from the CTD master repository for the project. Some older repositories use “master” instead of “main” as the name for the primary branch. Some teams will also create a development branch.
2. You create changes in a feature branch in your repository and push it to your Github fork of the master CTD repository for the project.
3. You do a pull request. When approved this will merge your changes from your feature branch into the CTD master repository.

You may only have read only access to the CTD master repository for the project. Your changes will be merged by the committers for the project.

Setting up for this Git Workflow

1. Fork the CTD master repository for the project into your own github account.
2. Clone the fork onto your workstation so that you can develop project features.
3. Add an additional github remote repository to your workspace for the project: git remote add upstream <git url of the master repository>
4. Do a git pull upstream main to synchronize with the master repository.

Working on a Feature

1. Do not make edits directly to the master branch. Instead, create a feature branch using git checkout -b <featurename> Note: If you forget, there are ways to save your changes and to get the master branch back the way it was. For example, if you have not committed changes, you can use git stash, then create the feature branch, then do git stash apply.
2. Work on the feature, periodically committing to your feature branch.
3. Periodically push your commits to github, using git push origin <featurename>
4. When the feature is complete, tested, and ready, commit and push it once more.
5. Then, checkout the master branch. You need to get any changes that have been made by your coworkers on the project.
6. Do a git pull upstream main to get those latest changes.
7. Then, git checkout <featurename> to switch back to your feature branch.
8. Do git merge main . This will bring those changes into your feature branch.
9. Sometimes you will get merge conflicts. This happens when you and your coworkers are both making changes to the same files. You need to resolve the merge conflicts by editing each file with merge conflicts. The merge conflicts will be marked, and you have to select whether your lines, your coworker’s lines, or both are to be included. You also need to remove the merge conflict markers.
10. If you fixed merge conflicts in any files, add and commit them to complete the merge.
11. Test one more time to make sure the merge didn’t cause a break and that your feature still works.
12. Push your feature branch to github one more time.
13. Login to github and do a pull request for your feature branch. Include git IDs for project committers in the comment for your pull request so that they can review it.
14. If the review determines that changes are needed, make them to the same feature branch. Then repeat the process of pulling the upstream main into the local main branch, merging the main branch, and resolving merge conflicts, and push your changes once more, marking the requested changes as resolved. Be sure to test as you make changes!
15. Repeat this process until your feature branch has been merged.
16. Checkout your main branch on your workstation.
17. Do a git pull upstream main to pull down your changes into your main branch. You can now delete your feature branch using git branch -d <featurename> .
18. Do a git push origin main to push your changes to your github fork main branch.
19. Time for a new feature branch!