D'après mon expérience personnelle, le flux de travail qui a le mieux fonctionné pour mon équipe dans le passé consistait à faire en sorte que tous les développeurs partagent une seule branche distante. Dans mon équipe, nous appelons cette branche "master". Notre stratégie de branchement emprunte des idées à cet article : un modèle de branchement de git réussi . Il suffit d'échanger les branches "develop/master" de l'article avec "master/release" et vous avez en gros ma configuration. C'est la même chose, juste étiquetée différemment.
En gros, je laisse tous nos développeurs faire des livraisons à master, mais avec une convention supplémentaire qui consiste à ne faire que des livraisons de fusion. Tout le codage direct se fait sur les branches du sujet. Pour les corrections rapides avec un seul jeu de modifications, il est permis de commiter directement sur master. Mais en général, l'utilisation de branches thématiques locales est fortement encouragée.
De plus, tous les commits vers master doivent être poussés immédiatement, sinon les différences s'accumuleraient et rendraient la fusion plus difficile. De cette manière, la charge de la résolution des fusions incombe au développeur et non au chef d'équipe ou à un logiciel automatisé. C'est la situation idéale puisque c'est la personne qui développe le code qui connaît généralement le mieux ses propres modifications.
Si plusieurs développeurs doivent travailler sur une même branche, j'autorise tous les développeurs à envoyer leurs propres branches à distance sous un chemin spécifique (dans mon cas, il s'agissait de "shared/") afin que les autres puissent tirer et pousser à partir de cette branche.
Quant au serveur de test (serveur CI), il met à jour le master et les branches à partir de celui-ci à chaque exécution du test. Il n'est pas strictement nécessaire de tester sur une nouvelle branche, mais je suis beaucoup plus à l'aise en sachant qu'un morceau de script automatisé ne travaille pas directement sur master.
Si vous venez de svn, le fait d'avoir de petits changements constants sur une branche partagée peut sembler un peu effrayant. N'ayez pas peur, git est généralement très bon pour résoudre les conflits et 90% du temps, un conflit de git merge o git pull ne déclencherait même pas de conflit.
Enfin, veillez à inculquer à vos développeurs l'habitude de commettre souvent, de tirer souvent. Les petits changements incrémentaux aident en fait git à mieux fusionner le code.
