Git merge vs. rebase
The short: git pull --rebase instead of git pullgit rebase -i @{u} before git push(on “feature”) git merge master to make feature compatible with latest master(on “master”) git merge --no-ff feature to ship a feature However if “feature” contains only 1 commit, avoid the merge commit:(on “master”) git cherry-pick feature The long: If you enjoy this post, check out my git tips you didn’t know about! Avoid merge commits that result from git pull When you want to push your changes to a branch, but someone else already pushed before you, you have to pull in their changes first. Such merge commits can be numerous, especially between a team of people who push their changes often. You should always pull with git pull --rebase. git config --global --bool pull.rebase true Interactively rebase local commits before pushing Run this every time before pushing a set of commits: git rebase -i @{u} Suppose you have a set of 4 commits (newest first): [D] oops! git merge --no-ff feature git cherry-pick feature
Configuring git colors (Shallow Thoughts) - Iceweasel
I spent a morning wrestling with git after writing a minor GIMP fix that I wanted to check in. Deceptively simple ideas, like "Check the git log to see the expected format of check-in messages", turned out to be easier said than done. Part of the problem was git's default colors: colors calculated to be invisible to anyone using a terminal with dark text on a light background. And that sent me down the perilous path of git configuration. git-config does have a manual page. But that's okay, thought I: all I need to do is list the default settings, then change anything that's a light color like yellow to a darker color. Well, no. But you can find most of them with a seach for GIT_COLOR in the source. gitconfig The next step is to translate those C lines to git preferences, something you can put in a .gitconfig. The syntax and colors are fairly clearly explained in the manual: allowable colors are normal, black, red, green, yellow, blue, magenta, cyan and white.
workspace • Git Cheatsheet • NDP Software
stash workspace index local repository upstream repository status Displays: <br>• paths that have differences between the index file and the current <code>HEAD</code> commit, <br>• paths that have differences between the workspace and the index file, and <br>• 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 <em>commit</em>. 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
Mémento Git à 100% - - De Raphaël Hertzog et Pierre Habouzit (EAN13 : 9782212181111)
La collection mémento enfin en version numérique ! Utilisé depuis plus de 5 ans pour le noyau Linux, Git est le système révolutionnaire de gestion de versions, plébiscité chez les développeurs modernes. Co-écrit par deux développeurs Git et Debian, ce mémento aidera les développeurs qui découvrent la gestion de versions avec Git à optimiser leurs processus d'édition collaborative et à exploiter sans risque la puissance de cet outil, qui succède à CVS et SVN. Le développeur verra rappelées toutes les commandes de création, d'exploration, de modification, d'annulation et de restauration de code ou de branche, avec un schéma illustrant les commandes liées aux cinq grands lieux de Git : le cache (stash), le répertoire de travail, l'index, le dépôt local et le dépôt distant. Les auteurs complètent le mémento de nombreux conseils d'utilisation - ce qu'est un bon commit, comment l'écrire...
A quick guide to pull requests « Otaku, Cedric's blog - Iceweasel
It’s pretty common for projects hosted on GitHub to receive “pull requests”: requests from people who have cloned your project, made a modification to it and then asking you to merge their changes back into the main project. There are a lot of ways you can handle these pull requests, here are some of them. Using GitHub’s web interface If you go to the “Fork Queue” panel of your GitHub dashboard, you will see all the pull requests that have been issued by contributors. I rarely use the web interface because I usually want to test the changes on my machine before committing them. Having said that, the web interface is convenient to quickly apply cosmetic commits that don’t change any code (documentation updates, space clean up, etc…). git am The git am command allows you apply a diff to your working directory. This works with regular commits as well: After this, you can just push your branch. Merging the remote branch Cherry picking Have I forgotten anything?
github-git-cheat-sheet.pdf
Soirée Git - prez @sdouche
everything I know about git - Iceweasel
How to export revision history from mercurial or git to cvs
