Bonsoir,

J'ai mis longtemps avant de m'y mettre car ça m'intéressais vraiment pas mais j'ai fini par apprendre Git car j'ai vu que c'était un outil qui pouvait être très utile surtout lors de création de projet d'ampleur/ travailler en équipe et que c'était en général quelque chose de requis en terme de connaissances qu'on soit en cdi ou indé.
Cependant le problème est que c'est pour le coup pas quelque chose qui me passionne tant que ça donc j'ai pas mal survolé les tutos pour voir comment ça fonctionne.
J'ai finalement vu que Git était utilisable sans avoir potentiellement à utiliser de lignes de commandes avec vscode, donc plus simple et sans forcément avoir à apprendre grand chose (si ce n'est de comprendre ce que l'on fait avec l'outil).
J'ai commencé à utiliser un repository sur github avec un projet et j'utilise donc git avec vscode pour cela.
Mais du coup je me demandais, est-ce que cela suffit en terme d'utilisation de Git ?
C'est à dire modification de fichiers + ajout + commit puis quand c'est terminé envoyer en ligne sur github ?

Merci

Git en ligne de commande c'est pas sorcier.

Git add . pour ajouter les fichiers modifiés en fil d'attente
Git commit -m pour sauvegarder ces modifications
Git checkout -b pour créer une nouvelle branche
Git merge pour fusionner 2 branches
Git push pour envoyer ses commits à distance sur Github avec ensuite le demande d'une pull request puisque chaque développeur travaille normalement sur sa branche.
Git pull pour récupérer les modifications distantes

Le flow de travail Git c'est à 90% du temps 6 commandes différentes.

Et une organisation avec une branche main, une branche dev, une branche propre à chaque développeur et/ou fonctionnalité est bien suffisant.

On aime bien compliqué les choses mais Git c'est 6 commandes et 3 groupes de branches en gros (main, dev, fonctionnalité)

Le reste c'est de la complexification qui a plus ou moins d'intérêt, voir aucun intérêt parce qu'avec ce flow de travail simple on peut déjà faire beaucoup de chose sans s'y perdre.

Donc pas de quoi avoir peur du terminal

la seule chose d'un peu complique avec git est la resolution de conflit. Regarde ca un peu en detail. et le reste est relativement trivial.

c'est pas une mauvaise idée de savoir utiliser les commandes pour les opérations de base

après si t'es pas malchanceux tu arrives sur un projet avec des gens bienveillants qui t'apprendront les trucs un peu plus compliqués

Les interfaces c'est bien seulement si tu maîtrise déjà l'outil. Sinon ça te donne un faux sentiment de savoir ce que tu fais. Déjà elles touchent seulement à la surface et tu pourras jamais faire des opérations un peu plus poussée en cas de besoin (ça arrive souvent).

Tu dois être capable de déterminer les bonnes commandes selon ta situation, les interfaces te diront jamais quoi faire. Une interface te dira jamais de rebase ou comment checkout des fichiers en remote, alors qu'en réalité c'est des commandes très pratiques et souvent utilisées. Pour les flags aussi (--hard, --amend etc) c'est très important de connaître les conséquences de ces actions

Une fois que tu connais tout ça, tu sais comment cherry pick, revert, utiliser les log etc etc là tu peux te tourner vers un GUI comme gitkraken pour plus de visuel et faire des actions basiques en un clic (et encore je trouve que c'est plus rapide le terminal si t'as des alias et des shortcuts)

N'oublie pas git stash qui permet de sauvegarder tes modifs et tu peux les récupérer plus tard.

C'est ultra utile quand tu veux synchroniser avec le remote.

Le 13 mars 2023 à 22:07:13 :

Le 12 mars 2023 à 23:06:59 :
N'oublie pas git stash qui permet de sauvegarder tes modifs et tu peux les récupérer plus tard.

C'est ultra utile quand tu veux synchroniser avec le remote.

en général je fait une nouvelle branche temporaire et je commit dessus, c'est quoi l'avantage de stash par rapport à ça ?

Ton commit laisse une "trace" si tu finis par le rapatrier sur tes branches principales. Le stash c'est juste une sauvegarde personnelle de l'état des changements locaux "en cours" qui n'auraient pas forcément de sens en tant que commit.

En théorie, il faudrait éviter les commits qui ne font pas sens du genre: "work in progress" "save state". Dans les faits, ce n'est pas forcément grave car il reste le squash qui permettra de "gommer" ces états intermédiaires "instables".