Après une demi journée passée à lire de la documentation sur git, je partage la synthèse.
Mon besoin est de créer un repository central et de travailler à la manière de SVN.
Remarque : GIT est à la base conçu pour travailler de manière décentralisée.
Pour ma société Liberasys, je voulais quelque chose de simple, efficace. Le mode de fonctionnement SVN correspond à ce que je veux.
Les notes sont en anglais, désolé pour les non anglophones.
# from : https://git-scm.com/docs/gitcore-tutorial
# Directories
.git/objects/ : real repository data (identified by SHA-1)
.git/refs/ : references to objects (heads of development, revision tags)
# Remarquable files
.git/HEAD : Master head : points to default branch
.git/index : describes your current working tree
# Objects types and content
# RQ : objects are immutable
git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238 : gives the type of the file
git cat-file blob 557db03de997c86a4a028e1ebd3a1ceb225be238 : gives the content of the file
# Diff commands and comparisons (by Jon Loeliger) :
diff-tree
+----+
| |
| |
V V
+-----------+
| Object DB |
| Backing |
| Store |
+-----------+
^ ^
| |
| | diff-index --cached
| |
diff-index | V
| +-----------+
| | Index |
| | "cache" |
| +-----------+
| ^
| |
| | diff-files
| |
V V
+-----------+
| Working |
| Directory |
+-----------+
# Configure information about git user
git config --global user.email "user@domain"
git config --global user.name "firstname lastname"
# Initialise git repository
mkdir test && cd test
git init
# Populating repository
echo "Hello World" >hello
# Index (cache)
echo "Silly example" >example
git update-index --add hello example
# Get diff-files : difference between current working directory and index file
git diff-files : raw summary
git diff : readable differences (= git diff-files -p)
# Get diff-index
git diff HEAD (= git diff-index -p HEAD) : differences between a commited tree and the working directory
git diff-index --cached -p HEAD : compares a tree and the index cache content
# Create a tree
git write-tree : Raw way to create a tree
# Create initial master tree (new commited tree, related to nothing else : the master tree)
tree=$(git write-tree)
commit=$(echo 'Initial commit' | git commit-tree $tree)
git update-ref HEAD $commit
# Making a change
# Process : working tree -> index file -> commited tree
git rm <file> : remove files from index (=git update-index --remove <file>)
git add <file : add files to index (= git update-index --add <file>)
git update-index hello example : updates index of files
git diff : show differences with index
git diff HEAD : show the differences with a tree (HEAD pointer tree)
git commit : store a change in the repository, give a commit message !
: all lines beginning with # will be ignored
# Get diff-tree : difference between two trees
git diff-tree -p HEAD : difference between the commited tree and the master tree
git diff-tree -p HEAD --pretty : idem, with metadata of commits
# Tags
git tag my-first-tag : light tag (branch put in the .git/refs/tags/ diretory rather than .git/logs/refs/heads)
git diff my-first-tag : diff between the tag and the working directory
git tag -s my-major-tag : real git object, will sign current HEAD
git tag <tagname> <mybranch> : tag from a branch
# Branches
git checkout -b <mybranch> : creates a branch (pointer into the Git object database in .git/refs/heads/)
git checkout -b <mybranch> <earlier-commit> : creates a branch from an earlyer commit (tag or branch)
git branch : displays the current branch
# Copy locally a repository
cp -a repo-src repo-dst
cd repo-dst
git reset # does :
git read-tree --reset HEAD # total index rebuild
git update-index --refresh # makes sure to match up all index entries with the checked-out files
# Copy remotely a repository
git clone git://git.kernel.org/pub/scm/git/git.git/ my-git
cd my-git
git checkout
# Switch between tags and branches
git checkout <name> : name can be a branch or a tag
# === Git, SVN way (with user groups) / server
# install git-core and git packages
adduser git
mkdir /pub
mkdir /pub/my-repo.git
chown -R git:git /pub/my-repo.git
su - git
cd /pub/my-repo.git
git --bare init --shared
# gives SSH accces to this directory from the users
# remark : you can use git-shell in order to limit system exposure
# as root:
USERNAME="myuser"
KEYSDIR="/data/keys"
adduser --shell /usr/bin/git-shell --ingroup git --disabled-password ${USERNAME}
mkdir -p ${KEYSDIR}/${USERNAME}
cd ${KEYSDIR}/${USERNAME}
ssh-keygen -t rsa -b 4096 -f ${USERNAME}_rsa_4096 -P ""
mkdir /home/${USERNAME}/.ssh
cp ${USERNAME}_rsa_4096.pub /home/${USERNAME}/.ssh/authorized_keys
chmod 700 /home/${USERNAME}/.ssh
chmod 600 /home/${USERNAME}/.ssh/authorized_keys
chown -R ${USERNAME}:git /home/${USERNAME}/.ssh
# now send the ${USERNAME}_rsa_4096 file to your new user
# ask him to put a passphrase to the key with :
ssh-keygen -f <keyfile> -p
# ask him to put the file in ~/.ssh/git_<original key file name>
# === Git, SVN way (with user groups) / user
# if not already done for the user :
git config --global user.email "user@domain"
git config --global user.name "firstname lastname"
# 1) === initial clone
export GIT_SSH_COMMAND='ssh -i <private_key_file>'
git clone foo.com:/pub/my-repo.git
cd my-repo
# remark : either do the export each time you use a new shell, either configure the .ssh/config file
# 2) TO DO ONLY ONE TIME : create master tree and HEAD link
tree=$(git write-tree)
commit=$(echo 'Initial commit' | git commit-tree $tree)
git update-ref HEAD $commit
git push origin master
# 3) === make local changes then commit them locally
# do not forget git add/rm/mv
git diff
git diff -p HEAD
git commit
# or :
git commit -a
# 4) === fetch changes from remote repository (merge them with local repository - always commit before)
git pull origin
# 5) === push the commits to the remote repository
git push origin master
# then iterate to 3)Je ne sais pas si le mode de fonctionnement proposé est "carré". Je compte sur les commentaires acerbes des lecteurs :-)
En tout cas cela fonctionne avec mes tests initiaux. J'espère que cela motivera certains à essayer voir à utiliser git au quotidien ?
Par ailleurs, quand je voudrai libérer des sources, je me demande si un téléversement d'un repository sera possible et aisé vers github ou gitlab (avec reprise des versions et métadonnées) ?
PS : la clef SSH initiale générée pour un utilisateur est non chiffrée. il faut donc la transmettre de manière sécurisée.
# Bonjour
Posté par Marotte ⛧ . Évalué à 8.
Je ne connais pas SVN, c’est peut-être pour ça que je ne comprends pas ton journal…
Git est bien conçu pour travailler de manière décentralisée, on peut cloner n’importe quel dépôt (même un dépôt de travail) cependant le dépôt de référence (ie: bare repository) représente bien une centralisation du développement ?
Voilà, est-ce que tu pourrais expliquer un peu plus ton idée, la problématique que tu as en utilisant Git « normalement » ?
[^] # Re: Bonjour
Posté par ghusson (site web personnel) . Évalué à 3.
Dans le processus conseillé de git (je n'arrive plus à retrouver le lien), cela me semblait compliqué (une personne chargée de centraliser, valider les patchs, appliquer + un serveur d'export éventuellement avec un repack …).
J'ai donc cherché un processus plus simple. Je n'utilise pas git, je débute :-) J'ai trouvé qui guide pour une utilisation à la SVN, ça m'a plu.
[^] # Re: Bonjour
Posté par Sufflope (site web personnel) . Évalué à 6.
Mouais ou sinon un dépôt "central" sur l'infra et clone pull push, quel rapport avec valider les patchs etc. ? Même si par ailleurs travailler "à la SVN" en mode "je commit direct sur master" est évidemment une mauvaise idée de workflow en général mais c'est un peu indépendant du fait que le dépôt de la boîte est le seul officiel et pas celui local sur l'ordi d'un mec.
[^] # Re: Bonjour
Posté par Marotte ⛧ . Évalué à 3.
En plus ça m’a l’air assez simple de faire le travail de validation de patch avec Git. Celui qui valide les patches c’est celui qui crée une branche dans son propre dépôt dans le seul but de merger la branche machin et la branche bidule (voir seulement certains de leurs commits), en résolvant éventuellement les conflits, et ensuite fait un merge final de celle-ci depuis LE master "officiel", depuis lequel on va livrer notre application, qui se trouve potentiellement sur un autre dépôt git que celui des développeurs, auquel lui seul à accès.
# git
Posté par CrEv (site web personnel) . Évalué à 8.
J'ai peut-être pas vraiment les yeux en face des trous ce matin, mais je comprend pas bien pourquoi faire ça.
En général (genre 99% du temps) il n'y a jamais besoin d'utiliser les commandes bas niveau de git genre
write-treeoucommit-treeSi le but c'est juste d'initialiser un dépôt vide avec une branche master distante :
Surtout avoir le
-uqui va permettre ensuite de ne plus jamais utiliserorigin master(en version courte hein). Ça va éviter pas mal de problèmes, surtout quand par la force de l'habitude quelqu'un fera ungit pull origin mastersans être dansmaster.Par contre j'ai toujours pas compris où tu voulais en venir.
Pourquoi ne pas déjà présenter le problème que tu veux résoudre ? Si le but est de fonctionner "comme svn" pourquoi ne pas prendre svn ?
Beaucoup de monde utilise git avec un dépôt central de référence (à la louche je dirais 99% du temps non ?).
Par contre les point qui changent le plus sont commits locaux, pull/push, merge, branch. En gros au final tout ce qui correspond à ton workflow. Donc c'est quoi ton workflow ?
Et j'ai l'impression aussi que tu es rentré dans pas mal de détails bien bas niveau (rien que les premières lignes de ton doc).
Si tu as un dépôt git il suffira d'ajouter une nouvelle remote pour pouvoir envoyer tout le dépôt.
[^] # Re: git
Posté par ghusson (site web personnel) . Évalué à 0.
Pourquoi faire ça : je ne sais pas, c'était dans la doc :-)
J'ai bien compris qu'il y avait des commandes simplifiées. Mais cela ne fait pas de mal de connaître un peu le fonctionnement interne. En l’occurrence, le paragraphe qui te choque est exécuté une seule fois à la création. Moi ça ne me pose pas de problème :-) Personnellement, j'aime bien avoir une vue (même partielle, mais des bases) de ce qu'il y a sous le capot pour réagir plus vite en cas de problème. Les notions de work dir, cache, tree sont à mon sens essentielles pour comprendre ce que l'on fait. D’où les premiers paragraphes.
Un serveur central de référence.
Des développeurs qui synchronisent régulièrement (au moins 1 fois / jour) leur développement sur le serveur.
Quand les développeurs sont satisfaits de leur travail (code fonctionnel, testé), il faut un processus de réconciliation (merge).
La je sèche un peu… entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?
Tu peux détailler STP ?
[^] # Re: git
Posté par CrEv (site web personnel) . Évalué à 9.
Je te dirais bien de changer de doc alors…
Avoir une idée de fonctionnement interne, de la plomberie, ok. Mais à mon avis si tu n'as jamais utilisé git le mieux serait de commencer par le fonctionnement externe.
Pas pour une utilisation basique, savoir où sont stockés les refs, comment fonctionnent les ids des blob, c'est pas tellement nécessaire dans un premier temps non.
Ouch, je sais même pas ce que vient faire
treelà dedans. Ni mêmetagd'ailleurs.?
Hop, tout est sur gitlab.
Mon conseil à 2 balles : commence par lire par exemple https://git-scm.com/book/fr/v2 (ou les tutos git sur github par exemple)
[^] # Re: git
Posté par ghusson (site web personnel) . Évalué à -2.
Merci pour tes retours. Je vais faire un premier cycle comme ça dans un premier temps.
Quand j'aurai de plus gros besoins, je lirai la doc (merci pour le lien) et j'installerai gitlab.
Pour le moment, j'avance. Ce sera toujours mieux que pas de repo du tout.
[^] # Re: git
Posté par CrEv (site web personnel) . Évalué à 8.
Je me répète (mais après j'arrête) : lis la doc (ce bouquin ou un autre, spa un problème) avant de faire un premier cycle sur des bases très sommaires et, il me semble, embrouillées aves des considérations bas niveau. Avancer c'est bien, mais si c'est mal fait ça peut aussi donner de mauvais résultats.
[^] # Re: git
Posté par ghusson (site web personnel) . Évalué à -5.
Merci pour le conseil. Voila ce qui va se passer (voir websérie " Les visiteurs du futur") :
- je vais faire comme ça pour le moment
- ça va merder
- je lirai la doc
- ça me donnera envie d'installer un gitlab
En attendant, j'ai un repo au lieu d'un répertoire non versionné.
Voir commentaire bookmark pour partager les liens, ça me servira dans quelques mois ;p
[^] # Re: git
Posté par CrEv (site web personnel) . Évalué à 5.
Mais pourquoi le faire alors ?
[^] # Re: git
Posté par ghusson (site web personnel) . Évalué à 1. Dernière modification le 24 novembre 2016 à 15:53.
Parce que je dois faire tourner ma boite :-) Tout ne peut pas toujours être parfait… (je me rends compte et j'accepte cela de plus en plus en étant "patron" :-).
Un investissement peut se faire en plusieurs phases, voir doit se faire en plusieurs phases selon les cas et les stratégies.
La, présentement, je n'ai pas 5 jours dispos pour me mettre plus sérieusement à git.
[^] # Re: git
Posté par Sufflope (site web personnel) . Évalué à 3.
Bah prend un plan en SaaS chez gitlab et voilà. Je crois même qu'ils proposent des dépôts privés dans l'offre gratuite.
[^] # Re: git
Posté par CrEv (site web personnel) . Évalué à 10.
Non mais juste non là.
Personne ne parle de passer 5 jours O_O
Et justement si tu n'as pas le temps, plutôt que de sortir des commandes bas niveau qu'aucun dev utilisant git n'utilise, prend un compte gitlab gratuit (2 minutes 30 en trainant un peu) plutôt que de passer du temps à faire de l'admin sys (à moins que ton job soit d'héberger du git je sais pas) et passe le reste du temps à lire une doc potable qui va t'apprendre à utiliser git correctement.
Et donc ça ne répond pas à la question posée ailleurs : ton équipe ne sait pas utiliser git du tout ? Parce que dans ce cas, si toi non plus il faudra bien que quelqu'un le sache, non ?
[^] # Re: git
Posté par groumly . Évalué à 10.
Mmh, si le but c'est d'avancer la maintenant tout de suite, tu te prends un compte github/gitlab a 10 dol' par mois, tu verrouilles master et tu demandes à tes gars d'envoyer des pulls requests. T'as ton git qui marche comme svn.
C'est ce que 90% de la planète fait. Pas besoin d'y passer 5 jours, ni de comprendre comment gît stocke ses objets.
Quand t'y voies plus clair et que t'as le temps de t'en occuper plus en avant, tu pushes ton repo sur une autre instance et c'est plié.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: git
Posté par Zenitram (site web personnel) . Évalué à 6.
Faudrait savoir : tu veux te faire plaisir à réinventer SVN n'importe comment, ou tu dois faire tourner ta boite?
Si l'idée est réellement de faire tourner ta boite, tu as un GitHub (ou GitLab) privé, et tes développeurs font des PR dessus comme 99% de la planète (qui n'utilise pas les fonctions avancées de Git), et surtout tu n'essayes pas de réinventer le passé sans rien comprendre avant (surtout sans comprendre pourquoi le passé genre SVN a été viré).
Bref : tu fais exactement l'inverse de ce que tu dis vouloir faire.
[^] # Re: git
Posté par Romeo . Évalué à 2.
Comme les autres : installe toi un gitlab sur un serveur local.
Pour quelqu'un qui veut que ça marche et qui dit ne pas connaitre git, tu pars directement dans les méthodes les plus complexes.
[^] # Re: git
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 26 novembre 2016 à 03:10.
Ce n’est pas obligatoire de tagger, un tag est juste un raccourci sur un commit (parce que c’est plus facile d’utiliser, par exemple, v2.1 que 6b0a7b9a2d489b438a0357587823b60e6c2f1387).
Par contre un tag pourrait effectivement être utilisé pour indiquer qu’une branche doit être mergée… soit en « avance rapide », s’il n’y a pas de conflit (ça peut donc se faire automatiquement en utilisant les "hooks" (des scripts qui se lancent automatiquement sur certaines actions sur un dépôt)).
S’il y a des conflits (selon l’algorithme utilisé, y’en a pas mal différents…), il faut que quelqu’un édite les marqueurs de conflit dans les fichiers afin que le merge aboutisse. Cette personne peut aussi dire : « ta branche je veux pas me faire chier à la merger, alors attends que je finisse de merger les autres branches de tes petits camarades qui codent pas comme des gorets, puis tu mergeras ensuite à partir de la nouvelle version pour régler tes conflits toi-même. » ;) Et abandonner le merge de cette branche.
Pour le nom des branches je dirais que les deux possibilités évidentes pour créer des branches c’est soit une branche par développeur, soit une branche par fonctionnalité. On peut bien sûr toujours aussi imaginer faire les deux… et d’autres.
Avec une branche par fonctionnalité, si deux dév travaillent sur une même fonctionnalité, si les deux push dessus depuis leur propre copie locale, c’est le premier qui est servi :)
Imagine le workflow suivant d’un développeur :
Début de journée, je mets à jour ma branche locale NouveauModule depuis le branche distante, disons qu’elle n’a pas changé depuis hier, je suis à jour. C’est bien, au boulot.
Je travaille sur cette branche, au bout d’un moment c’est prêt, j’ai fini ma tâche pour cette fonctionnalité, je nettoie éventuellement mon historique (rebase), parce que j’ai pu commiter localement par commodité pour X raisons, autant regrouper (fixup) les changements de ces commits, souvent peu utiles pour l’historique du projet… Et je push sur le dépôt de référence.
Et là paf, merde, entre temps un autre dév. a pushé son travail sur cette même branche. La branche distante étant maintenant « en avance de 1 commit par rapport à ma branche locale » je ne peux pas pousser comme ça (je pourrais forcer avec --force, si le serveur le permet, ce n’est pas recommandé, c’est pas gentil…), je dois donc d’abord merger moi même (en pullant) son travail, là pareil, si le collègue en question a travaillé sur d’autres fichiers, où à d’autres endroits dans le fichier et que l’algorithme de git est capable de le faire automatiquement il le fera, je pourrait ensuite pousser mon propre travail. Sinon suite au pull je me retrouve dans un état intermédiaire, avec les fichiers « marqués », là il faut éditer les fichiers pour les réconcilier, et le merge peut se terminer. Ensuite je pourrai pousser.
Une autre possibilité que le merge dans ce cas, c’est le rebase. Qui consiste (là encore j’espère qu’on me corrigera si je me trompe), à au lieu de créer un « commit de merge », à placer tous (ou une partie) de nos commits à partir duquel on dérive de la branche distante, en haut en cette branche. Donc il d’y a plus de « branchement », notre branche locale peut être pousser car elle représente la version distante (avec les travail de notre collègue) + seulement nos commits depuis, qui suivent quoi…
Je pense qu’on peut se contenter d’une seule des commandes, entre merge et rebase, pour un workflow défini… (hors le rebase qu’on peut faire soit même en local, pour modifier son historique avant de « publier » ses changements). Il y a des subtilités dont je ne pense pas avoir fait le tour et fonctionnellement elles me semblent équivalentes, elles n’aboutiront simplement pas au même historique. Mais le résultat, une fusion de branche, sera le même quant au contenu des fichiers à la fin de l’opération.
Et oui, du coup quand NouveauModule est de l’histoire ancienne, on supprime généralement la branche pour créer la branche NouveauModule2, que le nom des branches soit parlant. L’historique ne sera pas perdu, mais fusionné.
# pull --rebase
Posté par ord . Évalué à 6.
je suis pas sure d'avoir compris ce que tu veux, mais si tu n'est pas tout seul sur ton repos, tu devrait probablement (ou tu vas devoir) utiliser 'git pull --rebase' avant commit
Sinon comme beaucoup vont te le dire, tu ferais mieux d'utiliser un truc comme gitlab en interne et utiliser le workflow habituel avec 'pull request'. De toute facons tu vas y arriver bientot, on parie?
[^] # Re: pull --rebase
Posté par ghusson (site web personnel) . Évalué à 0.
Pourquoi j'aurais besoin d'un rebase si je réconcilie les branches de dev avec l'arbre maitre ?
Après, je sais que c'est limité comme manière d'utiliser git. Pour une petite équipe je pense que ça suffit.
Quand j'aurai besoin de plus, je passerai plus de jours à lire la doc :-)
[^] # Re: pull --rebase
Posté par ord . Évalué à 4.
si tu rebase pas tu avoir 50 commit "merge xxx" et vachement de problemes pour analyser les changements fait dans les merges
[^] # Re: pull --rebase
Posté par CrEv (site web personnel) . Évalué à 3.
Personne dans ta petite équipe ne connait git ?
[^] # Re: pull --rebase
Posté par paco81 . Évalué à 1.
Le rebase est l'équivalent le plus proche d'un commit dans le monde SVN. Tu mets tes nouveaux commit "par dessus" ceux qui sont déjà sur le dépôt central.
Dans le monde SVN, le merge de git n'a pas d'équivalent (un commit avec plusieurs parents).
[^] # Re: pull --rebase
Posté par paco81 . Évalué à 4.
après commit, et avant push ;)
Et selon moi, c'est encore mieux de ne pas utiliser git pull du tout, puisque 'git pull --rebase' est un raccourci de 'git fetch ; git rebase'. Et un raccourci qui n'aide pas du tout à comprendre ce qui se passe, puisque entre le fetch et le rebase, tu voudras certainement voir "ce qu'il y a de nouveau", par exemple avec 'gitk --all'.
[^] # Re: pull --rebase
Posté par ghusson (site web personnel) . Évalué à 2.
Merci pour les suggestions, je garde ça de côté pour le moment.
[^] # Re: pull --rebase
Posté par ord . Évalué à 2.
Correct ;-)
# ce n'est pas un problème d'outillage
Posté par Milo . Évalué à 5.
mais plutôt un problème d'organisation.
Je ne comprend pas moi non plus quel est le but réel de toute l'usine à gaz décrite dans le journal mais pourquoi ne pas utiliser un serveur de type gitlab ou équivalent ?
On obtiendrait surement alors les avantages de la centralisation sans les inconvénients … (et sans toute cette complexité)
[^] # Re: ce n'est pas un problème d'outillage
Posté par ghusson (site web personnel) . Évalué à 0.
Parce que j'aime bien avoir le code produit pas ma société sur un serveur que ma société maîtrise.
Pour l'instant je n'ai pas besoin d'interface graphique, je n'ai pas beaucoup de développeurs, je fais "dans mon coin".
Et cela me satisfait pour commencer.
Tout en sachant qu'un jour je mettrai certainement des projets sur gitlab, mais je passerai plus de temps à lire la doc avant d'y passer :-) Et pour l'instant le temps me manque… donc j'essaye d'optimiser.
[^] # Re: ce n'est pas un problème d'outillage
Posté par Milo . Évalué à 4.
Le serveur gitlab peut (doit?) être installé en interne. Un raspberry pi3 suffit pour une petite équipe (avec les dépots sur un serveur NFS quelconque, un NAS par exemple) …
L'interface graphique (web) est un plus mais il n'est pas indispensable de l'utiliser au quotidien. Les projets sur le serveur gitlab local sont juste vus comme des dépots "remote" standards.
[^] # Re: ce n'est pas un problème d'outillage
Posté par CrEv (site web personnel) . Évalué à 8. Dernière modification le 24 novembre 2016 à 11:38.
Dans ce cas pourquoi ne pas installer un gitlab ?
Avec autant de fiabilité (backup, qualité de service, etc) que des boites qui font ça toute la journée ? Surtout si tu n'as pas le temps.
[^] # Re: ce n'est pas un problème d'outillage
Posté par Marotte ⛧ . Évalué à 7.
Gitlab est un service mais c’est aussi un logiciel, libre, que tu peux installer sur un de tes serveurs ;)
https://gitlab.com/gitlab-org/gitlab-ce
[^] # Re: ce n'est pas un problème d'outillage
Posté par ghusson (site web personnel) . Évalué à 1.
J'ai vu gitlab, j'installerai ça certainement un jour. Pour rappel, j'ai passé une seule journée sur la question, et il faut que j'avance mes projets. Quand j'aurai de plus gros besoins ou une plus grosse équipe, je reverrai tout ça.
Pour l'instant je vais fonctionner en mode "quick and dirty" :)
[^] # Re: ce n'est pas un problème d'outillage
Posté par claudex . Évalué à 4.
Tu en aurais passé une demi en installant gitlab.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Rico Belo . Évalué à 1.
GitLab est une usine à gaz, une demi-journée me paraît vraiment optimiste pour un vrai déploiement (j'enttends par là autre chose que juste installer les paquets et juste démarrer le bazar avec sa conf par défaut)
En revanche, je suis surpris que personne n'ait fait mention de Gitolite, qui est pourtant très connu et utilisé sur de très gros projets, et qui est simplissime à installer et déployer, puisqu'il se configure lui-même avec Git !
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 25 novembre 2016 à 10:14.
Parce que pour moins que 10 000 personnes il y a besoin de plus ?
Pour les gros projets je demande à voir, et parce que ça n'apporte qu'un des aspects que couvre gitlab, comme le mécanisme de merge request, les review, le bugtracker, la CI…
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 2.
Qui à part ceux qui ont dit qu'il fallait utiliser git(hub|lab) a parlé de review, de CI ou de bugtracking par exemple ?
Je peux aussi te dire qu'il faut utiliser attlassian parce qu'ils font aussi le board kanban, le burndown, une gestion de fichiers, que ça fait les SLA sur les tickets,… Mais en quoi c'est utile pour le gars qui veut un gestionnaire de version ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Anonyme . Évalué à -2.
J’espère que c’est bientôt la retraite pour toi.
En tant qu’adminsys, je ne mets pas les pieds dans une boite qui ne fait pas de review ni de CI/CD.
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 3.
J'ai pas dis que c'était utile. Je dis juste que ce n'est pas une réponse adaptée.
Quand tu va voir ton garagiste pour faire changer d'amortisseur, il te change aussi la courroie parce que c'est quand même mieux ?
Il a peut être déjà tout ce qu'il faut pour le reste, hein ? Il existe des gens qui vivent hors de github/gitlab et qui font les choses au moins aussi bien que toi. Arrête de les prendre de haut.
Avoir un redmine, un jenkins et un reviewboard c'est très classique par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . Évalué à 1.
Personne ne dit le contraire. Mais généralement on se dit aussi que bon c'est à l'arrache et pas optimal, et qu'on pourrait mieux faire un jour.
On ne sous-entends pas que c'est la bonne méthode, juste celle faite méthode "larache" faute de temps (on sait qu'on payera en temps plus tard, mais bon c'est plus tard) et surtout on ne la conseille pas.
Quand même de moins en moins (surtout en pourcentage).
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 3.
Tu as des chiffres ? Peut être, hein ? Moi j'aime bien et là où je suis actuellement on a un github, mais tout ce que j'ai pu voir avant c'était du redmine à tout les étages et ça n'a rien de fais à la va vite.
Je préfère quasiment tout à la gestion de ticket de github par exemple.
Je suis pas fan du wiki de github, c'est cool de pouvoir le récupérer avec git, mais quand tu as joué avec xwiki tu fais forcément la gueule.
La CI je ne sais pas trop ce que ça a avoir puisque ni github ni gitlab n'en font à ce que je sache. Les gens utilisent travis ou codeship par exemple. Jenkins fait vraiment très bien le boulot surtout depuis la version 2.
La gestion des livrable ? Tu veux vraiment aborder la question de la gestion des livrables de github, parce qu'elle a un certain passif quand même ?
Github est bien (et gitlab aussi je présume), je dis pas le contraire, mais je vois pas en quoi d'autres solutions ne sont pas à minima aussi bien.
Et du coup je ne vois pas en quoi répondre à quelqu'un qui demande un truc d'utiliser forcément tout le packaging et de le considérer comme un débile s'il ne le fait pas est intelligent…
Pour conclure je citerais un grand mouleur⋅
« Passons… »
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par CrEv (site web personnel) . Évalué à 4.
https://about.gitlab.com/gitlab-ci/
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par El Titi . Évalué à 0.
Et sinon Mediainfo sur Github, c'est pour quand ?
"Gérard, Il a des idées sur tout, il a surtout des idées"
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 26 novembre 2016 à 07:57.
euh…
(et pour le pic sur les idées, c'est quand même bizarre je dis souvent que je sais que je ne fais pas tout parfaitement : désolé, je fais la différence entre ce que je fais et ce qui serait le mieux à faire, est-ce difficile à faire cette différence? Ici par exemple je pourrai très bien ne pas être passé à Git et le conseiller quand même car je sais que je ne suis pas sur le "bon chemin". J'ai l'impression qu'il y a une grosse difficulté à accepter qu'une personne puisse faire la différence entre ce qu'elle fait et ce qu'elle devrait faire, et l'impression que pas mal de monde doit défendre absolument sa façon de faire comme la meilleure car il fait comme ci comme ça sans se dire qu'il faudrait changer, l'impression n'est pas que dans ce journal).
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . Évalué à -1.
Un gestionnaire de version moderne doit gérer du CI (par gérer j'entends quelques tests avant d'accepter le PR), sinon il y a un problème de suivi de qualité / non régression (au moins dans la possibilité).
Perso, j'ai seulement quelques tests dans le CI, mais je sais que le problème est moi, et je ne dis pas "mais on parle pas de ça, on parle de gestionnaire de version", non, je sais que les bonnes pratiques ne sont pas chez moi et que c'est à moi de changer, pas à attaquer les gens qui en parle au bon endroit.
(et le mieux serait le bug tracker associé, qui cloture automatiquement la tâche notée dans le message de commit, pour être encore plus efficace, donc bugtracking dans ton gestionnaire de version ou du moins ton système global, si si).
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 6.
Ou l'inverse, tu peux très bien avoir ta CI qui gère ton gestionnaire de version. Jenkins fait ça très bien. Il se connecte à ton dépôt git et va lancer un build pour toutes tes branches et tu peux lui faire faire pour les pull request sans soucis.
Vraiment, il existe d'autres choses que gitlab, ne restez pas coincé dans des idées aussi coincées.
Je rappel, s'il le faut que pendant longtemps (je ne sais pas si c'est toujours le cas aujourd'hui), mais le créateur de git n'aimait pas du tout le fonctionnement de github (et celui de gitlab par extension).
Il y a des gens qui font autrement, écoutez un peu avant de juger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . Évalué à -1.
Tant que tu es conscient que tu as besoin des liens, OK pas de soucis.
Sauf que dans l'exemple du journal, ça ne semble pas du tout l'idée de la personne : je parie qu'elle n'a aucun CI.
hum… De ce que je connais de Jenkins (c'est très vague), il permet de lancer des tests après un merge/commit, et donc trop tard (on fait de la correction à postériori, mieux que rien mais pas le mieux, je l'imagine pour des tests trop longs pour le CI, c'est parfois chiant d'attendre 24 heures que le CI accepte un PR). Comment bloques-tu le PR dans le gestionnaire de version tant que les tests ne sont pas fait avec Jenkins?
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Renault (site web personnel) . Évalué à 3.
Pas du tout. Enfin, c'était peut être vraie à ton époque.
Dans ma boîte, on couple Gerrit (pour le code review) et Jenkins. Les commits sont en attentes dans Gerrit pour être validés par un humain, et automatiquement Jenkins vérifie de son côté que cela compile et les tests soient corrects.
Quand l'humain et Jenkins ont validé de leur côté, le commit peut être mergé.
Bref, on peut valider à priori avec Jenkins, au moins avec Gerrit. Comme Gerrit repose sur git, cela devrait être possible de faire avec git directement aussi.
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu rajoutes Gerrit, donc ça va, oui. Mais voila, on en revient que posé comme ça que avec Git, le workflow ne marche pas (efficacement).
Gerrit fait la glue dans ton cas, je vois mal "Git pur" (sans le configurer pour gérer le hook qui va bien) sans rien faire pouvoir bloquer un commit, car par défaut il ne bloque pas le commit justement (donc le système mis en place par l'auteur du journal a un petit soucis faute de CI, ce qu'on fait remarquer).
Quand l'auteur détaillera son workflow pour le CI, on en saura plus (ou pas).
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 2.
Ce fut difficile à sortir !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Sufflope (site web personnel) . Évalué à 3.
Bah si ta courroie est sur le point de péter j'espère qu'il te le dira, oui.
Vu les ravages de la "doc" lue par l'auteur, c'est ptêtre pas plus mal de l'aiguiller vers des bonnes pratiques.
Ça fait un peu acharnement mais bon je sais pas si ici on est dans ce cas-là, hein. Et puis s'ils font de la review et de la CI avec autre chose que leur forge, très bien. S'ils n'en font pas, à moins de s'appeler Notch, désolé, non, ils ne travaillent pas mieux que moi.
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . Évalué à 2.
Ce qui est je trouve pourri comme réaction, c'est que personne n'en sait rien, mais que ça n'empêche pas de présumer, puis de juger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Romeo . Évalué à 1.
Parcequ'il a passé une journée à développer un truc hyper complexe, avec des commandes bas niveau que les simples dev ne connaissent pas, plutôt que d'installer un truc plus simples avec des features qui sont plaisantes même dans les petites équipes.
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Romeo . Évalué à 2.
Ce qu'il a fait lui ne fait pas mieux qu'un gitlab de base…
Et un jour il voudra une UI -> gitlab, faire de l'intégration continue (c'est 10 minutes avec gitlab-ci), ou un chat (10 minutes avec mattermost)…
[^] # Re: ce n'est pas un problème d'outillage
Posté par Milo . Évalué à 1.
Un des points de départ possible (mais pas unique) pourrait être GIT-FLOW.
Je n'ai pas (encore) testé mais la démarche semble saine…
[^] # Re: ce n'est pas un problème d'outillage
Posté par Tangi Colin . Évalué à 3.
Gitlab-ce est limité par rapport à Gitlab-ee (entreprise edition).
Il y a une option manquante dans la version CE pour un vrai usage de développement au quotidiens et en équipe qui est la possibilité de choisir ça stratégie de merge lors d'un pull request. Dans la version communautaire seul le merge est permis (ce qui crée un historique non linéaire :/). La version payante (et donc non libre) rajoute toutes les possibilités (fast forward, rebase, squash and cherry-pick (ma méthode préfère sur gerrit, si j'ai besoin de plus de détails sur un "patchset" j'utilise le commit-id de gerrit)).
Pour une installe maison libre, je préfère un gerrit + jenkins. Le plugins gerrit de jenkins est plutôt bien fait et permet de mettre en place des intégration continue multi-git de manière assez simple (pour un coté haute disponibilités je mets jenkins avec du mesos/docker mais ça c'est une autre histoire).
Après j'avoue que le runneur de gitlab avec docker est un jeu d'enfant à mettre en place, par contre c'est du mono-git, faut tricher dans tous les sens pour faire de l'intégration continue sur des projets multi-git.
[^] # Re: ce n'est pas un problème d'outillage
Posté par Bactisme (site web personnel) . Évalué à 3.
Franchement, même remarque.
Je suis certain que beaucoup des dev n'utilise que marginalement la decentralisation.
Beaucoup de petits projets et de petites équipes ont un serveur qu'ils considère comme central (github, bitbucket, gitlab maison), et chaque dev pousse sur une branche à lui.
(Même, est-ce vraiment décentralisé, si tout les forks sont hébergés sur le même serveur ? :D)
[^] # Re: ce n'est pas un problème d'outillage
Posté par MrBidon . Évalué à 2.
Oui, c'est décentralisé car les développeurs disposent chacun de tout l'historique sur leur propre PC.
[^] # Re: ce n'est pas un problème d'outillage
Posté par windu.2b . Évalué à 7.
Pas que l'historique !
Un dépôt git sur sa machine n'est pas un ersatz de git ! On a toutes les fonctionnalités locales possibles : les commits, les branches (et donc les merges/rebases/cherry-picks/whatever), les logs, etc.
Rien de tout ceci n'est possible localement, avec SVN. Si t'as plus de réseau (parce que coupure, parce que serveur en vrac, parce que dans le train ou l'avion, …), tu te retrouves avec du code modifié qui "s'entasse" localement, sans pouvoir le commiter. Et quand tu retrouves le réseau, tu passes un moment à bien scinder les choses, pour faire des commits propres.
C'est ça, la vraie puissance de git (et des DCVS en général, bien sûr) : pouvoir (quasiment) tout faire, en local.
[^] # Re: ce n'est pas un problème d'outillage
Posté par barmic . Évalué à 1.
Il est toujours possible d'utiliser git (ou mercurial) comme client SVN.
Il est aussi possible de faire tout ça avec SVK.
Si, d'un point de vu organisation, on reste sur SVN autant avoir un serveur SVN. L'utilisation d'un git/hg en local permet de se mettre le pied à l'étrier au fil de l'eau sans obliger toute l'équipe à faire le switch.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce n'est pas un problème d'outillage
Posté par El Titi . Évalué à 3.
T'es sérieux là ?
svk est resté à l'état de quasi POC depuis sa naissance et est pratiquement mort depuis 2010
:
https://metacpan.org/release/CLKAO/SVK-v2.2.3
```
# Bookmak pour vraiment se mettre à GIT
Posté par ghusson (site web personnel) . Évalué à 2. Dernière modification le 24 novembre 2016 à 12:19.
Ce journal montre comment se mettre vite fait à git et peut être pas de la bonne manière.
Je propose aux connaisseurs de partager ici des URLs qui expliquent comment bien utiliser git.
Merci pour tout vos retours.
Commencer par lire la doc ici : https://git-scm.com/book/fr/v2
Pour un serveur auto-hébergé, voir ici : https://about.gitlab.com/products/
[^] # Re: Bookmak pour vraiment se mettre à GIT
Posté par think-free . Évalué à 2.
Une alternative de serveur auto-hébergé écrite en Go est https://gogs.io
[^] # Re: Bookmak pour vraiment se mettre à GIT
Posté par mfoucrier . Évalué à 1.
Merci pour le lien. J'ai installé la version précompilé pour arm sur un chip pour tester, et ça s'installe assez facilement.
[^] # Re: Bookmak pour vraiment se mettre à GIT
Posté par jerome (site web personnel) . Évalué à 7.
Pour se mettre "vite fait" à git, tu ferais clairement mieux de ne pas t'embarquer avec ton équipe dans un système tordu comme tu le proposes.
Il me semble plus important d'avoir un dépôt et une chaine de build/CI fiable dès le premier jour que de t'embarquer dans ce que tu montres ici.
NB : globalement, les gens qui utilisent github/gitlab le font d'une façon proche de l'UX svn, avec un dépôt central. En revanche, ils utilisent des systèmes de branches et des commits locaux.
[^] # Re: Bookmak pour vraiment se mettre à GIT
Posté par gUI (Mastodon) . Évalué à 7. Dernière modification le 25 novembre 2016 à 08:09.
On n'a pas la même notion de "vite fait". Ce que tu décris ici est une catastrophe, c'est pas du tout la bonne façon de faire. Moi qui utilise GIT au quotidien depuis 5 ans (sur un dépôt centralisé figure-toi) j'y comprends rien à tes commandes !!!
Le mot clé que tu cherches, c'est "bare". Il te faut créer un "bare" repo. Ce repo, on ne peut pas y travailler dedans. Il est juste là pour être LA référence (c'est le côté "centralisé" que tu recherches je pense).
Un lien : https://git-scm.com/book/fr/v2/Git-sur-le-serveur-Mise-en-place-du-serveur
Avec ta casquette de chef de projet, tu crées le repo, tu te choisis ta politique de branches (si il y en a), de tags (c'est à dire de version de ton soft) etc.
Quand tu prends ta casquette de développeur, tu vas cloner ce repo (c'est là où on dit que GIT est décentralisé, en tant que développeur tu vas récupérer l'intégralité de l'historique, c'est un vrai clone), y travailler dedans, tester, re-travailler, débugger, puis quand ta modif est belle, pusher vers ton repo "bare" tes modifs.
Le tout en utilisant 3 ou 4 commandes GIT de base : init, clone, push, merge (et encore, tu peux très bien vivre sans merge).
Quand on dit "GIT est décentralisé", c'est une technologie, pas un workflow.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Pourquoi ne pas utiliser SVN directement ?
Posté par beleys (site web personnel) . Évalué à 9.
Tout est dans le tire …
En fait, à la lecture de ton post, tu essaies de brusquer un outil décentralisé pour l'utiliser en mode centralisé … Pourquoi ne pas directement utiliser un outil qui et fait pour ?
Si ton équipe n'est pas prête à utiliser un outil comme git (par prête, j'entends formé), autant utiliser un outil correspondant à ton besoin. A vouloir utiliser un outil de la mauvaise manière, tu risque d'apporter beaucoup plus de problème que de solution.
Je viens de faire la transition SVN -> git pour mon équipe. On va dire que au bout de 6 mois de pratique , les outils d'aide à la validation (pull request) sont plus que nécessaire. Les boulettes sont très très rapides à faire …
# Mauvais tuto, changer de tuto
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Tu n'as pas lu la bonne doc … Le lien que tu donne commence par :
Ce que tu proposes, c'est un peu comme d'expliquer à un débutant comment coder en C en lisant les sources de GCC : ce sont les commandes de bas niveau, utiles pour les programmeurs qui veulent écrire des scripts à base de git, mais pas pour les utilisateurs.
Si tu veux un tuto « git centralisé pour débutants », il y en a certainement des tas sur le web. Tu peux regarder ceci que j'utilise pour des étudiants débutant en Git.
# Oh shit, git!
Posté par Anonyme . Évalué à 6.
Oh shit, git! :)
[^] # Re: Oh shit, git!
Posté par gUI (Mastodon) . Évalué à 3.
Oh il me plait ton bookmark, merci !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Et si on t'aidait pas à pas ?
Posté par Memiks (site web personnel) . Évalué à 3.
Je te conseille de passer la durée d'un épisode de série à faire les tutos de ce site :
http://learngitbranching.js.org/
il est vraiment bien, il te permet de simuler GIT ET de t'expliquer les concepts.
avec cela tu pourras oublier ton script je pense.
[^] # Re: Et si on t'aidaitpas àpas ?
Posté par Juke (site web personnel) . Évalué à 2.
Merci.
# conclusion inverse à la demande
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 25 novembre 2016 à 11:46.
1/ installer un truc chez toi n'est pas simple et efficace par rapport à utiliser un service déjà en ligne. Nous sommes en 2016, pas en 1976.
2/ Le mode de fonctionnement SVN ne correspond pas à ce que tu veux : simple oui, efficace non.
J'ai un peu souffert à comprendre comment utiliser les PR de GitHub, mais depuis, je hurle à chaque fois que je bosse sur le SVN pour un client toujours en SVN, car c'est pas du tout efficace d'avoir besoin de toujours être sur le même truc central.
Sérieusement, avoir SVN et "efficace" dans la même phrase, fallait oser. Même seul Git est largement mieux, ne parlons pas si tu es plus que 1 à travailler dessus.
Bref, la première chose que tu dois faire est soit revoir tes contraintes (efficace etc), soit réserver du temps pour ton plaisir, mais il faut choisir, la tu fais tout l'inverse de es contraintes en "fonctionnalités" et "temps".
OK. Mais alors arrête de dire que tu veux y passer 1 journée, prend le temps, sinon c'est juste une bêtise que tu regretteras le jour où ça crashera (et ça crashera).
Si tu as juste une journée, prend GitHub comme tout le monde qui veut pas y passer plus d'une journée.
# git != svn
Posté par calandoa . Évalué à -4.
Le gros problème que tu sembles avoir, c'est que tu t'imagines que git est beaucoup mieux que svn. C'est un problème que j'ai eu moi même il y a qq temps… jusqu'à que je m'y mette. Effectivement, en passant un peu de temps sur des forums, c'est l'impression générale qui se dégage de tous les commentaires.
En fait, pas du tout : Git est différent de svn et répond à une problématique différente. En simplifiant, le mode décentralisé de git convient très bien à l'open source, celui simple de svn est bien plus facile à mettre en œuvre dans une boîte.
Si beaucoup de gens encensent git, c'est juste que c'est des devs open-source qui galéraient sous svn qui ont vu plein de problèmes se résoudre grâce à git. J'ai pu de mon coté voir des problèmes inverses en comparant les boîtes où j'ai bossé qui utilisaient git et celles qui utilisaient svn.
Il semble évident que l'architecture de svn te convient… utilise donc svn !
Et par ailleurs (juste pour me défouler), en ce moment j'utilise perforce. Bon, n'utilisez jamais cet outil. JAMAIS.
[^] # Re: git != svn
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Je ne vois pas le rapport avec l'opensource, la décentralisation est une notion transversale à la licence des logiciels, et personnellement, étant en télétravail, je trouve par exemple juste indispensable de pouvoir créer à volonté des branches sans avoir besoin de faire des requêtes réseau.
Mettre en place du SVN aujourd'hui, c'est vraiment pour moi, une très très mauvaise décision, je ne vois quasiment plus aucun contexte où c'est utile, ça ne fera que frustrer les développeurs habitués à la souplesse des gestionnaires de sources décentralisés.
[^] # Re: git != svn
Posté par jyes . Évalué à 2.
Heureusement, quand le choix nous est imposé, il reste git-svn pour rendre les choses moins difficiles :-)
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 25 novembre 2016 à 12:28.
il répond à plus de problématiques, qui inclut les cas de SVN.
N'importe quoi, mais vraiment n'importe quoi. A commencer par opposer open source et boite (perso, je suis une boite qui fait de l'open source, alors me dire que je suis soit l'un soit l'autre…)
Certes je ne vais pas répondre la, mais c'est juste pour préciser au lecteur qui se perdrait la qu'il ferait mieux de se renseigner ailleurs (plein d'exemples sur le net) que ce commentaire.
Non. Car il n'y aucun cas aujourd'hui où SVN convient mieux que Git. Aucun. On répète : vraiment aucun. Au pire vous interdisez les PR si vous n'aimez pas les PR comme plein d'autres gens (qui utilisent Git quand même).
SVN meurt, laissez le mourir tranquillement (=avec ceux qui n'aiment pas le changement, ils partirons à la retraite petit à petit si on ne peut pas les déloger autrement).
Tu es assez masochistes pour aimer SVN, à partir de la tes conseils sont difficilement utiles (enfin, pour les non masochistes).
[^] # Re: git != svn
Posté par calandoa . Évalué à -1.
L'exemple que j'ai donné sur l'entreprise était une simplification, comme indiqué. Ton exemple ou celui de Guillaume sont bien sûr pertinents, mais dans un grand nombre de cas, les gens travaillent avec une base centralisée, fermée et accessible qu'à des employés "de confiance".
Prétendre par contre que git est supérieur en tout point est là particulièrement ridicule: svn est simple, git est complexe. Et c'est avantage extrêmement important dans une entreprise, où tu va forcer les gens à utiliser ton outil, et où ils n'auront pas forcement un très bon niveau. Même après des années d'utilisations, une opération comme un simple
svn updatepeut être extrêmement fastidieuse sous git. Git a plein de fonctionnalités que svn n'a pas, mais si tu n'en a pas besoin, ça ne sert à rien de se compliquer la vie.Et par dessus ça, même si l'architecture de git est bien pensée, son interface comme sa doc sont catastrophiques.
Et critiquer git ne m'empêche absolument pas de louer ses qualités. Pouvoir forker un projet sur github en un clic et maintenir son fork en parallèle de manière rigoureuse est effectivement impensable sous svn.
Malheureusement, je crois que tu es en train (comme d'hab en fait) de considérer ton nombril comme tout à fait représentatif de l'univers et que tu n'as jamais bossé dans une grosse structure centralisée.
Et je me permets de mettre ton « svn est mort, vive git » là ou je range les « le pc est mort, vive la tablette », « windows est mort, vive mac », « le disque dur est mort, vive le cloud », «l'email est mort, vive facebook », « le web est mort, vive les appli smartphone », etc…
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à -1.
< L'exemple que j'ai donné sur l'entreprise était une simplification, comme indiqué.
Tu n'as rien simplifier : tu as juste raconté n'importe quoi, et tenté d'opposer des choses complétements orthogonales, ce qui démontre que tu ne connais rien à la chose. ce n'est pas une insulte, juste un constat, et perso il y a aussi plein de choses que ne connais pas (à commencer par l'utilisation avancée de Git).
Euh… Ouais, bof, j'ai un GUI perso, ne connait rien aux commandes Git, et survit très bien, sans me prendre la tête.
Note : j'ai essayé un jour "svn update" dans l'avion sur le serveur à la maison, rien à faire impossible de commiter. Du coup, question efficacité, il a fallu attendre, noter les commits dans un coin, copier les fichiers à chaque étape pour avoir les bon messages avec les bons commits, très lourd. Mais bon, c'est efficace pour toi… note que je parle d'une grosse boite utilisant SVN et pas d'open source, ton "exemple".
Merci du compliment.
Dans l'attaque, tu es ridicule, tellement GitHub (et sa façon de faire pour les projet) est connu.
Je crois que tu es en train de faire l'autruche et attaquer une personne qui te parle d'un truc que tu n'as simplement pas envie de voir.
Tu sais, on peut aussi avoir vu et s'être rendu compte de la résistance au changement qui est le seul frein pour ne pas être plus efficace dans une grosse structure. Mais de plus, git accepte un serveur central, donc bon on voit bien que le problème n'est pas Git, mais les préjugés dessus (avec Git, on peut faire centralisé et décentralisé, mais les gens pensent que c'est mieux d'opposer).
Note que tu n'as pas donné d'exemple où SVN est mieux que Git (à part un pseudo exemple de "complexité" de Git qui se résout en des scripts de 2-3 lignes à fournir, et encore), et c'est un newbee de Git qui le dit.
Non, vraiment, ça n'a rien à voir : SVN est vraiment mort (en train de mourir), les seuls encore à l'utiliser son les masochistes et les gens ayant un historique, que ça te plaise ou pas.
Note que je n'ai jamais dit tous les exemples que tu as cité (bizarre non? tu m'y catalogues sans me connaitre).
Passons…
[^] # Re: git != svn
Posté par barmic . Évalué à 0.
BIM ! Comme c'est envoyé ! Tu dois être content après une réflexion comme ça ! Aller taper sur les gens avant le week-end ça doit être cool !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à -2.
Désolé, mais je prend très mal (enfin, version café du coin) quand on me considère comme inexistant juste parce que je suis une entreprise qui fait du libre.
"le mode décentralisé de git convient très bien à l'open source, celui simple de svn est bien plus facile à mettre en œuvre dans une boîte" ne te dérange pas, OK, mais désolé c'est sur ça que tu devrais réagir, car c'est justement ces gros préjugés transmis sous couvert de simplification qui font du mal au libre.
Les (grosses) entreprises n'ont pas attendu Git pour faire du décentralisé (non libre aussi), Bitkeeper par exemple était utilisé par des grosses boites proprio de chez proprio.
Il y a plein de libre centralisé (je dirai même la majorité des projets sur GitHub sont en centralisé dans l'idée, SVN pourrait convenir et ça changerai pas grand chose).
Ne pas le savoir, se mélanger les pinceaux la dessus et trouver une excuse "c'est pour simplifier" quand on le fait remarquer que ça n'a rien à voir, mais parler de quand utiliser SVN ou Git, désolé mais c'est bizarre.
Note que j'ai réagi de cette manière quand on s'est foutu de moi dans la réponse à ma réponse pour noyer le poisson (même pas un "excuse-moi" sincère, non juste une "simplification"), et non au premier commentaire.
Faut parfois regarder comment d'autres attaquent (ce n'est pas parce que la forme est plus jolie que le fond n'est pas violent).
[^] # Re: git != svn
Posté par barmic . Évalué à -1.
Pauvre chou… Tu te rend compte que tu en fait des beaucoup plus violente que ça à longueur de commentaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à -2.
Je suis conscient que la violence dans le fond se voit moins que la violence dans la forme, rien de nouveau et c'est la vie de pas mal de monde (pour prendre un exemple classique et troller, le grand classique "je ne suis pas homophobe, je veux débattre avec toi, mais bon hein hors de question de t'autoriser à avoir les même droit que les hétéros", il y a du monde qui joue pas mal sur calmer la forme pour faire passer de la violence sur le fond).
Et je suis conscient aussi que je ne changerai pas le monde sur le sujet, les idées les plus violentes passeront toujours quand la forme y est, donc "passons" (oui je le répète, mais en fait ça m'amuse de voir les fonds violents défendus juste parce que la forme y est).
[^] # Re: git != svn
Posté par barmic . Évalué à 2.
Non quand tu pose pamphlet à l'encontre des « libristes/communauté du libre/je ne sais quel autre groupe pas très précis ». C'est le même genre de violence que ce que tu viens de subir (tu veux une cellule psychologique ?). C'est du même acabit sauf que tes propos sont souvent plus violent et que pour toi on sait très bien que tu sais ce que tu fais, tu sais où tu va. C'est tout à fait volontaire (il y a récidive alors que ça t'a était dis déjà plusieurs fois).
Il est vraiment tard pour te la jouer victime larmoyante je trouve.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par calandoa . Évalué à 4.
J'allais répondre bille en tête au message plus haut, mais je n'avais pas saisi le problème de mon exemple avec l'entreprise. Effectivement en me relisant, j'ai un ton méprisant qui fait un peu grosse-boîte-sérieuse-costard-cravate contre petite-boîte-de-merde-qui-fait-du-libre. Ça n'était pas mon intention (c'en est même à l'opposé) et j'en suis vraiment désolé.
Maintenant je vais te parler un peu de mes états d'âmes à moi : j'ai utilisé des années svn et dans le même temps je lisais plein de trucs très élogieux sur git et je brulais d'y passer. Il y a une (grosse) boîte où j'avais bossé il y a qq année où il y avait une infrastructure CVS monstrueuse et où on a décidé de passer… à SVN ! sur le moment j'étais assez surpris qu'on utilise pas un truc moderne comme git.
Bon, ben dans la boîte suivante, j'ai pu bosser avec git. Et là j'en ai bien chié. Non seulement je galérais moi même, mais tout le monde galérait autant et même les pro-git prenaient des décisions débiles parce qu'ils étaient eux même à la ramasse, compliquant encore plus mes problèmes. Alors que l'organisation était bien plus simple que dans la boîte précédente, mes problèmes de VCS me prenaient un temps monstrueux (et encore un peu maintenant). Et le pire dans tout ça ? c'est qu'en allant chercher de l'aide sur le net, je tombais sans arrêt sur des trolls abrutis radotant « git c'est mieux, git c'est plus facile que svn » exactement comme toi plus haut avant que j'intervienne.
Heureusement, je me suis un peu calmé depuis, surtout que même si les fanboys git sont ceux qui hurlent le plus fort, il y a quand même pas mal de témoignages assez pertinents (je pense par exemple à ceci, avec bien sur son petit lot de commentaires git-c'est-mieux-pour-moi-donc-je-décide-que-c'est-mieux-pour-tout-le-monde).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 25 novembre 2016 à 15:27.
Apprécié.
Mais juste je reprécise : ça n'a vraiment rien à voir. Tu penses à des grosses boites qui centralisent tout, mais il existe des grosses boites qui ont utilisé BitKeeper bien décentralisé bien avant que Git existe. ce n'est pas une question de taille, mais de "design". Tout comme ce n'est pas une question d'open source. ce n'est pas la partie méprisante qui est la plus gênante, mais ne pas voir que c'est orthogonal. Il ne faut surtout pas mélanger sous couvert de simplifier (simplifier ne doit pas tromper), et surtout voir qu'on a merdé dans la simplification (et non ce n'est pas une attaque, tout le monde merde un jour, moi compris et pas qu'un peu), c'est ma plus forte réaction.
Donc maintenant que ce point est clos, repartons sur le sujet :
Je comprend, en ayant chié aussi.
Mais aussi pour une raison que tu as aussi : je connaissais SVN.
Et tu as oublié comme SVN est difficile à apprendre car c'est loin, mais un débutant n'a pas vraiment plus de problème avec Git qu'avec SVN, surtout quand on utilise Git comme SVN. J'ai l'impression que tu confonds "Git fait par des fans qui veulent utiliser Git à fond" et "Git qu'on peut utiliser comme SVN" : si tu veux te la jouer "SVN", tu as Git et tu fais des pull, commit, push le tout sur une seule branche d'un seul repo et c'est réglé (contre des update, commit, soit juste une commande de moins…)
Mais apprendre SVN juste parce qu'on a la flemme d'une commande en plus (qui permet de travailler offline, à l'heure de la mobilité d'entreprise…), ce n'est pas la bonne chose à faire pour qui ne connait ni SVN ni Git.
Il y a des intégristes fanboys partout, je n'ai jamais dit que Git était génial, j'ai juste dit qu'il n'y a plus aucun cas où SVN est conseillable. Si tu n'es pas d'accord, je demande un cas d'usage.
J'en ai donné un, le truc le plus basique, et c'est une commande en plus (pour toute personne non geek : un clic en plus) contre un confort en plus (commiter offline, c'est important en 2016), c'est à prendre pour tout le monde ou presque (les gens codant qu'au bureau avec le serveur Git / réseau online avec QoS 99.999%?), du moins j'attends un exemple où Git est plus compliqué à apprendre utiliser pour le même besoin de 2016 (je précise la date pour les moeurs qui contiennent la mobilité).
[^] # Re: git != svn
Posté par groumly . Évalué à 2.
Des noms? Ca fait deux fois que tu balances ça, je suis curieux de savoir si tu connais vraiment le sujet ou si t'affabules juste pour aller dans ton sens.
Note: la liste des clients actuels n'est pas suffisante, hein. Linux est pas une boite, donc ca compte pas, non plus.
Bullshit.
Non seulement Git est fondamentalement plus compliqué, mais il a aussi une interface a chier par terre, et t'exposes direct à toute la complexité de git. Et la communauté aide pas, en insistant pour que tout le monde commence direct avec les concepts compliques (genre rebase plutôt que merge).
Et la grande majorité des clients graphiques sont incroyablement compliques à utiliser, tant occupe qu'ils sont à exposer chaque petite feature dans un bouton dans la barre d'outils. Le seul qui je connaisse qui soit utile et simple à utiliser, c'est gitbox, qui n'est plus maintenu depuis 2012.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: git != svn
Posté par El Titi . Évalué à 0.
Merci !
Enfin du vécu.
J'ai aidé un projet à démarrer avec il y a peu au niveau testing et ces messieurs se la jouaient, git pas besoin de training on maîtrise à donf.
Genre, on va se faire du "trunk dev" finger in the noseet des feature branch quand on veut. On n'est pas des rigolos.
2 semaines plus tard il étaient au abois, merge intempestifs , chacun écrasant les commits de l'autre, … Mais Heu, avec svn c'est facile.
Ben ouais, les ptits gars, faut comprendre un peu le rebase pour bosser proprement, et la staging c'est pas fait pour les chiens …
[^] # Re: git != svn
Posté par jyes . Évalué à 3.
SVN peut pourtant s’utiliser assez aisément hors ligne avec les bons outils :-)
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 25 novembre 2016 à 13:59.
Plutôt d’accord avec toi sur le fait qu’un outil simple à utiliser a plus de chance d’être adopté (et correctement utilisé). Par contre :
Que leur reproches-tu au juste ?
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à 1.
Moi aussi.
Mais j'avoue ne pas voir le lien avec SVN (SVN n'étant pas simple à part pour les gens le connaissant, avec plein de "workarounds" à faire pour faire des choses assez basiques)
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Je n’ai jamais travaillé avec SVN (mon utilisation à l’époque se limitait à faire des
svn uppour récupérer le source de certains logiciels)Je pensais benoîtement que SVN ayant moins de fonctionnalité (mais là encore je dis peut-être une connerie) il était plus rapide à prendre en main.
Pour en revenir à l’aspect centralisé/décentralisé j’avoue ne pas bien comprendre de quoi on parle.
Il me semble que pour travailler avec Git il est nécessaire d’avoir un dépôt de référence (un bare…) car il n’est pas possible de pousser vers un dépôt de travail (même si on peut cloner un dépôt de travail) et il n’est pas possible non plus de travailler dans un dépôt de référence…
Donc pour moi Git c’est forcément centralisé. C’est tout aussi décentralisé car il est possible de commiter (ou créer une branche en local) et travailler dessus sans avoir à joindre le dépôt de référence, ce qui, si j’ai bien compris, n’était pas possible avec SVN.
Bon, comme vous pouvez le voir je débute avec Git, mais j’avoue que pour le peu que j’en connais (push/pull/merge/rebase/stash… le gestion des "remotes") je trouve déjà que c’est un outil vraiment puissant, utile.
Il me reste pas mal de truc à voir : cherry-picking (bon ça ça à l’air simple) bisect/3-way merge… et sûrement d’autres fonctionnalités… J’ai l’impression que les possibilités sont quasi infinies avec le système de hooks…
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à 1.
Pour le même usage, ce n'est pas parce qu'un outil permet plus qu'il est plus compliqué qu'un outil plus simple.
C'est un préjugé classique que d'imaginer que puissant veut dire complexe dans tous les cas (préjugé aussi pour les développeurs qui pour un usage simple vont dire "oui c'est plus compliqué que le concurrent mais c'est parce qu'on propose plus de choses", mauvais développeur qui légitime son incompétence en design par une fausse excuse).
Bref : Oui est (très) compliqué pour des choses assez compliquées que SVN ne permet pas. Mais pour des choses "à la SVN" c'est kif kif pour qui n'a jamais touché à un gestionnaire de version (il ne trouvera pas que commiter en local puis pusher est plus compliqué, il trouvera pas mal de pouvoir commiter dans l'avion et pusher en y sortant, et pétera un câble quand on le forcera à utiliser SVN et que sa connexion Internet a sauté et que donc il peut même pas faire 2-3 commit en attendant, bref les gens hurlent aux manques en se basant sur ce qu'ils ont utilisé en premier).
Euh…
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 25 novembre 2016 à 22:55.
Je vais être plus précis.
Dans le cadre du développement logiciel, Git va de consort avec les différentes sur-couches, tu ventes toi-même un service comme Github, sa facilité d’accès, sa valeur ajoutée… Ces sur-couches, ainsi que tout le reste de la forge logicielle, n’est pas aussi décentralisé que Git lui-même. Tu ne la migres pas d’un clone magique comme tu peux le faire avec les fichiers suivis eux-mêmes. Ces fichiers sont effectivement partout localement, en principe, selon leur popularité plus précisément, exactement comme un torrent…
Si on sort du cadre du développement logiciel (avec bugtracker et CI, au minimum…) et qu’on considère juste Git pour ce qu’il est, c’est absolument décentralisé je te l’accorde.
Je pense à l’utiliser pour mon $HOMEDIR. C’est un moyen qui me semble plutôt efficace pour installer rapidement mon environnement sur une nouvelle machine, ainsi qu’avoir un historique et pouvoir revenir en arrière en cas d’erreur. Je pense que pour cet usage, je ne devrais pas forcément utiliser un dépôt bare sur une seule machine, mais simplement lier les $HOMEDIR les uns aux autres,
au grès de mes envies, selon l’environnement où je travaille à un instant T (et surtout celui sur lequel j’étais à T-1…)Même là, le fait d’avoir un dépôt qui centralise, sur un NAS par exemple c’est intéressant. Pour le répertoire /etc c’est pratique aussi. Je ne serais pas surpris de voir dans l’avenir des distributions intégrer plus git, pourquoi pas pour la gestion des packages et de la configuration.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Et avant que tu ne m’en fasses la réflexion,
Oui j’ai bien écrit des conneries ici je pense ;)
[^] # Re: git != svn
Posté par BAKfr . Évalué à 1.
Il est possible très facilement de pousser vers un dépôt de travail. Si le dépôt distant a un accès SSH, il n'y a rien à configurer. Ça peut être très utile, par exemple pour tester rapidement des commits sur une VM de test.
Il n’est pas possible de travailler dans un dépôt "bare", mais rien n'empêche de prendre un dépôt normal comme référence. Accessoirement, on peut convertir un dépôt bare en dépôt normal, et vice-versa, en 4-5 lignes de commande.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 25 novembre 2016 à 23:17.
Juste pour voir si j’ai bien compris. Dans ce cas on ne pousse pas vraiment, on se connecte en SSH à distance et on « tire » (en clonant) depuis là-bas :)
[^] # Re: git != svn
Posté par BAKfr . Évalué à 0.
Non, c'est bien git s'en charge tout seul:
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 3.
C’est il me semble le comportement par défaut de ne pas le permettre.
[^] # Re: git != svn
Posté par BAKfr . Évalué à 1.
Curieusement, je n'étais jamais tombé sur ce cas.
Apparemment, on ne peut pas agir sur la branche pointée par "HEAD", pour ne pas laisser le dépôt distant perdu sans savoir sur quel branche il est.
Par contre, ça ne pose pas de problème de pousser une autre branche.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Effectivement. Merci.
Ensuite il n’y a plus qu’à :
oui car si j’ai bien compris c’est la branche pointée qui sert si quelqu’un d’autre veut cloner ce dépôt. Ça ne peut être deux états, deux commits (ou dans l’exemple, un commit et un dépôt vide)…
Tu m’auras appris un truc, merci.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
En espérant pas dire de connerie… Si on l’autorise (donc il faut déjà configurer cela après l’init du premier dépôt) ça rend le dépôt de travail distant « inconsistant » ça veut sûrement dire qu’on ne peut plus vraiment s’en servir comme dépôt de travail avant de « s’aligner » (avec le reset) et donc perdre potentiellement des choses qui aurait été faites de ce côté… Peut-on stasher dans ce cas ? Le dépôt dans cet état, s’il est cloné, quel est le résultat ?
[^] # Re: git != svn
Posté par BAKfr . Évalué à 1. Dernière modification le 26 novembre 2016 à 00:55.
Je viens de faire le test.
En résumé, ça modifie la référence du dossier de travail (HEAD), mais ça ne modifie pas les fichiers physiques.
Il faut savoir que
HEADpeut pointer vers un commit précis (git statusnous indique qu'on est dans l'état "HEAD détachée"), ou pointer vers une branche, qui elle-même pointe vers un commit (le fonctionnement normal).Une opération push va modifier la branche, et si HEAD suit la branche, HEAD sera indirectement impactée. Mais les fichiers locaux ne vont pas changer.
En pratique, si coté client on ajoute un fichier F dans un commit C, du coté serveur,
git statusva nous dire qu'on est bien sur le commit C, mais que le fichier F a été supprimé.Avant le push (sur le serveur):
Après le push:
Le risque, c'est que si on a des fichiers modifiés et que quelqu'un push sur notre dépôt, ça va tout mélanger et il va falloir faire du tri à la main, donc potentiellement grosse galère pour s'y retrouver.
Pour les autres opérations de pull et clone, ça ne devrait pas avoir d'impact.
[^] # Re: git != svn
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
J'ai pas tout lu, mais je crois que ce que vous cherchez est :
git config receive.denyCurrentBranch updateInstead. Cf. par exemple https://github.com/blog/1957-git-2-3-has-been-released pour des détails.[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Merci pour le lien. Cela dit je vais devoir aussi travailler avec du Git 1.7… mais c’est bien de voir que ça continue d’évoluer.
[^] # Re: git != svn
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Je n'ai pas grand chose à dire de la doc, mais c'est assez notoire quand même que l'interface de Git (je parle des commandes et des options) pourrait être largement améliorée, en utilisant un vocabulaire plus expressif.
http://www.saintsjd.com/2012/01/a-better-ui-for-git/
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est aussi quand même se bloquer sur la commande "git".
Perso, je ne l'ai jamais utilisée (j'utilise un IDE qui intégre Git, ou une extension au gestionnaire de fichier)
(bon, par contre oui on met du temps à comprendre push / pull / merge / etc, la je te suis et c'est ce qui m'a fait reculer et passé très tardivement de SVN à Git, perso je n'ai pas encore tout compris mais assez pour faire mon taf)
Bref : on n'a pas besoin de connaitre la commande "git" pour utiliser Git.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
J’en arrive à la même conclusion, je pense forcément en apprendre un peu plus mais je ressens aucun obligation de devoir tout assimiler pour collaborer sur du code.
[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Merci pour ton lien. J’étais passé à côté de ta réponse.
_o_. Moi j’ai carrément pris ça comme une réelle volonté d’indiquer à l’utilisateur l’importance que la pertinence de ces informations revêtent pour la collaboration sur un projet :)L’aide qui s’affiche par défaut je trouve ça assez bien. On dit toujours qu’il faut RTFM au débutant. Donc rappeler la base aux moments cruciaux est loin de me sembler délirant.
Bref, je pense que l’auteur initial de Git se souciait effectivement peu de cet aspect, si c’était logique pour lui.
D’automatiser le stash suivit d’un reset ça n’aide pas à comprendre ce qu’est ce stash.
Quand Linus a créé Git il devait faire pas mal de gestion de patch, plus que du développement à proprement parler. Git est fait pour faire de la gestion de patch (code source mais on pense aussi à la documentation…), et seulement cela, assez dans l’esprit Unix.
Bref, je pense que l’auteur initial de Git se souciait effectivement peu de l’accessibilité de son programme, son ergonomie, tant que c’était logique pour lui et son propre workflow.
Je reconnais que Git est pas non plus le logiciel que j’ai trouvé le plus facile à assimiler. Les pieuvres ça fait un peu peur
^^[^] # Re: git != svn
Posté par calandoa . Évalué à 2.
Je leur reproche la même chose que l'équipe GitHub dans cet exemple très parlant : leur doc de
git reset, commence par « git reset is probably the most confusing command written by humans ».[^] # Re: git != svn
Posté par Marotte ⛧ . Évalué à 2.
Merci pour ce lien avec ces explications très claires et ces exemples. J’ai moi même commencé à rédiger ce genre de document afin de mieux mémoriser ce que j’apprends sur Git.
Mais bon, à part dire que « c’est probablement la commande la plus confusante(?) jamais écrite par des humains » nulle part est pointé ce qui peut porter à confusion…
Une fois qu’on a saisi la différence entre l’étape add et l’étape commit, l’action reset c’est clair comme du cristal de roche ;)
[^] # Re: git != svn
Posté par El Titi . Évalué à 4. Dernière modification le 26 novembre 2016 à 02:02.
Oui, sachant qu'elle permet de faire des squashs des derniers commits, que pour un fichier son rôle est different, qu'elle permet d'unstager, que les options softs, mixed et hard laissent intact tes fichiers … ou pas.
Pour beaucoup, ca ressemble plutôt clair comme du pétrole brut.
Un indispensable: https://git-scm.com/book/tr/v2/Git-Tools-Reset-Demystified
[^] # Re: git != svn
Posté par El Titi . Évalué à 3.
Tu pourrais préciser un peu ?
A ma connaissance, Perforce est plutôt ce que SVN aurait dû être, avec entre autre :
* un cache digne de ce nom (à défaut d'un outil distribué)
* la possibilité de configurer un merge entre 2 branches en mappant explicitement les répertoires/fichiers qui ont bougé, ce que ni SVN n'a jamais réussi à faire (cf. le cauchemar des mergeinfo http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html) ni git qui se base sur des heuristiques sur le contenu et qui part dans les choux dans des cas complexes.
* permet d'intégrer la gestion des demandes de changement autrement qu'en rajoutant tes tickets en commentaire et permet même de gérer leur workflows.
Accessoirement, une petite boîte gère tout son code sous Perforce en mode trunk dev siouplé (ca c'est pour les afficionados des PR ala Githhub/Bitbucket/Gitlab):
http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
[^] # Re: git != svn
Posté par ckyl . Évalué à 3.
Google n'utilise plus perforce depuis un moment. Ils ont tout réécrit maison sous le nom de code Piper dont peu de détails ont fuités en dehors de quelques Google Tech Talks et de la présentation @Scale 2015 sur leur approche qui est l'orgine de l'article que tu cites.
Dans l'idée, le processus de Google est assez proche des PR. Lorsqu'un patch est soumis pour code review, le pre-commit s'occupe de faire passer tout l'outillage sur trunk + ton patch (CI, TU, analyse statique etc.), puis review par le maintainer du module, puis intégration du patch.
Si l'outillage est maison, la dynamique est très semblable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.