Bonjour,
Je ne suis pas programmeur, mais je crée parfois quelques programmes ou projets que je souhaiterai partager. J'ai pensé me mettre à Git, mais ça a l'air compliqué pour mon utilisation. Le seul intérêt de Git serait de pouvoir poster mon code sur des forges populaires, et de ne pas laisser traîner un fichier zip dans un coin de mon blog, qui ne sera trouvé par personne.
Le genre de choses à partager:
- petits projets Arduino
- utilitaires python, scripts bash
- designs openscad, voire blend ou stl…
Que me conseillez-vous pour partager mes projets? Dois-je me mettre à Git? Avez-vous d'autres solutions?
# gitlab public
Posté par François GUÉRIN (Mastodon) . Évalué à 4.
Bonjour,
Une bonne forge publique : gitlab.com ou encore mieux https://framagit.org/public/projects qui te permet de partager tes projets, avec plein de fonctionnalités en plus:
Git n'est pas très compliqué à utiliser, même pour un débutant…
Bon courage !
# Que me conseillez-vous ?
Posté par Obsidian . Évalué à 9. Dernière modification le 23 mai 2017 à 18:21.
Salut,
Tu as l'air d'avoir bien résumé la situation toi-même et d'avoir une vision assez précise de la chose. Il serait dommage de ne pas en profiter pour franchir le pas et approfondir le tout, en effet…
Je dirais plutôt que, vu la situation, c'est « une bonne occasion de se mettre à Git ».
Plus précisément, Git est aujourd'hui aussi populaire que répandu, mais il rebute parfois un peu les néophytes comme les habitués d'autres SCM. Une fois qu'on a compris le principe général, le tout devient somme toutes assez simple mais le mieux reste quand même de se le faire expliquer par quelqu'un qui connaît bien l'outil lorsque l'on fait ses premiers pas. Après, on peut pratiquement tout utiliser sans difficulté notoire.
Sache aussi qu'il est très intéressant d'utiliser un logiciel de versioning même lorsque l'on travaille seul (et pas simplement pour le code). Ça permet de conserver automatiquement la trace des différentes versions de ce que l'on écrit sans se soucier de les classer explicitement, ça permet de revenir facilement en arrière, ça permet de forker quand on veut démarrer un nouveau projet similaire à un autre et, in fine, ça permet de partager automatiquement son travail une fois que l'on a atteint un stade intéressant pour son entourage.
C'est aussi très intéressant pour conserver un code toujours propre : en général, il est facile d'ajouter des lignes de code à un fichier existant mais il est plus difficile de prendre la décision de supprimer des blocs lorsqu'ils ont demandé du travail pour être mis au point. En général, ils finissent en commentaires jusqu'à ce qu'ils soient suffisamment vieux pour être effacés… à condition qu'on ait pensé à écrire la date dans le commentaire en question. S'appuyer sur un SCM quand on développe permet d'effacer immédiatement ce qui ne sert à rien car non seulement rien n'est définitivement perdu, mais parce qu'il est très facile de les retrouver et même les mettre en évidence à l'aide d'un diff entre deux révisions.
Et si malgré ça rien ne te séduit, tu peux quand même faire un « git init » dans ton répertoire de travail, ajouter tout ton travail dans un seul gros commit initial sans rien d'autre, et t'en servir pour le partager sur une forge officielle.
# git
Posté par ted (site web personnel) . Évalué à 3.
Bon, je vais essayer git alors. Je vais essayer de trouver une bonne explication.
Merci pour vos retours.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: git
Posté par j_m . Évalué à 3.
Le wrokflow de base sera assez simple tant que tu es tout seul. Si tu publie sur github, ou un autre serveur, par exemple tu utilisera principalement deux commandes:
Pour enregistrer une petite modification du code source dans git:
$ git commit -a -m "Explication de mes modifications"
Pour envoyer le commit sur le serveur:
$ git push
Si tu utilises un serveur comme github, la difficulté c'est de démarrer parce que il faut gérer l'authentification. Choisi le site où tu veux déposer ton code source et suis scrupuleusement les explication, ça devrait aller.
[^] # Re: git
Posté par Obsidian . Évalué à 2.
N'hésite pas à poser tes questions ici dans programmation.autre, par exemple. Histoire de mettre facilement le pied à l'étrier (par exemple : voir d'emblée ce qu'est l'index/staging area).
Autre technique intéressante : rapatrier avec Git un projet d'envergure déjà existant (le noyau Linux en étant bien sûr l'archétype, mais on peut faire moins gros), non pas pour y travailler, mais pour se faire la main en conditions réelles. C'est plus facile de voir à quoi servent les branches, les reflogs et toutes les fonctionnalités qui ont émaillé l'outil au fil du temps en explorant un dépôt bien fourni qu'en faisant des cas d'école sur un répertoire qui ne contient qu'une demi-douzaine de commits.
Enfin, n'hésite pas à choisir un client pour Git. Personnellement, j'utilise « tig » mais il en existe pléthore. C'est plus facile de se balader dans un dépôt avec ce genre d'outil qu'en utilisant simplement git log --graph
Bon courage.
# github
Posté par ted (site web personnel) . Évalué à 2.
J'ai finalement créé un compte github:
https://github.com/kimented/elka1
Je me contente pour l'instant de faire des add/commit/push, qui sont suffisants pour mon utilisation actuelle.
Merci pour vos conseils
Un LUG en Lorraine : https://enunclic-cappel.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.