How to organize teamwork with git?

Question

git

Good evening! Tell me how to organize work for several frontend and backend developers using git ? How to implement branches, local repositories, what is the best way to merge all projects into one?

Answer 1

The organization of the work of any work should begin with the study of the documentation.
Git is no exception. Git seems quite complicated to a beginner (but it's actually very simple). Therefore, you need to start with the fact that everyone needs to be forced to read Pro Git (or the Russian translation of "Git for professionals"). You can not read everything, about half of the book is occupied by information on administration (which is not necessary for an ordinary developer). Therefore, the study time will take a maximum of 5 evenings.
Then 90% of the questions will go away by themselves.
There will be no stupid questions "how to delete a commit", "how to merge correctly", "how to push" and so on, which often slips on the toaster.
From personal experience.
Well, regarding the organization of branching - the canonical GitFlow, or the more successful (in my opinion) GitlabFlow. Or something of your own, git does not impose any restrictions on this.
Believe me, working in a team that does not know how to use git turns into hell and Israel.

Answer 2

It seems to me that it is difficult to give a definite answer here. To begin with, every developer should learn the basic principles and commands of Git. Many times I have encountered (and continue to encounter) the fact that developers memorize 2-3 commands (git commit / git pull / git push) and just hammer them without understanding what these commands do. IDEs make this process even worse, because there you don’t even have to think about what you drive in, the developer just presses a button and gets dirty in the repository. And then in the Slack chat he shouts: “I did everything on a piece of paper! As I was told, I did a git commit and a git push, it's your fucking git screwed up! (In fact, I heard this more than once).
Then you can make a repository, for example, with master branches and branches in which developers add new features (or fix bugs). For example, add-new-image-upload. The so-called feature-branch'i. When finishing work in a feature branch, merge them from master. Aerobatics - do a rebase before the merge, so as not to clutter up the history with useless merge commits. Even more aerobatics is to switch to git-flow, which automates work with master, development, feature branches, hotfixes, release branches. But it's not worth getting ahead of yourself.