As described in Managing Conflicts, creating conflicts is inherent to several persons working on copies of the same code or document, but probability of conflicts can significantly be reduced.
Without doing exact calculations, it is obvious that working in parallel for long periods is increasing chances for conflicts.
So one method for keeping the number of conflicts low is minimizing the time period between creating a feature branch and merging it back into develop.
Several persons working in parallel does not necessarily mean creating conflicts, if these persons would work on different parts of the code.
Unfortunately, Git doesn't indicate the code segments, which are currently under change in separate branches.
The following proceeding is recommended and also described in the step-by-step guidelines for Documenting an Issue, Processing an Issue and Completing an Issue:
- Create Issues for describing fixes, but also features!
- Assign every Issue to exactly one person and take care that persons are working on separate parts of the code.
- Keep the scope of the individual Issue small (effort for 30 minutes up to 1 day in maximum).
- Exclusively work on Issues that are assigned to yourself (if necessary change the assignment, but coordinate this step with the former assignee).
- Before starting to work, read the Issue in deep detail and add notes about all necessary changes.
- When starting to work, update your local develop branch first, and create a fresh feature branch for Processing an Issue from your updated local develop branch second.
- Focus on a single Issue at a time and keep going until all necessary changes have been completed.
- Double check completeness and correctness of the changes.
- Replicate your local feature branch to Github.
- Create a Pull-Request from the remote feature branch into the remote develop branch right after Completing an Issue.
- Define a team member to be Reviewer. If you wouldn't be CodeOwner, the CodeOwner should be automatically listed as Reviewer.
- Assign the Pull-Request to the person, who shall consolidate potential feedback and execute the Merge.
- Deal with the feedback as soon as some has been provided.
- If a second review would be required, don't forget to push the circular arrows.
- As soon as all comments have been resolved, merge the remote feature branch into the remote develop branch.
- Delete the remote feature branch.
- Make sure the underlaying Issue has been closed.
- Delete the local feature branch.
Additional hints:
- Github produces a lot of emails. Your Reviewer might overlook the request for review. Potentially, it make sense sending a separate email with a little bit of useful information and a direct link into the Pull-Request.
- Be frugal with appointing Reviewers. Reviewing is work. If you would appoint several Reviewers, you wouldn't know, who is actually active. In worst case, you would do the Merge while some Reviewers are still in the process.
- If you would have been appointed to be Reviewer, conclude the review as soon as possible. Chances of conflicts are constantly increasing until the Merge. Often, the CodeOwner would like to start working on the next Issue, but can't until the current one has been merged.
Over the intention of creating small packages, it shall not been forgotten that the develop branch shall always contain an executable code.
It is not planned to merge partly solved problems or half of an Issue.
In rare cases, it is maybe unavoidable to work on an Issue for several days and create a lot of changes until an executable contribution to the develop branch is ready for merging.
In such case, at least the second root cause of conflicts (changes, which have been made by other members of the team) should be actively managed by merging the latest status of the develop branch into the local feature branch on a daily base.
It is recommended to do this before continuing working in the local feature branch.
<- Back to Managing Conflicts - - - Up to Preparing for Specifying Applications - - - Ahead to own GitHub account ->