Discussion :

[CinePhil]

Suite de mes (més)aventures avec le Git d'Eclipse et donc avec Git...

J'ai modifié et créé des fichiers sur ma machine locale et je veux maintenant les pousser vers le serveur de développement et test.

Lorsque j'essaie de faire "Team / Push branch Master" dans Eclipse, ça finit avec un message d'erreur :

branch is currently checked out

Ça veut dire quoi ?
Qu'est-ce que j'ai manqué ?
Faut-il que je tire une branche sur le serveur pour que je puisse pousser mes modifications dedans ?

[Marco46]

Regarde cette discussion sur stackoverflow.

Ton repo distant est-il bien un bare repo ?

[CinePhil]

J'ai décidément des difficultés de compréhension avec git...

Pour rappel, voilà ce que j'ai sur le serveur de développement...

Mon projet est dans /srv/www/htdocs/pef (pef est le nom de mon projet). Dans ce répertoire figure également le répertoire .git

Voilà ce que j'obtiens comme status de git :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git@dev:/srv/www/htdocs/pef> git status
Sur la branche master
rien à valider, la copie de travail est propre

Sur l'ordinateur client sur lequel je développe, sous Eclipse, mon projet est dans /home/[moi]/Documents/Projets/[Repertoire-du-projet]/Developpement/pef. Y figure, de même, le répertoire .git et voilà ce que me donne un git status :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[plemenager@localhost pef (master)]$ git status
Sur la branche master
Votre branche est en avance sur 'origin/master' de 1 commit.
  (utilisez "git push" pour publier vos commits locaux)
Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git checkout -- <fichier>..." pour annuler les modifications dans la copie de travail)
 
        modifié*:         application/conf/constantes.php
        modifié*:         public/index.php
 
Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
 
        .buildpath
        .project
        .settings/
        application/Controller/
        application/Model/
        application/include/
 
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")

Je remarque au passage que, sur ma machine, mon répertoire de projet est donné par Linux en tant que "pef (master)" alors qu'il s'appelle bien "pef" et que ce n'est pas le cas sur le serveur. Peut-être est-ce dû à l'utilisation du plugin EGit de Eclipse qui présente ainsi mon projet.

Ton repo distant est-il bien un bare repo ?

J'avais lu quelques trucs sur divers sites et vu cette histoire de "bare repo".
Cela veut-il dire que, sur le serveur, je dois avoir deux repositories git ?
- un bare qui servirait à y pousser les modifications effectuées par les développeurs (un collègue et moi) ;
- un "master" pour récupérer les modifications approuvées vers les postes des développeurs.

Pourrais-je avoir une explication concrète de ce que je dois faire pour que :
- chaque développeur puisse pousser ses modifications vers le serveur de développement ;
- chaque développeur puisse récupérer la versions du serveur comprenant les modifications validées de l'autre développeur ?

Questions subsidiaires :
Les modifications poussées vers le serveur vont-elles se retrouver dans le répertoire du projet ou seulement dans le (bare ?) repository du serveur ?
Et si c'est seulement dans le (bare ?) repository, comment ensuite pousser les modifications validées vers le répertoire du projet du serveur pour qu'on puisse accéder à l'application dans sa dernière version via un navigateur web ?

Désolé si ces questions semblent basiques mais je n'ai pas trouvé de tutoriel pas à pas vraiment clair pour mon "relativement" vieux cerveau.

[Marco46]

On va déjà clarifier un point, ce que tu appelles "serveur de développement" c'est tout simplement le serveur web sur lequel du déploie le livrable correspondant à ta branche master c'est ça ?

Cela veut-il dire que, sur le serveur, je dois avoir deux repositories git ?
- un bare qui servirait à y pousser les modifications effectuées par les développeurs (un collègue et moi) ;
- un "master" pour récupérer les modifications approuvées vers les postes des développeurs.

Un bare repository sert à partager ton "tree", c'est à dire l'arbre des commits situé sur ta machine.

Un repository normal (sans l'option --bare quand tu fais git init) sert à travailler, tu as une working directory qui te permet de créer des commits, des branches, des tags, ...

Un bare repository sert à partager, il n'a pas de working directory.

Je n'ai personnellement jamais créé manuellement de bare repo pour partager, je passe soit par github soit par gitlab selon l'employeur. Certains ont des repos privés sur le github situé sur internet, d'autres ont un github ou un gitlab installé en interne. C'est cette installation qui sert de référentiel pour tous les devs et je pense que tu devrais installer l'un ou l'autre sur ton réseau pour simplifier les choses et éviter de te taper toute la config manuelle.

Concernant les déploiements, tout dépend déjà de la nature de ton livrable, est-ce qu'il s'agit du code source tel quel, ou bien as-tu une commande qui builde un livrable sur la base de ton code source ? D'où ma 1ère question.

[CinePhil]

On va déjà clarifier un point, ce que tu appelles "serveur de développement" c'est tout simplement le serveur web sur lequel du déploie le livrable correspondant à ta branche master c'est ça ?

On va dire oui.
Sans git ou autre gestionnaire de version, ce serveur serait, en gros, celui :
- sur lequel j'enverrais les programmes que je développe en local sur ma machine;
- sur lequel le service utilisateur de la future application (ou de ses évolutions) pourrait tester et valider ce que j'ai développé.

Comme nous sommes deux développeurs, il m'a semblé pas idiot d'utiliser git pour que les ajouts ou modifs de programmes de l'autre développeur ne se téléscopent pas avec les miennes... mais c'est plus compliqué que ce que j'avais prévu.

Un bare repository sert à partager ton "tree", c'est à dire l'arbre des commits situé sur ta machine.

Ça se complique de nouveau !
Sur ma machine j'ai juste utilisé la fonction "Checkout projects from Git" de Eclipse Neon, afin de récupérer l'arborescence du projet du serveur. J'ai décrit ce que j'ai fait dans l'autre discussion.

Un repository normal (sans l'option --bare quand tu fais git init) sert à travailler, tu as une working directory qui te permet de créer des commits, des branches, des tags, ...

Un bare repository sert à partager, il n'a pas de working directory.

J'ai fait git init sur le serveur pour y créer le repository du projet. Aurais-je dû y faire un git init --bare ou une commande de ce genre ?

Je n'ai personnellement jamais créé manuellement de bare repo pour partager, je passe soit par github soit par gitlab selon l'employeur. Certains ont des repos privés sur le github situé sur internet, d'autres ont un github ou un gitlab installé en interne. C'est cette installation qui sert de référentiel pour tous les devs et je pense que tu devrais installer l'un ou l'autre sur ton réseau pour simplifier les choses et éviter de te taper toute la config manuelle.

J'ai essayé d'installer gitlab sur le serveur (Opensuse 42.2) en suivant ces instructions mais...

dev:/etc # curl -sS https://packages.gitlab.com/install/.../script.rpm.sh | sudo bash
Detected operating system as opensuse/42.2.
Checking for curl...
Detected curl...
Downloading repository file: https://packages.gitlab.com/install/...&source=script
done.
Repository 'gitlab_gitlab-ce' is up to date.
Specified repositories have been refreshed.

The repository is setup! You can now install packages.
dev:/etc # sudo zypper install gitlab-ce
Loading repository data...
Reading installed packages...
'gitlab-ce' not found in package names. Trying capabilities.
No provider of 'gitlab-ce' found.
Resolving package dependencies...

Nothing to do.

Concernant les déploiements, tout dépend déjà de la nature de ton livrable, est-ce qu'il s'agit du code source tel quel, ou bien as-tu une commande qui builde un livrable sur la base de ton code source ? D'où ma 1ère question.

Il s'agit d'un projet PHP donc simple ajout de fichiers php, html, css, js... Pas de compilation.

Je viens de constater que j'ai accès via un navigateur à l'URL [mon-serveur-de-dev]/git (git-web installé) mais ça me dit seulement :

404 - No projects found

Je suis toujours paumé !

[Marco46]

Il faudrait que tu suives une formation git (1 ou 2 jours suffisent) ou que tu prennes le temps de faire des tutos.

Pour moi ya une confusion dans le sens où tu mélanges deux problématiques :
- comment collaborer à plusieurs développeurs avec git (dev)
- comment utiliser git pour gérer les déploiements (ops)

Il s'agit de deux problématiques différentes (bien que liées).

Tu devrais te limiter à la première pour le moment, et gérer tes déploiements avec scp ou un ftp ou n'importe quel autre utilitaire qui va déployer ton livrable sur ton serveur de développement. Une fois que tu comprendras mieux l'architecture (décentralisée) et le fonctionnement de git tu pourras bidouiller pour gérer la partie déploiement avec. L'idée c'est de prendre les choses les unes après les autres plutôt que de vouloir tout faire en même temps.

Prends le temps de bien chercher comment déployer gitlab sur un de tes serveurs, ne mixe pas cette problématique avec le déploiement de tes livrables, il ne s'agit que de collaborer à plusieurs développeurs. Rien que l'étape de savoir comment collaborer à plusieurs ça va te bouffer pas mal de temps.

L'usage de git est un investissement, il y a un cout d'entrée assez important. Par contre une fois qu'il est payé il te fait gagner en productivité et en souplesse. C'est vraiment beaucoup plus puissant qu'une solution comme SVN.

[CinePhil]

Je crois que j'ai fini par comprendre en repartant avec un projet nu de test.

1) Création répertoire de projet sur serveur dev
mkdir /srv/www/htdocs/test
chown wwwrun:www test
chmod g+w test

2) Création projet PHP test dans Eclipse sur machine premier développeur (d1)

3) Initialisation git sur machine d1
cd /home/d1/workspace/test
git init

4) Ajout fichier test-local.php dans Eclipse sur machine d1

5) Ajout et commit local dans git sur machine d1
git add test-local.php
git commit -m "Premier commit local"

5) Création dépôt git nu sur machine d1
git clone --bare .git test.git

6) Transfert du dépôt nu sur le serveur
scp -r test.git git@172.26.1.15:/srv/www/htdocs/test

=> Le dépôt nu de la machine d1 ne sert plus et pourra être supprimé par la suite

7) Clonage du dépôt nu sur machine développeur 2 (d2)
cd /home/plemenager
mkdir test
git clone git@172.26.1.15:/srv/www/htdocs/test/test.git

=> Crée un répertoire /home/plemnager/test/test avec le fichier test-local.php et un dépôt git (master) dans ce répertoire.

8) Ajout du dépôt nu du serveur en tant que origin sur la machine d1
git remote add origin git@172.26.1.15:/srv/www/htdocs/test/test.git

9) Ajout fichier entete.php et modification fichier test-local.php dans projet test dans Eclipse sur machine d1

10) Ajout et commit local dans git sur machine d1
git add test-local.php
git add entete.php
git commit -m "Deuxième commit local sur machine d1"

11) Envoi des modifications sur le serveur de dev
git push origin master

12) Récupération des modifications sur machine d2
git pull

13) Ajout fichier footer.php sur machine d2

14) Ajout et commit sur machine d2
add footer.php
commit -m "Ajout footer.php depuis machine d2"

15) Envoi sur le serveur depuis machine d2
git push origin master

16) Partage du projet Eclipse sur machine PL
Clic droit sur projet puis Team / Share project
Eclipse trouve le dépôt .git du projet et sa configuration avec le dépôt distant.

17) Création fichier contenu.php et modification test-local.php sur machine d1 dans Eclipse

18) Ajout et commit des modifications dans Eclipse sur machine d1


Le système fonctionne donc avec un "dépôt nu" sur le serveur qui était au départ un clone du premier dépôt de la machine du développeur 1. Ce n'est pas super clair dans le book de Git. Je ferai un tuto simple sur mon blog DVP plus tard.

Merci pour l'aide ; ça m'a quand même donné des pistes de compréhension.

Il me reste à trouver comment installer automatiquement les fichiers validés du projet sur le serveur pour qu'on puisse accéder à l'application depuis le réseau. C'est une autre aventure que je verrai un peu plus tard.