Git Cheatsheet

stash workspace index local repository upstream repository status Displays: • paths that have differences between the index file and the current <code>HEAD</code> commit, • paths that have differences between the workspace and the index file, and • paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace relative to the named commit. add file... or dir... Adds the current content of new or modified files to the index, thus staging that content for inclusion in the next commit. add -u Adds the current content of modified (NOT NEW) files to the index. rm file(s)... Remove a file from the workspace and the index. mv file(s)... Move file in the workspace and the index. commit -a -m 'msg' Commit all files changed since your last commit, except untracked files (ie. all files that are already listed in the index). checkout files(s)... or dir reset HEAD file(s)... reset --hard

Git - pousser une branche sur un dépot distant | Debianworld Créer une branche Git permet de créer des branches relativement facilement. Un branche permet de développer dans son coin sans toucher à la branche principale, master. $ git branch ma-branche Pour vérifier que la branche a bien été créée : $ git branch * master ma-branche La branche est bien disponible :) Pour l'utiliser, il suffit d'utiliser la commande checkout : $ git checkout ma-branche Cool ! Pousser une branche Nous allons devoir pousser la branche sur notre origin qui se trouve être sur un serveur distant. $ git push origin ma-branche Pour s'assurer que la branche que je viens de pousser a bien été créée, je vais cloner mon dépôt distant : $ git clone Un git branch -a me dévoile : * master remotes/origin/HEAD -> origin/master remotes/origin/ma-branche remotes/origin/master Pour que quelqu'un puisse "suivre" les modifications de cette branche, il devra utiliser la commande suivante : $ git checkout -b ma-branche origin/ma-branche

Git, un modèle de branches efficace (2/2) La gestion des branches dans Subversion ou CVS n’est pas suffisamment simple et rapide pour encourager les développeurs à s’y frotter, voire les en dissuade : « Quoi ? Une branche ? Non, trop compliqué de gérer les conflits… on reste dans le trunk » Partant de ce constat, tous les développeurs restent dans « le trunk », avec tous les inconvénients que cela peut avoir : Mr X commit en deux parties son code, rendant l’espace de quelques instants l’intégralité du projet instableMr X commit une fonctionnalité en cours de développement, rendant le projet impossible à livrer tant qu’il n’aura pas terminé sa fonctionnalitéMr Y commit lui aussi une fonctionnalité en cours de développement, rendant le projet encore moins possible à livrer tant qu’il n’aura pas terminé sa fonctionnalité. Et nous nous retrouvons avec un trunk complètement instable ou un « hotfix » devient impossible à réaliser. C’est là que Git intervient en proposant une gestion des branches simple et rapide. Le master

A successful Git branching model » nvie.com Note of reflection (March 5, 2020)This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.This is not the class of software that I had in mind when I wrote the blog post 10 years ago. Why git? ¶ For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. The main branches ¶ develop

Git dans la pratique (2/2) Dans une première partie, nous avons abordé la notion d’index et la différence entre une branche locale et une branche distante. Une fois les notions d’index et de branches locales et distantes bien comprises, il est possible d’aborder des fonctionnalités plus avancées de Git. Oui, Git est efficace et flexible Mettre de côté des modifications Régulièrement, on se retrouve avec des modifications en cours sur notre copie de travail quand vient une tâche plus prioritaire. Plutôt que d’abandonner les modifications déjà effectuées, de commiter des modifications qui cassent une fonctionnalité, ou encore de créer un patch dans un fichier que l’on met de côté, Git nous propose d’utiliser git stash.Cette commande permet de mettre de côté toutes les modifications de la copie de travail et de l’index (il faut penser à ajouter les nouveaux fichiers qui ne sont pas encore suivis par Git). Pour reprendre le travail commencé et rangé il est possible de le récupérer de 2 façons différentes : Exemple