Skip to main content Help Control Panel

Cybermedium

webdevelopper
webdesigner
webmaster

Utilisez GIT pour maintenir vos scripts YACS

Home Téléchargez

SELECT * FROM yacs_files AS files WHERE (files.anchor LIKE 'article:48') AND (files.active='Y') ORDER BY files.rank, edit_date DESC, files.title LIMIT 0,300
1054: Unknown column 'files.rank' in 'order clause'

Ce tutoriel a pour vocation de montrer les premières bases de GIT - sans cependant refaire la même chose que les tutoriels existants sur le web - et susciter l'intérêt de son usage pour YACS.
Le premier intérêt de GIT, c'est d'abord un moyen de maîtriser le versioning chez soi. Pour les intégrateurs yacsiens, GIT permet ainsi de maintenir facilement des "forks" de Yacs, en production chez vos clients.
En effet un upgrade de Yacs écrase les modifications sur les sources. Nous verrons comment avec GIT reporter automatiquement nos modifications dans une nouvelle version des scripts de Yacs.

GIT se prononce "guitte".
Wikipédia :
" Le magazine PC World nous apprend que « quand on lui a demandé pourquoi il avait appelé son logiciel "git", qui est à peu près l'équivalent de « connard » en argot anglais, Linus Torvalds a répondu « Je ne suis qu'un égocentrique, donc j'appelle tous mes projets d'après ma propre personne. D'abord Linux, puis Git. » " "


Pré-requis



Il faut bien sûr avoir GIT installé sur votre machine. J'ai réalisé ce tutoriel sous Linux Mint ; GIT fait partie des dépôts classiques. Sous Linux, GIT se pilote principalement en ligne de commande.

Il faut configurer quelques options générales pour GIT, en commençant par english flag vous identifier. Ceci ajoutera votre nom à chaque commit, et sera bien utile dans le cas de développement à plusieurs.

Il existe bien english flag d'autres configurations, je conseille la coloration (en ajoutant --global pour ne pas le refaire dans chaque répertoire de travail).

GIT bases

Initializing working directory

GIT se déclenche au niveau d'un répertoire, pour tous les sous répertoires et fichiers contenus. C'est archi-simple : créer ou aller dans un répertoire de travail, ouvrir un terminal dedans et faire : [style=terminal]$ git init[/style] Réponse : [style=terminal] Initialized empty Git repository in /home/.../yourfolder/.git/[/style] GIT a créé un répertoire caché [i].git[/i] à la racine du répertoire de travail, et stockera ses données dedans. Aucun autre fichier n'est placé ailleurs.

Adding Files

Si votre répertoire est vide, il faut créer ou copier des fichiers dedans. Faites cela avec votre moyen préféré. Pour l'exemple, j'ajoute ici un fichier testgit.html :
testgit.html
<html>
<
head>
    <
title>Test pour GIT</title>
</
head>
<
body>
    <
h1>/(bb|[^b]{2})/</h1>        <div>
        <
span>.-"""-.</span><span>/ _  _ \</span>
        <span>??  ](_' `_)[  ??</span><span>`-. N ,-'</span>
        <span>|===|</span><span>`---'</span>
    </div>
</body>
</html><
page de test html testgit.html
Maintenant, toujours dans notre terminal, faisons juste pour voir : [style=terminal]$ git status[/style] Réponse : [style=terminal]# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add filename..." to include in what will be committed)
#
# testgit.html
nothing added to commit but untracked files present (use "git add" to track)[/style]

Git nous dit qu'un fichier est présent mais non indexé. [style=terminal]$ git add testgit.html
$ git status[/style] le nouveau fichier est maintenant suivi. il ne reste qu'a commiter. On peut ajouter tous les fichiers du répertoire avec "git add *"

Commit Changes

[style=terminal]$ git commit -m "ajout fichier testgit.html"[/style] tout commit doit être accompagné d'un message. l'option -m permet de fournir le message en ligne de commande. Sinon GIT ouvre un éditeur pour faire cette saisie (vim). Vous trouverez un english flag tuturiel vidéo plus détaillé pour cette partie.

Branching

Maintenant nous allons faire de nouvelles modifications, mais dans une branche. Il est extrêmement facile avec GIT de créer une branche, puis de fusionner ses développements plus tard avec une autre branche. Aussi il ne faut pas hésiter à créer de multiples branches pour vos développements. On crée une branche ainsi : [style=terminal]$ git branch experience[/style] avec ici "experience", le nom de la branche. Vous pouvez visualiser les branches existantes ainsi : [style=terminal]$ git branch[/style] La branche avec une étoile est la branche active. La branche créée par défaut s'appelle master. On change de branche active ainsi : [style=terminal]$ git checkout experience[/style] Refaire [i]git branch[/i] pour voir. Au niveau des fichiers, rien ne s'est encore passé.

Maintenant, faisons de nouvelles modifications, et même, ajoutons un fichier.
modifs sur testgit.html et ajout style.css
<html>
<
head>
    <
title>Test pour GIT</title>
    <
link rel="stylesheet" type="text/css" href="style.css" media="all" />
</
head>
<
body>
    <
h1>/(bb|[^b]{2})/</h1>    <div>
        <
span>.-"""-.</span><span>/ _  _ \</span>
        <span>??  ](_' `_)[  ??</span><span>`-. N ,-'</span>
        <span>|===|</span><span>`---'</span>
    </div>
</body>
</html>


h1 {
    
text-align center;
    
color firebrick;
}

div {
    
margin 40px
}

div span {
    
display block;
    
text-align center;
    
font-family monospace;
}
feuille de style style.css
Un petit commit : [style=terminal]$ git add style.css
$ git commit -a -m "adding a style sheet"[/style] Un [i]git status[/i] doit donner "working directory clean". [*] Visualiser votre page dans un navigateur et retournons sur la branche master : [style=terminal]$ git checkout master[/style] [*] Recharger la page dans votre navigateur... Surprise ?

[*] Regardez vos fichiers : le nouveau fichier a disparu, et le contenu de l'autre est revenu à l'état initial. [*] Retournez sur la branche experience (git branch experience) : les modifications réapparaissent.

En fonction de la branche active, GIT change dynamiquement le contenu de votre répertoire de travail.
 

Merging

Faisons d'abord des nouvelles modifications sur la branche master [style=terminal]$ git checkout master[/style]
modifs sur test.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
>
<
html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<
head>
    <
meta http-equiv="Content-Type" content="text/html; charset=utf-8" />    
    <
title>Test pour GIT</title>
</
head>
<
body>
    <
h1>/(bb|[^b]{2})/</h1>    <div>
        <
span>.-"""-.</span><span>/ _  _ \</span>
        <span>??  ](_' `_)[  ??</span><span>`-. N ,-'</span>
        <span>|===|</span><span>`---'</span>
    </div>
</body>
</html>
et commitez-les : [style=terminal]git commit -a -m "doctype declarations")[/style]

Chaque branche contient maintenant des modifications uniques.

[*] Fusionnons experience dans master : [style=terminal]$ git merge experience[/style] [*]Contrôlez le résultat en rechargeant la page. [*]Dans le terminal, tapez "gitk" pour avoir un aperçu graphique de vos opérations.

Merging conflict

Bien sûr parfois GIT ne peut se dépatouiller tout seul avec des modifications contradictoires. Dans ce cas il signale un conflit et place un marquage spécial à l'intérieur du fichier. A vous de résoudre le conflit en éditant le fichier. Plusieurs commandes peuvent vous aider à visualiser les différences entre les versions. Voici un tutoriel english flag branching & merging pour plus de détails (vidéo en fin de page)

Voir aussi plus bas pour la résolution d'un conflit.

Upgrading a fork

Dans le cadre de cet exemple, supposons un projet démarré en Yacs, sur lequels vous avez dû effectuer quelques modifications dans les sources pour répondre à votre client. Une nouvelle version de yacs est sortie et vous souhaitez migrer. La mise à jour du serveur entraîne l'écrasement des fichiers et donc la perte de vos modifications. Il faut donc avoir consciencieusement noté chaque modification, et les reporter à la main dans les nouvelles versions des scripts, puis les uploader sur votre serveur après sa mise à jour. Cela peut être fastidieux...

La méthode ci-dessous permet d'automatiser l'intégration de vos modifications dans les nouveaux scripts de Yacs.

Indexing a Yacs serveur

Dans un répertoire, placer les scripts d'un serveur Yacs. Pour cet exemple je me limite à quelques fichiers. C'est du vécu : ajouter aux catégories l'option de listage des utilisateurs par ordre alphabétique. Je pars d'une 9.11. On va migrer ensuite vers 10.5. Je donne les fichiers de chaque version en zip ici pour refaire les tests chez vous. [*]categories/view.php [*]shared/members.php
Fichiers provennant de yacs9.11
indexez les fichiers [style=terminal]$ git add *[/style] puis commitez [style=terminal]$ git commit[/style] Vous pouvez étiqueter cet état de la branche avec le numéro de version [style=terminal]$ git tag v9.11[/style]

Branching to customize

[*]Créer une nouvelle branche pour votre projet spécifique [style=terminal]$ git branch MyClient
$ git checkout MyClient[/style] [*]Modifiez les fichiers pour appliquer vos modifications (en un ou plusieurs commits) en l'occurence : dans shared/members.php, insertion d'une nouvelle fonction après la fonction list_users_by_post_for_anchor (L994)
listage des utilisateurs par nom
/**
     * list alphabetically users assigned to an anchor
     *
     * Only users matching following criteria are returned:
     * - user is visible (active='Y')
     * - user is restricted (active='R'), but surfer is a logged user
     * - user is restricted (active='N'), but surfer is an associate
     *
     * @param the target anchor
     * @param int the offset from the start of the list; usually, 0 or 1
     * @param int the number of items to display
     * @param string the list variant, if any
     * @param string an id to avoid, if any
     * @return NULL on error, else an ordered array with $url => ($prefix, $label, $suffix, $icon)
     *
     * @see categories/view.php
     */
    
function &list_users_by_names_for_anchor($anchor$offset=0$count=10$variant=NULL$to_avoid=NULL) {
        global 
$context;

        
// locate where we are
        
if(!$variant)
            
$variant $anchor;

        
// limit the scope of the request
        
$where "users.active='Y'";
        if(
Surfer::is_logged())
            
$where .= " OR users.active='R'";
        if(
Surfer::is_associate())
            
$where .= " OR users.active='N'";
        
$where '('.$where.')';

        
// avoid this one
        
if($to_avoid)
            
$where .= " AND (users.id != '".SQL::escape($to_avoid)."')";

        
// the list of users
        
$query "SELECT users.*    FROM ".SQL::table_name('members')." AS members"
            
.", ".SQL::table_name('users')." AS users"
            
." WHERE (members.anchor LIKE '".SQL::escape($anchor)."')"
            
."    AND (members.member_type LIKE 'user')"
            
."    AND (users.id = members.member_id)"
            
."    AND ".$where
            
." ORDER BY users.full_name, users.nick_name LIMIT ".$offset.','.$count;

        
// use existing listing facility
        
$output =& Users::list_selected(SQL::query($query), $variant);
        return 
$output;
    }
[*]Dans categorie/view.php, à la L789, changer :
implémentation option users_by_name
// list items by date (default) or by title (option 'users_by_title')
        
$offset = ($zoom_index 1) * USERS_LIST_SIZE;
        
$items =& Members::list_users_by_posts_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE'watch');
par :
// list items by date (default) or by name (option 'users_by_name')
        
$offset = ($zoom_index 1) * USERS_LIST_SIZE;
        if(
preg_match('/\busers_by_name\b/i'$item['options']))
            
$items =& Members::list_users_by_names_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE'watch');
        else
            
$items =& Members::list_users_by_posts_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE'watch');
[*]Commitez : [style=terminal]git commit -a -m "added alpha order option for listing users on catergories"[/style]

Vous avez donc : [*]une branche master, qui contient les scripts originaux de yacs. [*]une branche MyClient, avec vos modifications spécifiques.

Vous pouvez créer autant de branches "client" à partir de master, et les compléter à mesure des évolutions de chaque projet, en activant la branche appropriée. Un seul répertoire contient tous vos serveurs !
Vous pouvez copier votre répertoire de travail, toutes les informations de GIT seront également dupliquées puisqu'elles sont dans le répertoire .git, et pourront êtres manipulées de manière distincte de l'original.
Un intérêt est de placer votre répertoire de travail pour le faire également tourner sous XAMPP par exemple. Dans ce cas vous pouvez avoir besoin d'éliminer certains fichiers de l'indexation GIT, moyennant la déclaration d'un fichier [i].gitignore[/i].
 

Rebasing to upgrade

Une nouvelle version de Yacs est dispo ! [*]Commençons par mettre à jour la branche master : fichiers de 10.5 fichiers provenant de yacs 10.5 [style=terminal]$ git checkout master[/style] supprimez tout le contenu, puis copiez dedans l'intégralité de la nouvelle archive. Commitez... votre branche master est à jour ; une mise à jour par écrasement ne permet pas de supprimer les fichiers obsolètes - pas dans cet exemple bien sûr.

[*] Maintenant il faut upgrader la branche MyClient. Nous voulons en fait reporter les modifications spécifiques sur les nouveaux scripts. C'est exactement ce que fait la commande "rebase" : elle initialise la branche selon la branche modèle, et applique les modifications dessus comme si c'était des patchs. C'est différent du merge, pas du point de vue du résultat produit sur le code, mais plutôt dans l'ordre dans lesquels les commits sont archivés.

[style=terminal]$ git checkout MyClient
$ git rebase master[/style]

Tout se passe bien pour shared/members.php, mais nous avons un conflit sur categories/view.php.

[style=terminal]First, rewinding head to replay your work on top of it...
Applying: added alpha order option for listing users on catergories
error: patch failed: categories/view.php:786
error: categories/view.php: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging categories/view.php
CONFLICT (content): Merge conflict in categories/view.php
Auto-merging shared/members.php
Failed to merge in the changes.
Patch failed at 0001 added alpha order option for listing users on categories

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
[/style]

[*]Éditez le fichier en conflit. Rechercher "=====" pour tomber sur les marqueurs spéciaux de ligne en conflit. Nous voyons ceci :
conflict in view.php
<<<<<<< HEAD:categories/view.php
        $items 
=& Members::list_users_by_posts_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE$layout);

===

        if(
preg_match('/\busers_by_name\b/i'$item['options']))
            
$items =& Members::list_users_by_names_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE'watch');
        else
            
$items =& Members::list_users_by_posts_for_anchor('category:'.$item['id'], $offsetUSERS_LIST_SIZE'watch');
>>>>>>> 
added alpha order option for listing users on catergories:categories/view.php
d'abord GIT affiche la version d'origine, ici celle de la branche master, et sous les ==== le patch qu'il tentait d'appliquer (avec à la fin l'intitulé du message qui accompagnait le commit en question. Cela n'a pas marché car entre 9.11 et 10.5, les catégories ont gagné la capacité d'offrir le choix du layout utilisateur : au lieu d'imposer un layout en dur (watch), cela passe par une variable $layout. Il faut donc remplacer nos 'watch' par $layout. On efface ensuite ce qui est inutile (l'ancienne version, et les marqueurs)

[*]Maintenant pousuivons : [style=terminal]$ git add categories/view.php
$ git rebase --continue[/style]

Une fois cette opération terminée, la branche MyClient contient vos modifications appliquées sur la nouvelle version de Yacs. Vous pouvez mettre à jour votre serveur distant avec l'archive standard puis uploader les fichiers modifiés depuis votre répertoire de travail.

une solution encore plus propre serait de construire une archive de mise à jour spécifique à partir du script build.php de Yacs, mais cela c'est un autre tutoriel !

Conclusion



GIT rend déjà beaucoup de services "à la maison" avec un système de versioning très puissant et pourtant simple d'apparence. Ce tutoriel en donne un aperçu. Bien sûr il y aurait des cas particuliers. Que se passe-t-il par exemple si on ne souhaite plus reporter une modification ? Afin de pouvoir isoler vos modifications, il est plus sage de les indexer via des commits distincts. GIT permet ensuite d'annuler un commit précis.

Autres tutos :
french flag Git dans une coquille de noix
english flag git ready

comparaison GIT avec d'autres [i]subversion systems[/i]
english flag Why git is better than X
DouglasGew
on Oct. 18 2018 at 08:52 am GMT
Http://vioglichfu.7m.pl/index.php?n=25&id=46463 [url=http://vioglichfu.7m.pl/index.php?n=25&id=361010#]cialis ohne rezept england[/url] <a href="http://vioglichfu.7m.pl/index.php?n=25&id=44979#">cialis once a day 5mg</a>

Alexis Raimbault
on June 23 2010 at 01:20 pm GMT

Petit complément sur l'indexation d'une archive YACS par GIT.

Ce qui est pratique, c'est de pouvoir indexer une archive tout en pouvant la faire tourner sous XAMPP par exemple.
Cette configuration vous permet de switcher d'une version à l'autre de Yacs très rapidement.

Mais sur un serveur actif, certains fichiers ne doivent pas être indexés. On utilise alors un mécanisme de GIT pour ignorer certaines parties de l'archive.
GIT propose en fait plusieurs mécanismes pour cela, suivant la portée des règles :

  • systématique pour votre machine de developpement ;
  • locales au projet et spécifiques à votre machine ;
  • spécifique au projet, à partager avec les autres contributeurs.


Dans le cadre d'un co-développement de Yacs c'est la troisième méthode qui nous intéresse le plus. Il s'agit simplement d'ajouter un fichier .gitignore à la raçine du projet. Ce fichier sera indexé par GIT comme partie prenante du projet (à moins de l'exclure lui même dans les déclarations).

Voici les règles que j'ai établies pour ce fichier. Le principe est d'éliminer tous ce qui est spécifique à une installation et non pas à la version du système.

 [small]Aperçu de la syntaxe usitée : Git Pro:recoding change to directory au paragraphe "Ignoring files"[/small]


[style=terminal]
# Ignore htaccess at root level only
/.htaccess

# Ignore parameters
parameters/
!parameters/index.php

# Ignore images and files sub-folder content
images/*/
files/*/

# Temporary folder
temporary/
!temporary/index.php

# Inbox folder
/inbox

# Scripts
scripts/run_once/
scripts/staging/

#bak files
*.bak

# Some temporary files from editors
*~
*.swp

# OS generated files
.DS_Store?
ehthumbs.db
Icon?
Thumbs.db
[/style]

En ce qui concerne les scripts "run_once", je les ai retirés car yacs peut transformer ces fichiers en *.done, ce qui nuit à l'indexation. Mon avis est de gérer le versioning des run_once à part de l'archive Yacs.


gitignore.zip

photo
webdesign templating by webmaster Alexis Raimbault