Bifurcation et branchement dans GitHub

Question

J'aimerais en savoir plus sur les avantages et les inconvénients de la bifurcation d'un projet github par rapport à la création d'une branche d'un projet github.

La bifurcation rend ma version du projet plus isolée de l'original car je n'ai pas besoin d'être sur la liste des collaborateurs du projet original. Comme nous développons un projet en interne, il n'y a aucun problème à ajouter des personnes en tant que collaborateurs. Mais, nous aimerions comprendre si le fait de bifurquer un projet rendrait plus difficile la fusion des modifications dans le projet principal. En d'autres termes, je me demande si le fait de bifurquer rend plus facile le maintien de la synchronisation entre les deux projets. En d'autres termes, est-il plus facile de fusionner et de pousser les modifications entre ma version du projet principal et le projet principal lorsque je crée une branche ?

Answer 1

Vous ne pouvez pas toujours créer une branche ou tirer une branche existante et pousser vers elle, car vous n'êtes pas enregistré en tant que collaborateur pour ce projet spécifique.

La bifurcation n'est rien d'autre qu'un clone. du côté du serveur GitHub :

• sans possibilité de repousser directement
• avec queue de fourche Ajout d'une fonctionnalité pour gérer la demande de fusion

Vous gardez un fork en synchronisation avec le projet original en :

• ajouter le projet original en tant que projet distant
• en récupérant régulièrement des données de ce projet original
• rebasez votre développement actuel sur la branche d'intérêt que vous avez mise à jour à partir de cette récupération.

Le rebasement vous permet de vous assurer que vos modifications sont simples (pas de conflit de fusion à gérer), ce qui facilite votre demande de retrait lorsque vous souhaitez que le responsable du projet d'origine intègre vos correctifs dans son projet.

Le but est vraiment de permettre la collaboration même si direct La participation n'est pas toujours possible.

---

Le fait que vous clonez du côté de GitHub signifie que vous avez maintenant deux dépôt "central" ("central" comme "visible depuis plusieurs collaborateurs").
Si vous pouvez les ajouter directement en tant que collaborateur pour un projet, vous n'avez pas besoin d'en gérer un autre avec une fourchette.

L'expérience de fusion serait à peu près la même, mais avec un niveau supplémentaire d'indirection (pousser d'abord sur le fork, puis demander un pull, avec le risque d'évolutions sur le repo d'origine rendant vos fusions rapides plus rapides).
Cela signifie que le flux de travail correct consiste à git pull --rebase upstream (rebasez votre travail sur les nouveaux commits en amont), puis git push --force origin afin de réécrire l'historique de manière à ce que vos propres commits soient toujours au-dessus des commits du repo original (en amont).

Voir aussi :

• Git fork est un clone de git ?
• Tirez les nouvelles mises à jour du dépôt Github d'origine vers le dépôt Github d'origine.

Answer 2

Voici les différences de haut niveau :

Bifurcation

Pour

• Maintient les branches séparées par utilisateur
• Réduit l'encombrement dans le référentiel primaire
• Le processus de votre équipe reflète le processus des contributeurs externes

Cons

• Il est plus difficile de voir toutes les branches qui sont actives (ou inactives, d'ailleurs).
• La collaboration sur une branche est plus délicate (le propriétaire de la branche doit ajouter la personne en tant que collaborateur).
• Vous devez comprendre le concept de remotes multiples dans Git.
  • Nécessite une comptabilité mentale supplémentaire
  • Cela rendra le flux de travail plus difficile pour les personnes qui ne sont pas très à l'aise avec Git.

Branchements

Pour

• Conserver en un seul endroit tous les travaux effectués dans le cadre d'un projet.
• Tous les collaborateurs peuvent pousser sur la même branche pour y collaborer.
• Il n'y a qu'une seule télécommande Git à gérer.

Cons

• Les branches qui sont abandonnées peuvent s'empiler plus facilement
• Le processus de contribution de votre équipe ne correspond pas à celui des contributeurs externes.
• Vous devez ajouter les membres de l'équipe en tant que contributeurs avant qu'ils puissent créer des branches.

Answer 3

Cela a à voir avec le flux de travail général de Git. Il est peu probable que vous puissiez pousser directement vers le dépôt du projet principal. Je ne suis pas sûr que le dépôt du projet GitHub supporte le contrôle d'accès par branche, car vous ne voudriez pas accorder à quiconque la permission de pousser vers la branche master par exemple.

Le schéma général est le suivant :

• Fork le dépôt du projet original pour avoir votre propre copie GitHub, à laquelle vous serez alors autorisé à pousser des changements.
• Clonez votre dépôt GitHub sur votre machine locale.
• En option, ajoutez le référentiel d'origine comme un référentiel distant supplémentaire sur votre référentiel local. Vous pourrez alors récupérer directement les changements publiés dans ce référentiel.
• Faites vos modifications et vos propres commits localement.
• Poussez vos modifications vers votre dépôt GitHub (car vous n'aurez généralement pas les droits d'écriture sur le dépôt du projet directement).
• Contactez les mainteneurs du projet et demandez-leur de récupérer vos modifications et de les réviser/fusionner, et laissez-les pousser vers le dépôt du projet (si vous et eux le souhaitez).

Sans cela, il est assez rare que les projets publics permettent à quiconque de pousser directement ses propres commits.

Answer 4

La bifurcation crée un dépôt entièrement nouveau à partir d'un dépôt existant (il suffit de faire un clone git sur gitHub/bitbucket).

Les fourches sont utilisées au mieux lorsque l'intention de la "scission" est de créer un projet logiquement indépendant, qui ne pourra jamais être réuni avec son parent.

La stratégie de branche crée une nouvelle branche sur le référentiel existant/travaillant.

Les branches sont utilisées au mieux : lorsqu'elles sont créées comme des endroits temporaires pour travailler sur une fonctionnalité, avec l'intention de fusionner la branche avec l'origine.

Plus spécifique :- Dans les projets open source, c'est le propriétaire du référentiel qui décide qui peut pousser vers le référentiel. Cependant, l'idée de l'open source est que tout le monde peut contribuer au projet.

Ce problème est résolu par les fourches : chaque fois qu'un développeur veut modifier quelque chose dans un projet open source, il ne clone pas directement le dépôt officiel. Au lieu de cela, il le bifurque pour créer une copie. Lorsque le travail est terminé, il fait une demande de reprise (pull request) afin que le propriétaire du dépôt puisse examiner les modifications et décider de les intégrer à son projet.

À la base, la bifurcation est similaire à l'embranchement de fonctionnalités, mais au lieu de créer des branches, une bifurcation du dépôt est faite, et au lieu de faire une demande de fusion, vous créez une demande de pull.

Les liens ci-dessous fournissent la différence de manière bien expliquée :

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html