Je mets ça dans la cat PHP parce que c'est ce qui me semble le plus pertinent.
 
Je développe une petite application web, pour faire simple :
- un seul dev
- fichiers php (et bdd) sur mon pc sous windows (+wamp)
- pour la prod, un serveur type kimsufi sous linux
 
Jusqu'à présent sur des petits projets de ce type, je me faisais 1 serveur de dev sur mon ordi et quand c'était bon hop, je balance tout ce que je viens de modifier en prod via SFTP (au besoin un petit coup de comparateur de fichiers entre le local/distant dans FileZilla).
Ca marche très bien pour tout ce qui n'est pas critique, qui n'évolue pas beaucoup (petits sites web par ex).
 
Là je bosse sur une application qui le jour où elle sera en prod sera utilisée 7J/J par pas mal de monde et pour laquelle j'aurai probablement pas mal de modifications à intégrer dans le temps... donc pas envie de faire n'importe quoi.
 
Je découvre (c'est l'occase aussi) git, notamment via git GUI. Et globalement pour l'instant ça me sert à versionner mes modifs au fil du développement.
J'ai créé le dépôt, intégré tous mes fichiers php&co dedans, et à chaque fois que j'ai terminé une grosse modifications de ces fichiers en question je fais un scann de ce qui a changé (Rescan), Intègre tout ce qui a changé (Stage Changed) et Commit . Le tout sur le master.
 

 
Donc à l'heure actuelle j'ai (en simplifiant bien sûr) :
c:\monprojet\.git <- tout le bazar du dépôt git
c:\monprojet\index.php
c:\monprojet\toto.css
...
 
Ah oui, hors de question de me fader des instructions git en ligne de commande, on est en 2016, on a des interfaces graphiques. J'ai pas spécialement envie d'ajouter chaque fichier manuellement ou de devoir taper 3 lignes à chaque fois pour comprendre sur quelle branche est quoi... Si je risque d'oublier d'intégrer un fichier alors ça n'est pas un bon outil car justement on met en avant le côté "avec les outils de gestion de version, plus de risque d'oublier d'uploader un fichier en prod..." mais c'est le même cerveau humain qui gère ça, alors si le fichier n'a pas été intégré à la base de versionning au départ, c'est un outil inutile à mes yeux (pour mon utilisation, sur une appli web avec 100-1000 fichiers je me vois pas me taper les intégrations des modifs fichier par fichier à la main).
 
Mes questions :
1/ Est-ce déjà une bêtise que de travailler directement sur les fichiers que j'ai intégré initialement ou c'est bien comme ça qu'on procède ? Pas besoin que j'exporte l'intégralité dans un autre dossier et que je travaille sur cet autre dossier ?
 
2/ OK, je suis prêt à mettre en prod, sur un serveur distant, qui a un dossier /home/monprojet/www qui attend, il faut que je fasse quoi ? C'est là où c'est pas clair. Je continue à transférer tous mes petits fichiers via SFTP ? En prenant tout ce qui est dans c:\monprojet (en excluant le dossier .git bien sûr) ?
Il doit y avoir plus propre si j'ai compris (Remote server) et buton Push peut-être... ah par contre la syntaxe du serveur remote...heu... ?!? et côté doc, heu

Et il faut installer quoi en face sur le serveur ?  
 
Jusque là c'était à priori facile côté dev/prod : sur mon pc les différents états du projet pour récupérer des modifs écrasées par erreur par exemple. De l'autre la prod, l'état final où tout va bien. Pas besoin de staging vu que je suis en même temps développeur et testeur, j'ai tout sur ma machine.
 
3/ Vu que je prévois de développer des fonctionnalités dans le futur, que je ne pourrais pas les poster à tout moment, j'ai bien compris l'idée d'avoir désormais la possibilité de retoucher la version actuellement en prod (master) pour faire un patch en urgence par ex, et de travailler sur une branche séparée pour intégrer les nouvelles fonctionnalités.
Du coup c'est là que je commence à sécher un peu : j'ai une seule source de fichiers PHP, ils sont dans c:\monprojet, comment je fais pour accéder aux 2 états à des moments différents (et pouvoir les tester/utiliser bien sûr ?
Là je n'ai pas encore capté... je veux bien un coup de pouce...
 
Merci par avance

Hello,
 
  J'ai lu ton message avec attention, si si je t'assure.
 
  Très bonne idée d'apprendre git, même pour un projet solo.
 
As tu un accès ssh à ton serveur ?
 
Où se situe ton dépot git ? si tu veux un dépot privé (donc pas github) regarde du coté de gitlab.
 
  Ne cherche pas ici à ce qu'on t'apprenne git. Commence par un truc du genre : https://openclassrooms.com/courses/ [...] e-avec-git  (peut être un peu verbeux)
  Et puis ensuite tu comprendras lesidées de base : clone, branch, checkout, commit, push ...  
 
  Tu peux mettre à jour ton serveur avec pull, c'est ce que je fais sur mes 80 serveurs,  après avoir correctement fait tes checkout, commit et pull.
 
  Mais tout ces mots que tout les utilisateurs git connaisse sont sur la ligne de commande, pas sure qu'avec une IHM ca soit très parlant.
 
  si si j'ai bien lu ton message surtout là où tu parle de 2016...  
 
  Apprend la ligne de commande, c'est un conseil.
 
Pierre

Il y a une différence entre comprendre le vocabulaire (j'ai pas encore tout capté entre pull (que tu évoques) et push (du bouton de la GUI).
Après la ligne de commande pour ce genre d'outil ça me parait un peu contre productif, notamment pour l'aspect visuel de bien savoir à tout moment sur quelle branche on travaille et ce genre de choses...
 
Après j'imagine que chacun est différent.
 
Je vais lire ton doc.
J'ai déjà consulté pas mal d'articles, mais beaucoup partent soit d'un niveau trop pointu, soit se contentent d'expliquer quelle fonction sert à quoi mais pas pourquoi on l'utiliserait.

tu n'a pas répondu à mes 2 questions :
 
As tu un accès ssh à ton serveur ?
 
Où se situe ton dépot git ?

Pardon je voulais faire un second message après lecture de ton lien mais j'ai été interrompu.

Ssh oui
Dépôt, pour l'instant uniquement local

si dépot uniquement local, ca va être compliqué de faire des pull sur ton serveur distant, à moins de faire un montage ssh, et donc simuler un autre dossier local.

Ça n'est pas figé, je découvre, mais justement ça serait quoi la bonne pratique pour ce type de situation ?

la bonne pratique est assez lourde à mettre en place : test unitaire, logiciel d'intégration continue, serveur de recette, suivi de source sql, déploiement automatique...
 
Avant tout cela une bonne brique est d'avoir un serveur git qui fait pivot. Ton dev est branché dessus et ta prod aussi. Si un jour un autre Développeur web s'ajoute, c'est plus facile.
 
de la tu push tes dev sur le seveur git, et tu pull sur la prod.
 
Si besoin d'une branche de patch idem, tu push ta branch, et tu pull la branch.
 
Tu veux travaillé depuis un cyber café, pas de soucis, git clone, et hop.
 
Sur le serveur git là parcontre il te faut une interface web : voir les branches, les commit, les différences, rechercher dans l'historique : Github, ou gitlab, il y en a d'autre.
 
Ton serveurs git devient essentiel, donc backup à fond.
 
Avec ca tu as une bonne base, qui te permet de voir venir.

OK, j'ai fini de lire "ton" doc, donc si je comprends bien, par rapport à mes questions initiales :
 
1/ git + fichiers php en local et c'est bon -> non, il vaut mieux travailler sur un "import" venant d'un serveur git "extérieur". (J'évite le langage git volontairement).
Donc si je capte bien :
a) il me faut une machine qui fera serveur git distant (paramétrable idéalement via une interface web, un truc qui tourne en tant que démon si je comprends bien ?).
b) ainsi que mon organisation initiale : mon code + mon git "local".
Ensuite j'envoie (push) le projet au serveur git distant et c'est ce serveur qui fait ma base fiable de l'état de l'avancée du projet ainsi que du code en production. En gros je peux dégager "a)" si besoin sans souci et recommencer plus tard un nouveau "a)" sur une autre machine.
 
2/ mise en prod du code -> si j'ai bien compris il faut également installer git sur le serveur web et importer le projet de mon serveur "a)" (pull). Concrètement ça marche comment ? La première fois en ssh sur mon serveur web je vais dans le dossier /home/monprojet/www et je lance un git clone ? Pareil ensuite un git pull pour les mises à jour ?
 
3/ Travailler sur le code de branches différentes successivement -> Si j'ai bien compris quand on change de branche (checkout) ça modifie tous les fichiers pour les remettre à l'état de la branche sur laquelle on veut travailler. Donc pas besoin d'exporter le code d'une branche dans un nouveau dossier, de configurer un virtualhost différent dans Apache ou que sais-je, il suffit juste de travailler sur l'un après l'autre et de faire les commit sur la branche qu'on veut.
Ex : (dites-moi si je me trompe) :
- je travaille sur la branche "ajout_fonction_toto", donc mon code est non fonctionnel car en cours de rédaction
- Un utilisateur pointe un bug critique qu'il faut résoudra là tout de suite
- Je commit (ou stash si je veux éviter de commit un code non fonctionnel) tout mon travail en cours sur ma branche
- Je change de branche pour revenir sur le master (checkout)
- Automatiquement tous les fichiers (php, css...) sur lesquels j'ai travaillé sont écrasés dans le dossier de mon projet et remplacés par la version actuellement en prod (master)
- Je corrige mon bug critique
- Je commit
- Je push sur mon serveur "a)"
- Je me logue sur mon serveur de prod, je pull depuis mon serveur "a)"
- Sur mon pc principal je peux re-switcher sur ma branche "ajout_fonction_toto" et hop tous les fichiers seront remodifiés pour revenir à l'état sur lequel j'étais (non fonctionnel) lors de la rédaction de ma nouvelle fonction (bug critique non corrigé).
- Le jour ou je fusionne (merge) ma branche "ajout_fonction_toto" avec la master, j'ai un code qui sera aussi mis à jour pour tenir compte de la correction du bug critique.
C'est ça ?
 
A mon stade (1 seule personne sur le projet, pas d'autre prévue) + code stocké en réalité non pas sur mon pc perso mais sur un petit serveur windows qui tourne H24, accessible de l'extérieur... est-ce réellement pertinent d'ajouter un autre serveur git intermédiaire (celui que j'appelel "a)" ) ? Après pour la mise en prod ça doit poser un souci (pas d'accès ssh au serveur sous windows donc le git pull je ne vois pas bien comment je pourrais le faire...

Bravo pour la lecture du tuto !
 
 

 
Oui (tu apprends vite )
 

Je te conseil d'avoir une branche "master" qui est la branche maitre de ton projet. Toutes les autres branches tu les crées à partir de master. Evite de créer une branche à partir d'une branche, sinon ca va vitre devenir compliqué. Tu en auras peut besoin un jour, mais évite dans un premier temps.
 
Pour bien faire il ne faudrait pas modifier directement master. Dans ton scénario du bug critique, tu créer une nouvelle branch ce qui donne : checkout, commit, push, merge, pull  . Mais ce point est discutable pour les bugs critiques, tout dépends où tu veux mettre l'indicateur de qualité.
 

ton code sera à jour sur le dépot git, par forcément en local. En local il faudra faire revenir sur la branch master et faire une git pull
 

Plusieurs solutions :  
- Installer un serveur ssh sur ton windows : cygwin ou copssh avec un forward de port et si pas d'ipfixe un coup de no-ip.org
- Prendre un serveur dédier premier prix, 3.60 € par mois : https://www.kimsufi.com/fr/vps-ssd.xml   Vu que tu aimes apprendre, au passage tu apprends l'admin linux en ligne de commande, il te faut juste du temps et de la motivation :-)

J'ai installé une VM gitlab sur mon serveur windows, bon VMWare Workstation player sur un Atom c'est pas la joie (c'est lent) mais ça me permet de tester. Donc j'ai pu "push" vers ce serveur, prochaine étape pull depuis mon serveur de prod... et c'est là qu'une livebox en ipv4 c'est pas non plus la joie pour filer l'accès depuis l'extérieur à la VM
 
work in progress...

Pour le stockage de mon code j'utilise bitbucket il a l'avantage d'héberger gratuitement ton code.

Hébergement gratuit avec le code qui reste en privé ?

Parce que github c'est payant même pour 1 projet si on veut que le code ne soit pas public.

Oui, c'est pour cela que j'utilise bitbucket pour mes projets persos
et pour le reste c'est github quand je fais vraiment de l'open source

Bon on ne rigole pas, mais je n'ai pas compris quel username/pass il faut utiliser pour faire un push depuis mon git local vers gitbucket !?!
 
Quand on créé un compte sur le site il faut :
email + un nom "complet" + un pas
 
Ensuite quand on valide l'email il faut créer un username (mais pas de pass supplémentaire)
 
Quand je push sur l'url (https) du projet ça me demande login/pass... et à première vue il n'y a rien qui fonctionne une idée ?

pour gitlab et github ca fonctionne par echange de clef qu'il faut déposé sur son compte. gitbucket je sais pas.

Ce qui est  bizarre c'est qu'on peut afficher 2 "urls" pour le projet : la version "via ssh" ou "via https". Or a ma connaissance quand c'est par https ça ne passe pas par les clés non ?
 
Je le sentais mal cette histoire de clés (because je rappelle que je code sous windows).... mais  par le plus grand des hasards j'ai trouvé dans la GUI pour windows le moyen de générer la clé (menu Help - Show SSH key)...
 
Miracle ensuite avec l'url "ssh" du projet, ça a fonctionné !

un jour faudra envisager à passer sous linux tout de même
 
Tout les développeurs que je connais sont sous linux, et aucun ne retournerai sous windows.

 
Sur Mac c'est bien aussi ;-) (sauf les claviers sans touche suppr ni pavé numérique, ni "{" ou "[" écrits sur le clavier).. et le prix aussi...
 
Plus sérieusement j'ai 2 activités, et l'une n'est pas envisageable sous autre chose que Windows (ou Mac Os mais je ne suis pas fan de Mac). Comme je n'ai qu'un ordi, que je n'ai pas envie de switcher en permanence (reboot sous linux pour coder) ou de bosser sur une VM... ça limite.
 
Mais je reconnais que ça apporte pas mal de contraintes.
 
Même chose mon "serveur" local (sur lequel je fais tourner wamp) est aussi mon htpc et pas mal d'autres applis qui ont tendance à être plus simples d'usage sous windows... donc un peu bloqué.
 
J'avais envisagé de me faire un petit serveur de dev sous linux, à base de raspberry, mais c'est lent (en tout cas quand j'ai testé sur un raspberry 2, 1 Go de RAM c'est trop peu pour apache + mysql + ...), ça fait encore un truc en plus à gérer (backup, ...)
 
J'ai 2 serveurs "de prod" chez ovh, sous linux, mais j'ai pas bien envie de mettre mon code de dev ou mon dépôt git dessus...
 
Vous savez tout maintenant

étape suivante donc "pull" du code depuis bitbucket vers mon serveur de prod... des conseils ?
On peut aller dans un dossier quelconque (genre /home/monuser/www) et faire un git pull (visiblement un git init en premier) ?
 
Le truc qui fait peur : le dossier. git qui va être créé sur le serveur (dans www) -> pas une bonne idée qu'il soit accessible. Soit il faut que j'en protège l'accès via un htaccess soit que tout mon projet soit stocké "1 cran au dessus du dossier www.
 
Ca veut dire en local par exemple:
c:\monprojet\.git
c:\monprojet\www\
c:\monprojet\www\index.php
...  
 
Qu'est-ce qui semble le plus pertinent ?

git pull n'est jamais la première commande.
 
c'est soit git clone, soit en effet dans ton cas git init
 
La meilleur solution ait que tu es un dossier parent non accessible. Il y a toujours beaucoup de chose utile qui ne doivent pas être accessible directement depuis un navigateur. Par exemple toutes tes class.

ok, merci.
Par contre vu que www est un sous-dossier du compte de l'utilisateur, /home/toto/www dans ce dossier /home/toto il y a des fichiers propres au serveur, genre .bashrc, .profile ... ça ne risque pas de tout écraser lors du pull ???
EDIT : je me réponds après quelques tests :
- si le fichier n'existe que sur la destination, il est ignoré. Ex : genre si ".bashrc" est dans /home/toto du serveur de prod mais qu'il n'y en a pas été intégré dans le "git source", RAS, il n'est pas écrasé
- si le fichier existe sur la source ET la destination, git râle lors du pull pour indiquer qu'il y a un conflit qu'il faut résoudre avant de pouvoir effectuer le pull correctement. Ex : /home/toto/www du serveur de prod n'est pas vide (un index.php ou .htaccess trainent par exemple), le pull ne pourra pas avoir lieu tant qu'on n'aura pas dégagé ces fichiers.
 
Autre question :  
Un "push" du git local (ou bitbucket) vers le serveur de prod ça ferait pareil ?  
Pourquoi faire un pull "prod<-stockage" plutôt qu'un push "stockage->prod" ?

Bon petite mise à jour
 
Donc j'ai :
- généré une paire de clés sur le serveur de prod via
ssh-keygen -t rsa
(chiffrée avec un pass)... ça semble toujours une bonne idée mais du coup c'est chiant car ça demande le pass à chaque utilisation, c'était pas le but d'une clé que d'éviter d'avoir un mot de passe à se taper ??? AVIS ?
 
- J'ai ajouté dans les paramètres de bitbucket la clé publique (~/.ssh/id_rsa.pub)
 
- j'ai lancé :
git init
git remote add origin git@bitbucket.org:USERNAME/PROJECTNAME.git
git pull origin master
 
là ça m'a demandé le pass de la clé et hop miracle j'ai tous mes fichiers transférés...  
 
Bon par contre j'ai une couille de .gitignore, je ne capte pas, j'ai tenté d'ajouter un dossier entier à ignorer (et tout ce qu'il y aurait en dessous), mais ça n'ignore pas
 
En gros j'ai un moteur de templates qui génère des fichiers intermédiaires dans /app/var dont je n'ai rien à faire (3 sous dossiers dans lequels il met ce qu'il veut).
 
Dans .gitignore j'ai tenté :
app/var/*
app/var/**/*
 
ou alors les dossiers un par un :
app/var/cache/*
app/var/configs/*
app/var/templates_c/*
 
rien n'y fait.
Par contre j'ai aussi mis :
backups/*  
et là le dossier "backups" (de 1er niveau) est bien exclu !
WTF ???
 
Sinon j'ai fait une réorganisation massive pour gérer ce niveau www/ et de gitignore... et ça m'a foutu la zone, sur la prod j'ai  
"Le pull n'est pas possible car vous avez des fichiers non fusionnés.
Veuillez les corriger dans votre copie de travail, et utilisez alors 'git add/rm <file>'
si nécessaire pour marquer comme résolu, ou utilisez 'git commit -a'."
 
grrr. Je recommencerai bien from scratch, mais j'aimerai comprendre, je veux que le pull écrase tout sur la prod avec les modif du staging (bitbucket)...
Là il y a un truc qui m'échappe sur la prod. Imaginons que "par erreur" je modifie un fichier sur le serveur de prod, oui je sais... Par exemple patch ultra à l'arrache en ssh direct sur le serveur parce que bug critique et juste un smartphone sous la main au milieu d'une rando à la montagne... vous voyez l'idée.
Ensuite je rentre chez moi et je refais le patch gentiment et proprement sur ma machine de dev, commit sur la branche master, push sur le serveur bitbucket, me logue en ssh sur le serveur de prod et tente un pull depuis bitbucket...  
c'est pas censé écraser mes modifs faites à l'arrache dans le code de prod ???

Question du jour :
 
J'ai démarré des modifs de code en pensant que j'allais pouvoir faire ça tranquillement petit à petit (migration d'une couche d'abstraction d'accès à la bdd un peu antique à pdo + prepared statements) Ca remet plein de choses en question, pète des validations de données que je faisais avant, bref ça met mon appli en PLS tant que je n'ai pas totalement finalisé la migration.
Problème, j'ai fait un paquet de commit, même quelques pushs sur mon serveur git distant (bitbucket).
Maintenant je me rends compte que j'aurai du faire une branche séparée, afin de continuer à pouvoir "patcher" la branche master et pousser les modifs en prod.
A ce stade quelle est la solution pour pouvoir créer une branche à partir d'un état antérieur ?
En gros je dois pouvoir arriver à retrouver le commit de début de travail sur ma migration et j'aimerai que :
- master revienne à cet état
- avoir une branche "migration-pdo" (ou truc du genre) qui prenne tout mon code actuel en l'état (à la limite je me fiche de perdre les commit intermédiaires).
 
C'est quoi la technique pour faire ça ?
 
Réponse :

Ca retourne l'id du commit, on peut vérifier avec une gui que c'est le bon si on veut.  
 
Pour le push sur bitbucket ou équivalent :

sans le --force ça couine parce qu'on essaie de faire un push avec des données plus anciennes que celles déjà transmises (donc le serveur appelle à faire un pull d'abord).