git - the simple guide
+just a simple guide for getting started with git. no deep shit ;)
+ + +
+ just a simple guide for getting started with git. no deep shit ;)
+ + +
+
+ create a new directory, open it and perform a
+ git init
+ to create a new git repository.
+
+ create a working copy of a local repository by running the command
+ git clone /path/to/repository
+ when using a remote server, your command will be
+ git clone username@host:/path/to/repository
+
+ your local repository consists of three "trees" maintained by git.
+ the first one is your Working Directory which holds the actual files.
+ the second one is the Index which acts as a staging area and
+ finally the HEAD which points to the last commit you've made.
+
+
+ You can propose changes (add it to the Index) using
+ git add <filename>
+ git add *
+ This is the first step in the basic git workflow. To actually commit these changes use
+ git commit -m "Commit message"
+ Now the file is committed to the HEAD, but not in your remote repository yet.
+
+ Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
+ git push origin master
+ Change master to whatever branch you want to push your changes to.
+
+ If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
+ git remote add origin <server>
+ Now you are able to push your changes to the selected remote server
+
+
+ Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion. +
+
+
+ create a new branch named "feature_x" and switch to it using
+ git checkout -b feature_x
+ switch back to master
+ git checkout master
+ and delete the branch again
+ git branch -d feature_x
+ a branch is not available to others unless you push the branch to your remote repository
+ git push origin <branch>
+
+ to update your local repository to the newest commit, execute
+ git pull
+ in your working directory to fetch and merge remote changes.
+ to merge another branch into your active branch (e.g. master), use
+ git merge <branch>
+ in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts.
+ You are responsible to merge those conflicts
+ manually by editing the files shown by git. After changing, you need to mark them as merged with
+ git add <filename>
+ before merging changes, you can also preview them by using
+ git diff <source_branch> <target_branch>
+
+ it's recommended to create tags for software releases. this is a known concept, which also exists in SVN. You can create a new tag named 1.0.0 by executing
+ git tag 1.0.0 1b2e1d63ff
+ the 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the...
+
+ in its simplest form, you can study repository history using..
+ git log
+ You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:
+ git log --author=bob
+ To see a very compressed log where each commit is one line:
+ git log --pretty=oneline
+ Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
+ git log --graph --oneline --decorate --all
+ See only which files have changed:
+ git log --name-status
+ These are just a few of the possible parameters you can use. For more, see
+ git log --help
+
+ In case you did something wrong, which for sure never happens ;), you can replace local changes using the command
+ git checkout -- <filename>
+ this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.
+
+ If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
+ git fetch origin
+ git reset --hard origin/master
+
+ built-in git GUI
+ gitk
+ use colorful git output
+ git config color.ui true
+ show log on just one line per commit
+ git config format.pretty oneline
+ use interactive adding
+ git add -i
+
+
+
+ ++
+ +juste un petit guide pour bien démarrer avec git. no deep shit ;)
+ +
+
+ créez un nouveau dossier, ouvrez le et exécutez la commande
+ git init
+ pour créer un nouveau dépôt.
+
+ créez une copie de votre dépôt local en exécutant la commande
+ git clone /path/to/repository
+ si vous utilisez un serveur distant, cette commande sera
+ git clone username@host:/path/to/repository
+
+ votre dépôt local est composé de trois "arbres" gérés par git.
+ le premier est votre espace de travail qui contient réellement vos fichiers.
+ le second est un Index qui joue un rôle d'espace de transit pour vos fichiers et
+ enfin HEAD qui pointe vers la dernière validation que vous ayez faite.
+
+
+ Vous pouvez proposer un changement (l'ajouter à l'Index) en exécutant les commandes
+ git add <filename>
+ git add *
+ C'est la première étape dans un workflow git basique. Pour valider ces changements, utilisez
+ git commit -m "Message de validation"
+ Le fichier est donc ajouté au HEAD, mais pas encore dans votre dépôt distant.
+
+ Vos changements sont maintenant dans le HEAD de la copie de votre dépôt local. Pour les envoyer à votre dépôt distant, exécutez la commande
+ git push origin master
+ Remplacez master par la branche dans laquelle vous souhaitez envoyer vos changements.
+
+ Si vous n'avez pas cloné votre dépôt existant et voulez le connecter à votre dépôt sur un serveur distant, vous devez l'ajouter avec
+ git remote add origin <server>
+ Maintenant, vous pouvez envoyer vos changements vers le serveur distant sélectionné
- function recordOutboundLink(link, category, action) {
- _gat._getTrackerByName()._trackEvent(category, action);
- setTimeout('document.location = "' + link.href + '"', 100);
- }
-
-
-
just a simple guide for getting started with git. no deep shit ;)
- - -
-
- create a new directory, open it and perform a
- git init
- to create a new git repository.
-
- create a working copy of a local repository by running the command
- git clone /path/to/repository
- when using a remote server, your command will be
- git clone username@host:/path/to/repository
-
- your local repository consists of three "trees" maintained by git.
- the first one is your Working Directory which holds the actual files.
- the second one is the Index which acts as a staging area and
- finally the HEAD which points to the last commit you've made.
-
-
- You can propose changes (add it to the Index) using
- git add <filename>
- git add *
- This is the first step in the basic git workflow. To actually commit these changes use
- git commit -m "Commit message"
- Now the file is committed to the HEAD, but not in your remote repository yet.
-
- Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
- git push origin master
- Change master to whatever branch you want to push your changes to.
-
- If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
- git remote add origin <server>
- Now you are able to push your changes to the selected remote server
-
-
- Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion. -
-
-
- create a new branch named "feature_x" and switch to it using
- git checkout -b feature_x
- switch back to master
- git checkout master
- and delete the branch again
- git branch -d feature_x
- a branch is not available to others unless you push the branch to your remote repository
- git push origin <branch>
-
- to update your local repository to the newest commit, execute
- git pull
- in your working directory to fetch and merge remote changes.
- to merge another branch into your active branch (e.g. master), use
- git merge <branch>
- in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts.
- You are responsible to merge those conflicts
- manually by editing the files shown by git. After changing, you need to mark them as merged with
- git add <filename>
- before merging changes, you can also preview them by using
- git diff <source_branch> <target_branch>
-
- it's recommended to create tags for software releases. this is a known concept, which also exists in SVN. You can create a new tag named 1.0.0 by executing
- git tag 1.0.0 1b2e1d63ff
- the 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the...
-
- in its simplest form, you can study repository history using..
- git log
- You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:
- git log --author=bob
- To see a very compressed log where each commit is one line:
- git log --pretty=oneline
- Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
- git log --graph --oneline --decorate --all
- See only which files have changed:
- git log --name-status
- These are just a few of the possible parameters you can use. For more, see
- git log --help
-
- In case you did something wrong, which for sure never happens ;), you can replace local changes using the command
- git checkout -- <filename>
- this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.
-
- If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
- git fetch origin
- git reset --hard origin/master
-
- built-in git GUI
- gitk
- use colorful git output
- git config color.ui true
- show log on just one line per commit
- git config format.pretty oneline
- use interactive adding
- git add -i
-
-
- + ++ Les branches sont utilisées pour développer des fonctionnalités isolées des autres. + La branche master est la branche par défaut quand vous créez un dépôt. + Utilisez les autres branches pour le développement et fusionnez ensuite à la branche principale quand vous avez fini. +
+
+
+ créer une nouvelle branche nommée "feature_x" et passer dessus pour l'utiliser
+ git checkout -b feature_x
+ retourner sur la branche principale
+ git checkout master
+ et supprimer la branche
+ git branch -d feature_x
+ une branche n'est pas disponible pour les autres tant que vous ne l'aurez pas envoyée vers votre dépôt distant
+ git push origin <branch>
+
+ pour mettre à jour votre dépôt local vers les dernières validations, exécutez la commande
+ git pull
+ dans votre espace de travail pour récupérer et fusionner les changements distants.
+ pour fusionner une autre branche avec la branche active (par exemple master), utilisez
+ git merge <branch>
+ dans les deux cas, git tente d'auto-fusionner les changements. Malheureusement, ça n'est pas toujours possible et résulte par des conflits.
+ Vous devez alors régler ces conflits
+ manuellement en éditant les fichiers indiqués par git. Après l'avoir fait, vous devez les marquer comme fusionnés avec
+ git add <filename>
+ après avoir fusionné les changements, vous pouvez en avoir un aperçu en utilisant
+ git diff <source_branch> <target_branch>
+
+ il est recommandé de créer des tags pour les releases de programmes. c'est un concept connu, qui existe aussi dans SVN. Vous pouvez créer un tag nommé 1.0.0 en exécutant la commande
+ git tag 1.0.0 1b2e1d63ff
+ le 1b2e1d63ff désigne les 10 premiers caractères de l'identifiant du changement que vous voulez référencer avec ce tag. Vous pouvez obtenir cet identifiant avec
+ git log
+ vous pouvez utiliser moins de caractères de cet identifiant, il doit juste rester unique.
+
+ Dans le cas où vous auriez fait quelque chose de travers (ce qui bien entendu n'arrive jamais ;) vous pouvez annuler les changements locaux en utilisant cette commande
+ git checkout -- <filename>
+ cela remplacera les changements dans votre arbre de travail avec le dernier contenu du HEAD. Les changements déjà ajoutés à l'index, aussi bien les nouveaux fichiers, seront gardés.
+
+ Si à la place vous voulez supprimer tous les changements et validations locaux, récupérez le dernier historique depuis le serveur et pointez la branche principale locale dessus comme ceci
+ git fetch origin
+ git reset --hard origin/master
+
+ Interface git incluse
+ gitk
+ utiliser des couleurs dans la sortie de git
+ git config color.ui true
+ afficher le journal sur une seule ligne pour chaque validation
+ git config format.pretty oneline
+ utiliser l'ajout interactif
+ git add -i
+
+
-
- -