J'ai peut-être pas vraiment les yeux en face des trous ce matin, mais je comprend pas bien pourquoi faire ça.
Pourquoi faire ça : je ne sais pas, c'était dans la doc :-)
J'ai bien compris qu'il y avait des commandes simplifiées. Mais cela ne fait pas de mal de connaître un peu le fonctionnement interne. En l’occurrence, le paragraphe qui te choque est exécuté une seule fois à la création. Moi ça ne me pose pas de problème :-) Personnellement, j'aime bien avoir une vue (même partielle, mais des bases) de ce qu'il y a sous le capot pour réagir plus vite en cas de problème. Les notions de work dir, cache, tree sont à mon sens essentielles pour comprendre ce que l'on fait. D’où les premiers paragraphes.
Donc c'est quoi ton workflow ?
Un serveur central de référence.
Des développeurs qui synchronisent régulièrement (au moins 1 fois / jour) leur développement sur le serveur.
Quand les développeurs sont satisfaits de leur travail (code fonctionnel, testé), il faut un processus de réconciliation (merge).
La je sèche un peu... entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?
Si tu as un dépôt git il suffira d'ajouter une nouvelle remote pour pouvoir envoyer tout le dépôt.
[^] # Re: git
Posté par ghusson (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 0.
Pourquoi faire ça : je ne sais pas, c'était dans la doc :-)
J'ai bien compris qu'il y avait des commandes simplifiées. Mais cela ne fait pas de mal de connaître un peu le fonctionnement interne. En l’occurrence, le paragraphe qui te choque est exécuté une seule fois à la création. Moi ça ne me pose pas de problème :-) Personnellement, j'aime bien avoir une vue (même partielle, mais des bases) de ce qu'il y a sous le capot pour réagir plus vite en cas de problème. Les notions de work dir, cache, tree sont à mon sens essentielles pour comprendre ce que l'on fait. D’où les premiers paragraphes.
Un serveur central de référence.
Des développeurs qui synchronisent régulièrement (au moins 1 fois / jour) leur développement sur le serveur.
Quand les développeurs sont satisfaits de leur travail (code fonctionnel, testé), il faut un processus de réconciliation (merge).
La je sèche un peu... entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?
Tu peux détailler STP ?