Discussion :

[Gluups]

Bonjour tout le monde,

Sur un projet collaboratif j'ai deux Pull Requests à proposer.
Comme j'ai, on va dire, une expérience limitée quant à Git et GitHub, j'y suis allé par étapes.

J'ai cloné le projet sur ma machine, et je l'ai inscrit au contrôle de code source, sur ma machine et sur un dépôt à moi sur GitHub.

Puis j'ai fait mes modifications de code, ça donne ce que je veux, je suis content de moi.

Là où il y a un hic, c'est qu'entre les deux, j'ai complètement oublié de pousser les modifs sur Git. Donc si je fais une intégration maintenant, c'est avec les deux ensemble. Pas vraiment ce que j'avais prévu.

Alors, je me dis que ça risque de donner un résultat plus lisible en recommençant tout.

Pour les modifications de code ce n'est pas la mer à boire, la première prend une minute, la deuxième à tout casser un quart d'heure, c'est d'expliquer qui à la limite prend plus de temps, et ça j'ai gardé à part.

Mais alors c'est les dépôts de code ...

Sur ma machine c'est facile, si je renomme le répertoire de dépôt de sauvegarde, le fameux "distant local", quand je vais de nouveau cloner le projet sur ma machine et l'inscrire au contrôle de code source, j'aurai un dépôt dans l'état initial, il n'y aura plus qu'à faire les modifications et les intégrer.

Pour GitHub, je suis plus dubitatif.
Je me demande si il vaut mieux effacer les fichiers et répertoires de code pour de nouveau les intégrer dans leur état initial, en laissant Git se rendre compte que la documentation est inchangée, ou est-ce qu'il vaut mieux supprimer le dépôt et le recréer, et dans ce cas avec quel délai entre les deux ?

Quand j'aurai fait tout ça et que j'aurai bien mes deux Pull Requests sur mon dépôt GitHub, je suppose que c'est une bagatelle de les proposer sur le dépôt collaboratif ?

Sous-entendu, à chaque étape, valider le principe c'est bien, après il y a aussi la question de comment on fait.

Il y aura des questions que peut-être je poserai après, parce qu'inscrire un projet au contrôle de code source, localement seulement, alors qu'il existe un dépôt de même nom sur GitHub, ce n'est pas aussi évident qu'il y paraît.

[Toulousaing]

RÈGLE-GIT-018

Nom :
COMMITS_NOT_SEPARATED

Symptôme :
Plusieurs modifications indépendantes ont été effectuées avant le premier commit.

Cause :
Les changements n'ont pas été découpés en commits logiques.

Pourquoi ?
Git permet de regrouper ou séparer les changements avant leur publication.

Correctif :
Créer plusieurs commits distincts ou utiliser git reset avant publication.

Confiance :
95 %