Section 5.1 Before Beginning, Consider This
One of the great features of GitHub is the promotion of collaboration, adding new things, and improving others’ work. If your repo is public, anyone can contribute to it. But as the repo owner, you have certain authorities. No one will be able to change things officially without your permission. The main branch will only be changed if you (or other moderators) approve it. This emphasizes the importance of branches (so you can test others’ work) and forks (as explored in Section 5.2).
As more people collaborate on a project at the same time, the complexity of the branch and fork system increases. With this, it is important to consider potential conflicts. Especially with larger projects, you could have multiple working on the same area at the same time. If two people decide to change the same part of the project at the same time, which edits win? Who gets the privilege of having their changes incorporated into
main? Sadly, GitHub and Git cannot figure that out by themselves and create a merge conflict, leaving you, the repo moderator, to settle the dispute.Throughout this part, I will guide you through the process of editing with a team while providing warnings and lessons from what I have learned. I should say that the extent of my knowledge of this topic is not as developed as others’ might be. With Git, I find it better to stick with the things I know how to do (add, commit, push, pull, fork, clone, etc.) and if a problem arises, I research how to fix it. As I learn how to correct Git errors, I will update this part of the book and especially Appendix C. Regardless, the focus of this book is on the basics and what you need to know to have a successful workflow. If that’s what you need, read on.
