Last chapter, we discovered Issues and used them to plan our project. We also learned how to link our commits to issues, so that we can follow each change in our project. Our way of work was simple: choose an issue, make a commit that can resolve it, and push to GitHub. The issue was then resolved and closed. But this way of work is not very adapted in most real-world projects; the potential of screw-ups is too high.
What if you need more than one commit to resolve an issue? What if other team members pushed a commit that contained changes to the same files ...