Git... ou Subversion ?

Salut,
J’ai un projet de développement d’un CMS perso pour un portail Web.

J’ai entendu, et parfois utilisé pour récupérer des sources, parler de Git.

Il y en a ici qui l’utilisent pour du développement ?
Est-ce compliqué à installer et à utiliser ?

J’ai du mal à comprendre comment ça fonctionne… J’ai bien lu la doc et wikipédia, mais ça reste un peu flou.

Merci.

C’est un très bon outil, incomparable avec Subversion ou Bazaar (CVS j’en parle même pas c’est une horreur), mais pas forcément facile à prendre en main au départ.

Question installation : y’a rien à faire, tu installes les paquets Debian et c’est marre (je pars du principe que tu te contenteras d’un dépôt local, pour les dépôts distants ça doit pas être bien compliqué vu qu’il a un mode SSH).
Question utilisation… faut s’y faire. Ce tuto semble assez complet : unixgarden.com/index.php/gnu … ine/git-it

Ne pas oublier de le rendre un peu plus clair en rajoutant des couleurs et un pager digne de ce nom :

# aptitude install less $ git config --global core.pager less $ git config --global color.ui auto $ git config --global color.diff auto

Salut,
Merci pour le lien. C’est (un peu) plus clair.

Je vais travailler avec des personnes sous Windows et MacOs, j’ai vu sur le site de git que ce n’est pas un souci, c’est bien.
Je suppose qu’il y a des interfaces graphiques, au moins pour se faire la main.

Tout ça m’a l’air très bien…

Sais-tu s’il est possible que la version d’un projet “à jour” soit en ligne en permanence (sur un serveur apache s’il s’agit d’un programme en php) ?

J’en avais testé quelques unes, elles sont pas vraiment satisfaisantes. Le problème la plupart du temps c’est que git est tellement puissant et souple que c’est très dur de le “faire rentrer” dans une interface utilisateur.
Le moins pire que j’avais vu était SmartGit (pas terrible au moment où je l’ai testé mais d’après leur site il y a eu beaucoup d’améliorations depuis – gratuit pour utilisation non-commerciale et, de mémoire, en Java donc multi-plateforme).

Tu veux dire dès qu’il y a un push sur le serveur de “référence”, que les fichiers du site web soit mis à jour ?
Modifs locales -> commit local -> push sur le serveur distant -> checkout sur le serveur distant. Ça devrait le faire.

Sinon si tu développes de l’open-source, tu peux aussi utiliser un truc genre github qui a en plus un issue-tracker et un wiki. Dans ce cas là ça donnerait plutôt quelque chose du genre :
Modifs locales -> commit local -> push sur github -> pull sur le serveur distant -> checkout sur le serveur distant (ce dernier point étant peut-être inclus dans le pull, je sais plus car je fais quasiment jamais de pull :mrgreen:).

Perso j’ ai juste eu à télécharger des sources avec git et ça fait comme svn (pour télécharger)

à mettre en place derrière je n’ en ai aucune idée par contre :033

Salut,

Je n’ai pas eu le temps de regarder plus en détail. Je pense que ce sera un git centralisé…

Github…
J’ai besoin de protéger mon code au moins jusqu’à ce que mon site soit opérationnel, je n’ai pas envie de me faire couper l’herbe sous le pied… Disons que le “concept”, je deteste ce mot… que l’idée est un peu novatrice dans mon coin. :wink:

Merci pour vos réponses.

Re-salut,

Dans mes recherches, je suis tombé (évidemment…) sur subversion.
Même question que pour Git… Quelqu’un l’utilise pour de la gestion de projet ?
Les avantages et les inconvénient par rapport à Git ?

Merci.

Subversion est très bien… si tu as pas besoin de faire beaucoup de branches, et que les membres de l’équipe ne travaillent pas trop sur les mêmes fichiers (sinon bonjour les problèmes de merge !). :eusa-whistle:

Pour la petite histoire, ça fait des années que j’utilise SVN, et très peu de temps que j’utilise git (à peine deux mois), mais malgré le fait que je ne sache pas encore me servir totalement de git je peux dores et déjà te dire que c’est le jour et la nuit. Mon avis : t’emmerde pas avec Subversion (comme dit Torvalds : « SVN avait pour but d’être un CVS done right, mais rien qui soit basé sur CVS ne peut donner quoi que ce soit de bon » – traduction libre, l’original est bien plus virulent comme à son habitude), prends directement des bonnes habitudes avec git.
Perso j’attends encore un peu d’être plus à l’aise avec pour migrer mes projets pro, mais c’est simplement parce que je suis, par définition, réticent à changer quelque chose qui marche. Si demain je devais commencer un nouveau projet ça serait sous git.

La grosse différence (qui fait toute la force de git à mon avis) c’est le côté distribué (chaque dév. a son propre dépôt complet sur sa machine au lieu de devoir accéder à un serveur central), et une gestion des branches grandement simplifiée.
Résultat : pour implémenter un truc tu fais une branche locale, tu codes, tu commit dans ta branche autant que tu veux, et quand elle est prête tu merge dans le tronc commun.
Sous SVN gérer les branches c’est une véritable horreur, du coup tout le monde commit direct dans le tronc commun par flemme, et sur le serveur central qui plus est, ce qui fait que le dépôt est beaucoup moins propre et ça se ressent forcément dès que tu veux par exemple trouver l’origine d’un bug ou revenir en arrière de quelque manière que ce soit.

[code]SVN: tronc commun -> commit 1 personne X -> commit 1 personne Y -> commit 2 personne X -> commit 3 personne X -> commit 2 personne Y -> …

git: tronc commun … -> fonction 1 -> fonction 2
|-> branche personne X -> commit 1 -> commit 2 -> … ->^ ^
|-> branche personne Y -> commit 1 -> commit 2 -> … ->|[/code]

Re,
Effectivement, ce sera donc Git… Et peut-être même gitorious… :wink:
gitorious.org/debian-gitorious

Merci.

Tu as deux familles de gestionnaire de version. Les centralisés plus anciens (CVS et SVN pour les plus connu) et les gestionnaires de versions décentralisés (git, mercurial, bazaar, svk et d’autres).

La principal différence c’est que dans un gestionnaire de version décentralisé chaque développeur aura l’ensemble du dépôt avec lui sur sa machine. Les commits sont local et il effectue des push pour envoyer ces commits vers un autre dépôt (pas nécessairement un dépôt central).

L’avantage des distribués c’est par exemple de pouvoir faire des commits sans connexion et de n’envoyer que quand tout est bien propre (c’est pas exaustif). L’avantage des centralisé c’est qu’ils sont plus simple, tu n’oublie pas de pusher, tout le monde travail sur un dépôt central.

On peut utiliser un gestionnaire de version décentralisé avec un dépôt central tout de même. On peut même utiliser un serveur subversion avec des clients git ou mercurial.

Les DCVS étant plus récents ils possèdent quelques fonctionnalité intéressante le merge plus efficace par exemple et leur architecture apporte quelques intérêt pas désagréable comme bisect (méthode qui permet de déterminer le commit exact où a eu lieux une régression).

On m’a dit beaucoup de mal sur git sous Windows et il paraît que mercurial est plus simple (quand on viens de git on galère quand même un peu). Bien que je sois un habitué de git, je pense réellement que mercurial a d’excellent atouts (il est réellement portable, il est extensible, il n’est pas écris par Linus, il est plus interopérable avec d’autres gestionnaires de version, sa mise en place en tant que serveur est paraît-il plus simple).

[quote=“lol”]Re,
Effectivement, ce sera donc Git… Et peut-être même gitorious… :wink:
gitorious.org/debian-gitorious

Merci.[/quote]
gitorious je suis pas un grand fan de son interface, je m’y perd tout le temps.Je te conseil de l’essayer avant (en tant qu’utilisateur) ^^

J’ai utilisé les deux, et actuellement pour notre équipe c’est git.
Difficile pour moi de cacher que j’ai encore du mal avec ce dernier, mais je fais avec. Je préférais de loin des outils centralisés.

De mon côté mon choix s’est porté sur Mercurial, notamment pour la portabilité qui lui était attribué, ses GUI matures (paraît-il, y’a TortoiseHG mais j’ai vu que TortoiseGit existait aussi) ou son intégration native dans Netbeans (même si je n’utilise que Mercurial en CLI et Vim en éditeur, je préfère faciliter la vie de ceux avec qui je peux travailler).
Paraît aussi que Git offre des fonctionnalités très puissantes difficilement réalisable sous Mercurial, mais que ce dernier possède une interface en CLI plus élégante et homogène.

Utilisant SVN au boulot, c’est un bonheur de retrouver un DVCS pour mes projets perso.

Pour ajouter mon petit grain de sel, je dois avouer une grande préférence pour mercurial (hg), parce que:

  • C’est le premier que j’ai utilisé, donc j’en ai pris l’habitude. Par suite, je dois avouer que son utilisation est facile à prendre en main. Contrairement à git qui lui m’a complêtement perdu par la suite!
  • Il faut avouer que c’est cool, il utilise le symbole chimique du mercure, c’est le genre de chose qui fait chavirer mon coeur! :wink:

Pour mercurial, le site de bitbucket offre un hébergement gratuit. Mais il est possible de l’installer en local sans souci :wink:

Cependant, mon avis est à prendre à la légère, car je ne développe pas assez pour utiliser le potentiel de ces gestionnaires à fond.

J’ajoute mon grain de poivre :mrgreen:

Git est très orienté “GNU/LINUX” les client Windows sont un cran (voir deux) en deçà. Pour info il est écrit en C et initié par Torvald. Extrêment souple, mais du coup complexe a maitriser.
Mercurial est le grand concurent, il est écrit principalement en Python ce qui le rend bien plus portable. il est légèrement plus ancien que Git. Il est dit plus facile a prendre en main que Git

Salut,
Merci pour vos retours d’expériences.
J’ai opté pour git + gitweb, autant commencer avec et ne pas prendre de “mauvaises” habitudes avec un autre gestionnaire de version.

D’une facilité déconcertante à installer…
J’ai collé ça sur mon dédié dans un vhost, ça roule. (des petits problèmes de droits à régler encore)

git clone git://git.domaine.tld/project.git/ Cloning into 'project'... warning: You appear to have cloned an empty repository.

Gitorious m’a découragé… On verra peut-être plus tard…

Réglé et opérationnel!
Merci.

:006

[quote=“lol”]Merci pour vos retours d’expériences.
J’ai opté pour git + gitweb, autant commencer avec et ne pas prendre de “mauvaises” habitudes avec un autre gestionnaire de version.

D’une facilité déconcertante à installer…[/quote]
Tiens ? Ça m’intéresse j’ai commencé dimanche avec gitolite réputé simple et en voulant faire “propre” et utilise le paquet Debian je me retrouve à lire les scripts perl pour savoir pourquoi tel ou tel erreur arrive.

Je regarderais du coté de gitweb du coup, merci.

On m’a dit le plus grand bien de redmine en tant qu’utilisateur je l’ai pas mal appréciée c’est une forge complète (gestion de bug, forum, gestion de fichier à télécharger, gestion de projet avec un planning entre autre, …) et pour ce qui est de l’installer d’après un ami ça ne prend que quelques minutes.

Note : en même temps que je viens de me rappeller que redmine a forké pour donner ChiliProject. C’est peut être mieux de garder dans cette direction si tu veux autre chose que gitorious.

Salut,
J’ai jeté un oeil, autant redmine à l’air facile à installer, autant chiliproject est une usine à gaz (pas de paquet Debian…).
Je me heurte à l’installation de ruby et cie…
Je ne maîtrise pas du tout les histoires de “bundle” c’est un peu la galère. :017

En insistant un peu (sur une machine de test…) je vais y parvenir, le projet à l’air sympa et très complet. :smiley:

edit: oups j’avais pas vu la date, ça fait un peu déterrage désolé

Si vous êtes plusieurs un peu éparpillés à travailler sur le projet, c’est en effet une excellent idée d’installer une “forge” (redmine, trac…)
la possibilité de créer des tickets pour se répartir les tâches, de se mettre un calendrier prévisionnel (les “jalons” de trac) et de suivre l’avancement au quotidien en nombre de tickets restant à fermer, de coupler ça facilement à un wiki et un un dépôt de documents, etc. ça n’a pas de prix.
J’aime beaucoup trac que je connais bien mais redmine qui semble assez proche dans l’esprit a d’excellents retours également.