On n'a pas la même notion de "vite fait". Ce que tu décris ici est une catastrophe, c'est pas du tout la bonne façon de faire. Moi qui utilise GIT au quotidien depuis 5 ans (sur un dépôt centralisé figure-toi) j'y comprends rien à tes commandes !!!
Le mot clé que tu cherches, c'est "bare". Il te faut créer un "bare" repo. Ce repo, on ne peut pas y travailler dedans. Il est juste là pour être LA référence (c'est le côté "centralisé" que tu recherches je pense).
Avec ta casquette de chef de projet, tu crées le repo, tu te choisis ta politique de branches (si il y en a), de tags (c'est à dire de version de ton soft) etc.
Quand tu prends ta casquette de développeur, tu vas cloner ce repo (c'est là où on dit que GIT est décentralisé, en tant que développeur tu vas récupérer l'intégralité de l'historique, c'est un vrai clone), y travailler dedans, tester, re-travailler, débugger, puis quand ta modif est belle, pusher vers ton repo "bare" tes modifs.
Le tout en utilisant 3 ou 4 commandes GIT de base : init, clone, push, merge (et encore, tu peux très bien vivre sans merge).
Quand on dit "GIT est décentralisé", c'est une technologie, pas un workflow.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Bookmak pour vraiment se mettre à GIT
Posté par gUI (Mastodon) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 7. Dernière modification le 25 novembre 2016 à 08:09.
On n'a pas la même notion de "vite fait". Ce que tu décris ici est une catastrophe, c'est pas du tout la bonne façon de faire. Moi qui utilise GIT au quotidien depuis 5 ans (sur un dépôt centralisé figure-toi) j'y comprends rien à tes commandes !!!
Le mot clé que tu cherches, c'est "bare". Il te faut créer un "bare" repo. Ce repo, on ne peut pas y travailler dedans. Il est juste là pour être LA référence (c'est le côté "centralisé" que tu recherches je pense).
Un lien : https://git-scm.com/book/fr/v2/Git-sur-le-serveur-Mise-en-place-du-serveur
Avec ta casquette de chef de projet, tu crées le repo, tu te choisis ta politique de branches (si il y en a), de tags (c'est à dire de version de ton soft) etc.
Quand tu prends ta casquette de développeur, tu vas cloner ce repo (c'est là où on dit que GIT est décentralisé, en tant que développeur tu vas récupérer l'intégralité de l'historique, c'est un vrai clone), y travailler dedans, tester, re-travailler, débugger, puis quand ta modif est belle, pusher vers ton repo "bare" tes modifs.
Le tout en utilisant 3 ou 4 commandes GIT de base : init, clone, push, merge (et encore, tu peux très bien vivre sans merge).
Quand on dit "GIT est décentralisé", c'est une technologie, pas un workflow.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.