[Résolu] Git, GUI et Ligne de commande

(reprise du message précédent)

Merci pour ta réponse Quentin,

Oui, j'ai cru comprendre que c'était moyen sur un hébergement mutualisé ovh.
J'ai bien trouvé ce tuto, mais à voir :
http://darklg.me/2016/03/deployer-un-site-avec-git-sur-un-hebergement-mutualise-ovh-ou-autre/
Ensuite, c'est pas le prix qui m'empêche de prendre un kimsufi, c'est qu'il me faudrait bosser en plus des notions d'administration serveur que je n'ai absolument pas... et niveau temps, ça serait juste si je veux manger.

Et je veux rester sur git maintenant que j'ai commencé à mettre les mains dans le cambouis.

Je pense que tu as raison sur le débat sur l'interface : de plus en plus dans mon apprentissage de git je réalise que les 2 peuvent cohabiter, que les 2 cohabitent souvent, d'ailleurs certains utilisent leur IDE pour certaines tâches ultra simples et la ligne de commande pour des choses plus avancées.
Ensuite tout évolue. Il y a 20 ans, je n'avais pas un clavier incorporé sur ma souris donc je quittais rarement mon clavier. Maintenant, je copie/coupe/colle tantôt au clavier, tantôt à la souris (clavier) en fonction de l'endroit où je suis déjà. Un autre endroit où le clavier est très important, c'est sous les outils graphiques. Si je devais faire un CTRL MAJ ALT E sous photoshop via les menus, je saurais même plus où le trouver. Et en effet, les interfaces ont évoluées pour ré-intégrer des champs de saisie pour taper directement des commandes et c'est pas plus mal. Concernant le 3 fois plus vite, je ne sais pas. Sur toutes les vidéos que j'ai regardées sur git en ligne de commande, et j'en ai mangé quelques-unes, j'ai vu les gars se planter, faire des retour arrière multiples pour éviter de retaper un commit, se planter et recommencer etc...
Bref, git en ligne de commande commence à m'amuser, donc je vais bien arriver à le digérer comme tout le monde.
Maintenant concernant les lieux de mes dépôts, je sens que je vais devoir faire des essais avancés avant de trouver véritablement l'organisation qui me sera la plus pratique. J'ai pourtant cherché s'il existait des tutos orientés lonesome developer mais j'ai pas trouvé.


Modifié par Manhattan (08 Aug 2016 - 13:13)

Manhattan a écrit :
[...] débat sur l'interface : de plus en plus dans mon apprentissage de git je réalise que les 2 peuvent cohabiter, que les 2 cohabitent souvent, d'ailleurs certains utilisent leur IDE pour certaines tâches ultra simples et la ligne de commande pour des choses plus avancées.

C'est ma manière de procéder à moi aussi.

Pas mieux, je fais mes commits, résoud les conflits et certaines recherches dans l'IDE, je sélectionne les branches, fait les fetch/merge/pull/push en ligne de commande.

Merci à vous.
Mais quid des contenus ?
Je veux dire, quel intérêt pour un développeur travaillant seul d'avoir ses dépôts ailleurs que chez lui ?
Edit : pas clair ce que je dis : est ce que je peux envisager de garder mes dépôts en local et de n'avoir que mes contenus, mes différentes versions de site en ligne ?
Modifié par Manhattan (08 Aug 2016 - 13:44)

a écrit :
J'ai bien trouvé ce tuto, mais à voir :

Ca m'a l'air pas mal. IL faut juste voir si tu as bien un accès SSH chez ton hébergeur, et si GIT est bien installé.

a écrit :
Ensuite, c'est pas le prix qui m'empêche de prendre un kimsufi, c'est qu'il me faudrait bosser en plus des notions d'administration serveur que je n'ai absolument pas... et niveau temps, ça serait juste si je veux manger.

Tu as aussi l'option en quelque sorte intermédiaire, le VPS.

LE seul truc que ja'rrive encore pas à faire tout seul c'est mettre en place le serveur mail. Le reste ça va.
Ca demande un peu d'apprentissage et quelques connaissances théoriques, mais apache, PHP et bind ne sont pas si compliqué que ça à configurer pour des sites à fréquentation normale / modérée.

Après pour un très gros sites qui ferait des millions de visites par jour ou qui aurait besoin d'une disponibilité à 99.9999% avec plusieurs sous-serveurs de cache, proxy, réplication base de donnée et et autres, je serais probablement totalement à côté de la plaque car je ne l'ai jamais fait, mais c'est quand même très particulier. Je n'ai de loin pas le niveau d'un administrateur sysstème confirmé.

a écrit :
Concernant le 3 fois plus vite, je ne sais pas. Sur toutes les vidéos que j'ai regardées sur git en ligne de commande, et j'en ai mangé quelques-unes, j'ai vu les gars se planter, faire des retour arrière multiples pour éviter de retaper un commit, se planter et recommencer etc...

Oui parce que de toute manière, l'interface la plus faible c'est toujours celle qui est entre la chaise et le clavier; que le programme que tu utilises soit tout beau tout joli ou noir et moche avec un curseur blanc clignotant n'y change rien...

La seule grosse différence à ce niveau c'est qu'on part du principe que l'utilisateur du logiciel en ligne de commande sait ce qu'il fait; ou en d'autres termes, on ne te prend pas par la main ni t'aide à te relever si tu tombes.

a écrit :
Je veux dire, quel intérêt pour un développeur travaillant seul d'avoir ses dépôts ailleurs que chez lui ?

Un des premiers intérêts que je trouve à avoir un dépôt bitbucket/github/etc. en plus de son dépôt local même si on est tout seul, c'est que ça fait toujours une copie de sauvegarde en plus. On ne fait jamais assez de sauvegardes.
De ce point de vue-là, bitbucket a l'avantage d'être gratuit même pour les dépôts privés au contraire de github (je me demande d'ailleurs comment bitbucket gagne de l'argent si personne ne paye à priori)

L'autre chose, spécifique à github celle-là, c'est que j'ai l'impression que ça « fait bien » vis-à-vis des recruteurs quand on a quelques petits projets à montrer, même quand ça n'a rien à voir avec le poste qu'on recherche.
JE me trompe peut-être, ce n'est qu'une impression.

Dacodac,

Je suis en train de bosser bitbucket pour m'en servir pour les dépôts.

C'est vrai qu'à terme je prendrai ou un VPS ou un micro dédié, mais il me faudra un petit peu plus de temps pour bosser tout ça. Modifier tout son workflow c'est très chronophage même si à terme on est gagnant. Et comme en plus je veux aussi mettre en place Gulp... j'ai du travail.

Autre question qui n'a que peu de rapport, mais j'en profite :

Je ne sais jamais où trouver (si c'est possible) les informations pour comparer un serveur dédié du genre kimsufi (où l'on peut lire facilement quel est le processeur, la ram etc...) avec un mutualisé dont on ne connaîtra jamais le nombre d'installations dessus. Je veux dire : comparer une offre ovh Pro avec une offre ovh Performance, c'est faisable, mais comparer l'une des 2 avec une offre dédiée, on fait comment vu que la première on a plein de colocataires ?

a écrit :
Je ne sais jamais où trouver (si c'est possible) les informations pour comparer un serveur dédié du genre kimsufi (où l'on peut lire facilement quel est le processeur, la ram etc...) avec un mutualisé dont on ne connaîtra jamais le nombre d'installations dessus. Je veux dire : comparer une offre ovh Pro avec une offre ovh Performance, c'est faisable, mais comparer l'une des 2 avec une offre dédiée, on fait comment vu que la première on a plein de colocataires ?

ON peut savoir combien on a de colocataires avec du reverse DNS, i.e. combien de noms de domaines pointent sur la même IP.

Mais à partir de là vu que les caractéristiques de base ne sont pas explicitées publiquement, on ne peut rien savoir.
Il est très probable qu'en fait ces informations ne soient même pas très pertinentes. Quand on a autant de clients qu'OVH, ça coûte moins cher et c'est surtout beaucoup plus flexible pour assurer la disponibilité d'avoir un système de virtualisation qui répartit intelligemment la charge, plutôt qu'un simple X personnes sur la même machine physique. Peut-être même bien q'un serveur dédié low cost comme kimsufi n'égale pas nécessairement une machine physique.

A mes débuts, mon tout premier hébergeur mutualisé payant hébergeait 300 sites sur une seule machine physique. Un jour la machine s'est fait pirater, les 300 sites ont été down pendant une semaine !
Inutile de dire que je suis vite allé voir ailleurs...

Aujourd'hui on ne peut pas se permettre ça, c'est donc plus que certain qu'ils font de la virtualisation. Une machine tombe en panne ? pas de problème, une autre reprend immédiatement la charge et personne n'a rien vu.
Dans le cadre d'un système virtualisé, c'est pas très pertinent de parler de CPU ou de RAM; à chaque instant les charges sont réparties et je pense que c'est difficile de savoir exactement qui consomme quoi à quel moment.
Je ne sais plus où j'ai lu ça mais dans des data center comme ceux d'OVH, à chaque minute il y a au moins une machine qui est remplacée...
Modifié par QuentinC (08 Aug 2016 - 21:34)

Ah ouai !
J'y avais pas pensé mais ça parait tout à fait logique ce que tu dis.
Je me posais la question parce que ça reste assez difficile de conseiller un client pour un hébergement (pour des sites de petites entreprises). J'argumente facilement parce que j'ai du bagou, mais j'aimerais avoir de vrais arguments techniques pour conseiller telle ou telle offre. Et en terme de serveur pour un hébergement web, je trouve ça assez compliqué au vu du nombre de paramètres.
Bon, demain j'attaque l'article d'Edenpulse sur la synchronisation de son serveur avec Github (ça devrait marcher pour bitbucket).
Au fait, c'est grave si l'on ne met pas de passphrase sur un dépôt bitbucket privé ?
Edit : c'est grave si l'on ne met pas de passphrase sur une clé SSH qu'on utilisera pour un dépôt bitbucket privé ?
Modifié par Manhattan (09 Aug 2016 - 08:45)

@QuentinC

Tu dis : "Un des premiers intérêts que je trouve à avoir un dépôt bitbucket/github/etc. en plus de son dépôt local même si on est tout seul, c'est que ça fait toujours une copie de sauvegarde en plus. On ne fait jamais assez de sauvegardes."

Une sauvegarde de code uniquement alors, parce que j'ai cru comprendre qu'il valait mieux ignorer/ne pas versionner tout le reste : htaccess, robots.txt, images, fonts etc... ?

@*
Et dans la foulée : Dploy ou Capistrano pour déployer mes projets versionnés sur bitbucket sur mon mutu ovh ?
Modifié par Manhattan (09 Aug 2016 - 19:39)

Toujours dans mon amélioration de workflow. Donc si j'ai bien compris (loin d'être sûr) :

J'ai actuellement tous mes projets en local sur wamp.
Pour chaque nouveau projet je crée 2 branches : master et develop.
J'ai une version de ces branches sur bitbucket au cas où je veuille y accéder à partir d'une autre machine ou pour partager mon code et je push donc sur bitbucket.

Mais concernant le déploiement, je ne sais pas s'il faut que je cherche à obtenir ceci :
commit en local -> push automatique sur bitbucket -> déploiement automatique de bitbucket vers mon mutualisé
ou ceci :
commit en local -> push automatique sur bitbucket
et en parallèle -> déploiement automatique de local vers mon mutualisé

?

Edit : et une dernière pour la route si quelqu'un passe dans l' coin : On versionne les fichiers minifiés compressés concaténés compilés ou bien uniquement les non-min etc... ? (suis en train de mettre en place gulp).
Edit 2: Mmm en fait,je pense qu'il faut que je versionne les 2, mais que je dise au script qui récupère les sources sur bitbucket de ne récupérer que les minifiés/compilés...
Modifié par Manhattan (10 Aug 2016 - 19:34)

a écrit :
Une sauvegarde de code uniquement alors, parce que j'ai cru comprendre qu'il valait mieux ignorer/ne pas versionner tout le reste : htaccess, robots.txt, images, fonts etc... ?

A mon avis ça ne pose aucun problème de tout versionner, sauf si tu es limite en espace disque.
Ca peut être très utile, si tu modifies un document / une image / ue musique / une vidéo et que finalement tu te rends compte après quelques jours qu'avant la modification c'était mieux... Avec GIT on peut toujours revenir en arrière, ça permet d'éviter du stress inutile.
En situation de stress genre la mise en prod qui a foiré tu ne sais pas trop pourquoi parce que pourtant d'habitude ça marche, c'est à mon avis important d'avoir une procédure la plus simple possible pour revenir en arrière rapidement.

C'est par contre beaucoup moins utile de versionner les fichiers qui sont générés à partir d'autres fichiers; typiquement tout ce qui est compilé, compressé et minifié.
Versionner ces fichiers ne sert à rien puisque tu peux toujours reconstruire des fichiers à jour à partir d'un instantané quelconque.
Dans l'idéal ces fichiers devraient être générés juste après pull sur le serveur; pour la minification ça ne change pas grand chose mais pour la compilation ça peut (optimisation spécifique).

La seule chose qu'il ne faut pas versionner, c'est les fichiers qui contiennent des mots de passe, des clés API, ou d'autres informations sensibles.
Ca paraît évident mais on a vite fait de l'oublier. Mieux vaut les mettre immédiatement dans le .gitignore et comme ça on est tranquille.

a écrit :
Mais concernant le déploiement, je ne sais pas s'il faut que je cherche à obtenir ceci :
commit en local -> push automatique sur bitbucket -> déploiement automatique de bitbucket vers mon mutualisé
ou ceci :
commit en local -> push automatique sur bitbucket
et en parallèle -> déploiement automatique de local vers mon mutualisé

Ca dépend©®

Ne jamais oublier que plus on va loin dans l'automatisation, plus on a de chance pour qu'une petite erreur idiote se retrouve en prod !
Donc c'est à toi de savoir ce que tu juges utile d'automatiser, et ce qui risque de se retourner contre toi. C'est aussi une histoire d'habitude.
Pour pouvoir aller si loin sans prendre trop de risques tu as intérêt à être blindé en procédures de test.

Par contre le push automatique après un commit c'est une très mauvaise idée à mon avis. C'est courant de faire des erreurs en commitant puis recommiter 5 minutes plus tard; ne serait-ce que pour corriger le commit message. Sans compter les outils qui vont plus loin dans l'automatisation et qui commit automatiquement depuis l'IDE (ce que je ne fais pas parce que je trouve bête et dangereux (cf. au-dessus), mais c'est possible).
Tant que je suis tout seul je m'en fiche un peu, mais les vrais pros de GIT aiment bien faire du rebase et bidouiller l'historique pour que tout paraisse toujours propre dans ce cas.
Je ne sais pas si tu aimes bien les choses bien rangées et organisées ou si tu t'en fiches un peu, mais en pushant automatiquement après un commit local tu t'interdis définitivement ce genre de possibilités.

Bonjour Quentin et merci pour le temps passé à m'aider dans cette période creuse car estivale

Alors voilà où j'en suis :

Je versionne mes projets en "gitignorant" les htaccess, gulpfile.js, package.json. Je conserve le reste (images, font suite à tes conseils). Concernant les fichiers générés, je code en html et css, donc ni jade, ni sass (pour l'instant) ce qui me limite à la minification. Je fais maintenant un push manuel sur bitbucket, et j'utilise le script FTPbucket de Thomas Malicet pour déployer mes sources de bitbucket sur ovh.
Maintenant je suis en train de mettre en place gulp en étudiant à la loupe les tutos de Raphaël. En parallèle, j'étudie aussi la manière de versionner un projet wordpress en modifiant son architecture pour utiliser les submodules git http://agence.keyrusdigital.fr/blog/articles-technique/bien-versionner-wordpress-git/

Il y a quand même quelque-chose qui m'inquiète dans toute ce workflow : quand je regarde par exemple le package.json de Raphäel entre le tuto découverte de gulp, le tuto gulp workflow, et son fichier sur github, on remarque une évolution à chaque fois :
https://gist.github.com/raphaelgoetter/39e8923d282b4007ac98
Alors je sais qu'un workflow évolue constamment surtout dans notre métier, mais je sais aussi que c'est chronophage et que parfois il vaut mieux bien maîtriser un outil qu'en changer tous les 6 mois ^^

Maintenant, comme je ne fais que me remettre à jour, c'est peut-être une impression fausse.

Par contre, je n'ai toujours pas encore pigé comment je vais greffer git à gulp (ou l'inverse). Parce qu'en théorie, je devrais minifier par exemple mon css au moment de le déployer, or ça, c'est entre bitbucket et ovh que ça se passe et pas sur mon pc.

Edit : Si, je commence à piger comment faire la greffe. Par contre, les submodules git uniquement pour utiliser le versioning de wordpress ça ne m'intéresse pas au final. Je vais me contenter de versionner le thème, les plugins et mu-plugins.

Jraconte ma life histoire que quelqu'un m'corrige si j'déraisonne
Modifié par Manhattan (11 Aug 2016 - 16:18)

a écrit :
mais je sais aussi que c'est chronophage et que parfois il vaut mieux bien maîtriser un outil qu'en changer tous les 6 mois ^^

Pour ma part j'estime que mettre en place un workflow de travail bien foutu doit servir plusieurs années (avec des micro-ajustements). Sinon c'est effectivement trop chronophage (sauf si on adore ça et qu'on le fait à temps perdu, mais bon

Techniquement, dans un workflow d'entreprise, on utilise principalements trois types d'outils: Les outils de versioning pour travailler sur le code, des outils de builds et des outils de déploiement/intégration continue.
Ainsi le versioning idéal ne contient que le code et les fichiers que l'on a écrit soi-même. Tout le reste est téléchargé/construit par les divers outils. Pour un CMS, cela donne en gros:
- Le code du thème ou du sous-thème réalisé (incluant les images en dur .
- Le code des plugins/modules maison.
- Les fichiers indiquant les modules/thèmes/plugins/assets et leur versions à télécharger.

C'est normalement comme cela qu'on versionne. Après bien entendu, cela devient (trop) lourd à mettre en place pour un indépendant. Du coup on peut tordre le système de versioning pour l'utiliser pour du déploiement, mais il faut généralement être plus large dans l'inclusion des fichiers versionnés (ce qui n'est pas la fin du monde).

a écrit :
Je versionne mes projets en "gitignorant" les htaccess, gulpfile.js, package.json.

Le htaccess si c'est celui du CMS il s'ignore volontiers, s'il est de son cru il faudrait l'inclure,
quant aux gulpfile.js et package.json ceux-ci me semblent absolument obligatoires dans le versioning ?

Bonsoir

Pour le htaccess, je pensais à un site sans CMS, mais en effet, mon but est de créer un workflow essentiellement pour du wordpress. Je pensais qu'il ne fallait pas versionner les fichiers utilisés par gulp... comme beaucoup m'est encore assez opaque dans ces technos, j'avais peur de tomber dans un type de récursivité.
Je ne sais toujours pas bien si j'ai raison de ne pas utiliser la méthode de submodules pour wordpress :
http://agence.keyrusdigital.fr/blog/articles-technique/bien-versionner-wordpress-git/
En fait cela me dérange un peu de modifier la structure de wordpress
Et sinon, pour l'instant je laisse tomber bower car je n'avais pas capté que c'était orienté front, or, j'utilise très peu de framework (pas de framework css), et bêtement, je pensais que bower allait me permettre de dire : alors jveux un wordpress, avec un fichier de test unitaire, etc... allez hop construit moi ça ici bim ^^

@Manhattan,
à ce moment critique de la conversation, puis-je te dire ceci : nos ancêtres antédiluviens ont inventé (ou découvert) un silex pour découper bois et chair pour progresser : c'est l'ellipse magnanime de l'effort comme un bras-de-levier, un arc en-plain-cintre, un triangle moderne architectural indéformable.

Rien de ceci n'est extérieur à ta question.
Modifié par pictural (11 Aug 2016 - 21:16)

@Pictu

Amen

@Manhattan,
je n'ai pas pensé être si idiot.

Le mot amen exprime l'assentiment.
Et comme tu citais le déluge je me suis permis une analogie religieuse.

Bonne soirée

@Manhattan,
bizz.

Non, tu ne risques pas de créer une faille dans l'espace-temps si tu versionnes le package.json et le gulpfile.
Je suis d'accord avec Custolovic, je dirais même que c'est encore les premiers à versionner. Tout comme le build.xml et/ou le pom.xml si tu fais du Java, ou le composer.json avec Symfony.
N'oublie pas de versionner aussi le .gitignore, et à mon sens le .htaccess aussi devrait être versionné.

C'est utile de versionner le guplfile et le package.json parce que ça te permet de versionner et mettre à jour ton workflow. D'ailleurs tu peux pourquoi pas inclure un npm install après chaque pull; ça ne mange pas de pain, si rien n'a changé il n'installera rien.

Oula oula oula, c'est là que je vois que je comprends encore pas tout : je fais pas de pull moi : je travaille mon code, je l'ajoute (add) je l'indexe (commit) sur ma branche develop et je le push sur bitbucket. Automatiquement il est déployé sur mon répertoire ovh de test. Si ça me convient, je merge develop dans master, je push master qui est déployé sur mon répertoire ovh de pré-prod, seule partie que peut voir mon client.
Alors j'ai compris que finalement il faut que je versionne tout (à part d'éventuels password) mais je ne comprends pas à quoi servirait un npm install après chaque pull et surtout pourquoi je ne fais pas des pull alors qu'il te parait logique que j'en fasse...