Usage des GIT et des espaces apaches

[Dominique]

Toutefois, j'avoue que parfois je me suis tellement embrouillé moi aussi à effacer les mauvais fichiers, en ajouter plein qui "polluent" que dans mon espace de travail je sais plus ce qui sert et ce qui ne sert plus.
Or, un "git pull" ne suffit pas à remettre tout "à zéro" car ça garde bien sûr toutes mes modifs locales (dont je veux justement me débarrasser) j'utilise alors la magouille suivante :

Code : Tout sélectionner

rm modeles/ vues/ gestion/ controlleurs -rf  -------> j'efface le ou les dossiers dans lesquels je sais que c'est le souk
git pull ---------> je récupère les derniers commits
git log ---------> je recupère, en haut, le tout dernier commit
git reset --hard 2fdd8f666bc05a517c90604a8f0711e4a53330b5 -----> la magie s'opère ici, tout mon "espace de travail" passe dans l'état propre de git

Bon, d'accord, tout virer pour tout remettre, ça s'apparante à un "git clone" mais ça me garde mes trucs que je sais vouloir garder et qui ne sont pas dans git, et ça garde donc aussi les 2 fichiers pré-cités

J'offre un carambar à celui qui trouve plus simple et plus rapide car ça m'intéresse une méthode "normale"

git checkout .

[Dominique]

Moi, je ne le fais pas systématiquement, surtout ces derniers temps où je change des noms de fichiers, je fais du rangement, je créer des controlleurs. Qui sont typiquement des opérations qui amène à des "warning, cannot open file" ou des "404 file not found" à des endroits que je ne soupçonnais pas. Auquel cas, en laissant mariner dans dev pendant genre 3 mois, j'augmente mes/vos chances de le repérer avant de passer en prod.

Ben ça, c'est bien quand on est tout seul à faire ça parce que tu sais ce qui marine. Mais si un autre arrive derrière et pousse tout sans savoir, on va se retrouver avec les erreurs 404 tout d'un coup et on ne saura même pas pourquoi.
C'est ma grande angoisse devant le GIT dev ou dev.ri: est ce que quelqu'un n'est pas en train de maturer quelque chose là dedans ?

A ce moment là, il serait presque préférable d'avoir un GIT SLY / DOM / LEO pour stocker ses petits travaux et en faire le merge quand on veut.
Par contre, un dev commun, je ne vois pas comment on peut s'en servir (sauf une grande synchro)

[Dominique]

C'est un peu bourrin, ça t'oblige à re-créer le fichier config_privee.php et le fichier .htaccess qui sont deux fichiers ignoré (.gitignore) et pas présents dans github

C'est bourrin, oui, mais j'ai packagé des CP dans un shell (en fait je passe les commandes en paramètre de mon PuTTY de sorte que ça me coûte un click) Avantage de Windows

[sly]

git checkout .

Pas mal du tout ton truc, je viens d'aprendre un truc !
Mais je ne t'offre qu'un demi carambar car cela ne retire pas les fichiers "autres" genre les fichiers truc.php.old que j'aurais mis de coté ou d'autres vielleries entassé en local, mais pas sur le dépot git

C'est ma grande angoisse devant le GIT dev ou dev.ri: est ce que quelqu'un n'est pas en train de maturer quelque chose là dedans ?

Moi, très rarement ou alors je hurle sur le forum : "oulla, j'ai mis un truc pas clair dans dev, laisser moi un peu de temps mais ne mettez pas en ligne sur master"

A ce moment là, il serait presque préférable d'avoir un GIT SLY / DOM / LEO pour stocker ses petits travaux et en faire le merge quand on veut.

C'est ce que je fais en réalité, j'ai une branche "dev" chez moi et je fais plein de commit dedans mais je ne fais le "push" final que quand je sais que c'est assez stable pour que ça se trouve sur master...

Mmmm je viens de fournir moi même la démonstration que ma propre utilisation de la branche dev (sur github) m'est inutile ;-)

Seule utilité, d'avoir une sauvegarde sur github de ces modifs "à part"... donc la solution : avoir une branche par personne... qui est donc la proposition que tu viens juste de faire. Ok tu m'as convaincu ! Si yip et leo qui nous lisent peut-être n'ont pas d'objections, je supprimerais la branche dev de github et je m'en créerais peut-être une genre "dev-sly"

Je retiens toutefois l'idée (avec l'exemple phpbb3) de créer une branche, pour une durée déterminée, qui intégrerais une grosse modifs de fond, sur laquelle nous serions plusieurs à bosser et qui n'aurait pas vocation à être merger dans master, sauf une seule fois : à la fin, quand tout marche !


************
Je m'étais promis de pas répondre à une outrancière tentative de démarrage d'une troll war linux vs windows, mais j'ai pas réussi

(...) commandes en paramètre de mon PuTTY de sorte que ça me coûte un click) Avantage de Windows :)

pfff sous linux , c'est aussi vieux que ssh dont putty n'est qu'un pâle clone ;-p
Je créer une icone (beurk) ou un alias (mieux !) sur ma machine avec la commande suivante :
ssh refuges.info "cd www.refuges.info ; git pull"

Et ça se connecte par ssh avec ma clé RSA et ça exécute un git pull à distance ou tout autre commande de mon choix. Bien sûr, avec l'alias, je peux aussi passer des arguments comme par exemple le texte de mon commit.
Et na !

[leosw]

Salut

Que de réponses !

Pour ce qui est du push sur dev.ri, j'avais essayé depuis ma session, et je pense que ce n'était pas un problème de droits mais bien ce que dom à soulevé.

Pour la branche de dev individuelle et des branches temporaires je suis d'accord (à condition d'effacer les temporaires une fois le travail fini )

Léo

[sly]

et ben voilà, plus de branche dev et plus de site dev.ri non plus

[Dominique]

et ben voilà, plus de branche dev et plus de site dev.ri non plus

Merci

[leosw]

Coucou

Je peux effacer les deux vieilles branches ?

Léo

[sly]

tu parles de avant-pdo et yip-tinyows ?

Perso, je ne pense pas qu'on y reviendra, trop de chemin a été parcouru depuis, peu de chance qu'on en vraiment du code à récupérer là dedans.

Au pire, je viens de faire une copie locale d'archive chez moi. Tu peux faire le ménage.

[leosw]

Oui, c'est effacé