In a practicum, a team of developers shares access to a single Git repository. This can create problems. Several team members may change a given piece of code, with the result that conflicting changes are introduced. The links below describe processes that minimize the potential for conflict and that provide a way to resolve code conflicts if they occur.
There are two such processes, but the flow is similar in both.
Most practicums use the open source process. In this process, each team member has a fork of the code. The local git repository on each team member’s machine is connected to two remote repositories, typically named origin and upstream. Most team members only have read access to the upstream repository. The origin repository is that team member’s fork of the upstream repository. One or several reviewer/committers has write access to the upstream repostory. A triangular flow is created, where team members pull from the upstream repository, push feature branches to their origin repository, and create pull requests from their feature branches of the origin repository to the main branch of the upstream repository. A reviewer/committer then reviews the pull requests, and when one is approved, merges it with the main branch of the upstream repository.
Some practicums and most Code the Dream internal projects use the closed source process. This process is used when we don’t want the code to be publicly available. There are no forks of the code. Instead, there is only one remote repository that resides on the Code the Dream or the Code the Dream Students github account. Team members are given read/write access to this repository, except for the main branch, for which they have read/only access. Only reviewer/committers can write to the main branch. A triangular workflow is created where team members pull from the main branch, push feature branches, and create pull requests from their feature branches to the main branch. A reviewer/committer then reviews the pull requests, and when one is approvide, merges it with the main branch.
Ideally, one would not have several team members working on the same files at the same time. But this is not always possible. When several team members make changes to the same file, a merge conflict can occur. A pull request from the first of these team members may be merged into the main branch, but a pull request from another team member will show the merge conflict. That team member must then resolve the merge conflict before their pull request can be approved.
The open source process is described here.
The closed source process is described here.
A video explaining how to resolve merge conflicts is available here.