The Issue Driven Project Management process is designed to support small groups of developers who are in the initial stages of building a product, and who are not experts at git and software development project management. In this context, there are certain common git practices that are “antipatterns” in IDPM: they tend to lead to problems in the context of IDPM.
The goal of this page is to warn you away from several git practices that can be useful in certain situations, but frequently cause problems for projects using IDPM.
In IDPM, there is a single repository on GitHub for your project. Members of the project team become a collaborator on that repo, and then clone that repo to their laptop, make changes, and then push their enhancements back to the repository on GitHub.
An alternative approach, used on some large projects, is to create multiple repositories on GitHub by using the “fork” command. Essentially, one or more of the team members create their own personal top-level GitHub repo, and then clone that one and make changes to it. To get their changes back to the “main” repo, they must issue a pull request.
The “fork and pull request” model works well for large projects where there can be large numbers of “untrusted” collaborators, for example in the case of the Linux operating system project. In Linux, the owners want as many people as possible to be able to play with the code and experiment with enhancements, but they also want to prevent these people from changing the code base without a thorough review.
IDPM is not designed for a situation like the Linux project. In IDPM, there are only a small number of collaborators, and they are by definition “trusted”. The “fork and pull request” model makes it harder for the trusted collaborators to actually collaborate, since it is not easy to simply switch to a different branch in order to see what the fellow developer is working on.
Therefore, don’t fork in IDPM
As noted above, pull requests are useful when you are not sure whether your code is appropriate for incorporation into the project. Pull requests are useful to formalize the process of incorporating code into the master branch and allow a prior review.
In the case of IDPM, it is assumed that project members will take responsibility for deciding when their work is ready to be merged into master. Pull requests introduce an extra step into the development process. Since IDPM does not incorporate an explicit code review step, the use of pull requests slows down development without added benefit.
Therefore, don’t issue pull requests in IDPM.
Rebase is an advanced git feature. For a great introduction to rebase, please see git merge vs rebase: what’s the diff?.
The important things to note from this article are:
Rebase offers only “cosmetic” changes to the repository history. In the case of IDPM projects, you don’t benefit from these cosmetic changes.
Rebase is dangerous: you can create havoc for your team members by rebasing inappropriately.
Because rebase has significant risks and no significant benefits in the case of projects suited to IDPM, you should use the standard git merge command to incorporate your changes from a branch back into master.
Therefore, don’t rebase in IDPM.