distante : git push origin --delete [nom_de_la_branche]

git reset --hard past_commit
git reset current_commit
git commit

git rebase -i --root master

git rebase -i $(git merge-base HEAD master)

alias grbb='git rebase -i $(git merge-base HEAD master)'

Pour modifier un commit sur sa branche qui est déjà plusieurs commits derrière HEAD
1) modifier les fichiers..
2) git add les fichiers
3) git commit --fixup $hash_de_l_ancien_commit

A partir de la un nouveau commit avec le commentaire fixup! est créé
Ensuite on peut lancer le rebase interactif avec l'option autosquash qui va ordonner tout ça proprement :

git rebase -i ancien_commit --autosquash

il y a aussi l'option --squash pour git commit qui va squash dans le rebase interactif au lieu de fixup

via Martin

git merge-base branch2 branch3
050dc022f3a65bdc78d97e2b1ac9b595a924c3f2

git merge-base HEAD origin/master

Instead of using -f or --force developers should use

--force-with-lease

Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.

he Base Script

This bash "one-liner" displays all blob objects in the repository, sorted from smallest to largest.
For my sample repo, it ran about 100 times faster than the other ones found here.

git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
| awk '/^blob/ {print substr($0,6)}' \
| sort --numeric-sort --key=2 \
| cut --complement --characters=13-40 \
| numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest

This will generate nice human-readable output like this:

...
0d99bb931299 530KiB path/to/some-image.jpg
2ba44098e28f 12MiB path/to/hires-image.png
bd1741ddce0d 63MiB path/to/some-video-1080p.mp4

Filtering

To achieve further filtering, insert any of the following lines before the sort line.

To exclude files that are present in HEAD, insert the following line:

| grep -vF "$(git ls-tree -r HEAD | awk '{print $3}')" \

To show only files exceeding given size (e.g. 1 MiB = 220 B), insert the following line:

| awk '$2 >= 2^20' \

Output for Computers

To generate output that's more suitable for further processing by computers, omit the last two lines of the base script. They do all the formatting. This will leave you with something like this:

...
0d99bb93129939b72069df14af0d0dbda7eb6dba 542455 path/to/some-image.jpg
2ba44098e28f8f66bac5e21210c2774085d2319b 12446815 path/to/hires-image.png
bd1741ddce0d07b72ccf69ed281e09bf8a2d0b2f 65183843 path/to/some-video-1080p.mp4

To clean old file in repo

Or "how to search text in git diff history"
git log -p -S "string"

The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...

git reflog

and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).

Suppose the old commit was HEAD@{5} in the ref log:

git reset --hard HEAD@{5}

perso je tends pour le rebase

I've edited my .vimrc to add fugitive plugin and commited it by using fugitive

Voir fichier à un commit :
git show HASH:path/to/file

Hash du commit initial :
git rev-list --max-parents=0 HEAD

Voir liste fichiers modifiés entre 2 commits :
git diff --name-only SHA1 SHA2
git log --name-status --oneline HEAD~6..HEAD
git log --name-status --oneline HEAD~6..HEAD |grep -vP '^\S[^\s]'|sort|uniq

Voir modif sur un fichier entre 2 commits :
git diff SHA1 SHA2 main.c

Trouver l'ancetre commun le plus vieux
git config --global alias.oldest-ancestor '!bash -c '\''diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne "s/^ //p" | head -1'\'' -'
git oldest-ancestor

git rebase -i [HASH parent]

man -7 gitrevisions

HEAD
HEAD~1 HEAD^ HEAD^1
HEAD~2 HEAD^2 HEAD~1^
HEAD~3

10:10 V /tmp/git_test [master L|V]
$ git lola

• 52f73ef (HEAD -> refs/heads/master) Merge branch 'toto'
  |\
  | * 2f39200 (refs/heads/toto) commit on toto
• | d581320 Commit on master
  |/
• eae368a first commit
  10:10 V /tmp/git_test [master L|V]
  $ git log --name-status --oneline eae368a..52f73ef
  52f73ef Merge branch 'toto'
  d581320 Commit on master
  A tata
  2f39200 commit on toto
  A b

git branch -a --sort=-committerdate

je découvre ce plugin vim qui a l'air juste magique pour interagir avec git

The -m option specifies the parent number. This is because a merge commit has more than one parent, and Git does not know automatically which parent was the mainline, and which parent was the branch you want to un-merge.

When you view a merge commit in the output of git log, you will see its parents listed on the line that begins with Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James ben@example.com
Date: Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
README

In this situation, git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0, and git revert -m 2 will reinstate the tree as it was in 7c6b236.

git remote update origin --prune

Un workflow git qui a le mérite d'être simple : le cactus

Pour cancel un commit qui n'a pas encore été push

git reset --soft HEAD^

Show what will be deleted with the -n option:

git clean -f -n

Then - beware: this will delete files - run:

git clean -f

Pratique pour cloner en http

servir betement avec apache

• hoot post-update :
  exec git update-server-info

/me découvre les cherry-pick

git config receive.denyNonFastforwards true

via alk

Une couche permettant de faire de la review

Je prends de plus en plus le réflexe de "git init" dans certains dossiers un peu chaud qui bougent beaucoup comme des dossiers de configuration..

Et là arrive le moment où je me pose la question : qu'est ce que j'ai touché depuis que j'ai fais mon git ini ? Et voilà la commande magique qui répond à ma question :

git diff --name-only SHA1 SHA2

Après si vous voulez la liste entre le premier et le dernier commit :
git diff --name-only HEAD $(git log --format=%H | tail -1)

tout est dans le titre

via Skunnyk

conseils pour les messages de commit

Quelques trucs sympas, mais encore un peu avancés pour le moment

• http://symfony.com/doc/2.0/contributing/code/patches.html#step-3-submit-your-patch
• http://labs.excilys.com/2012/02/28/preparez-vous-a-reecrire-lhistoire-avec-git-rebase/

Ignorer un fichier versionné :
git update-index --assume-unchanged path/to/file.txt

Workflow for continuous integration environments

Y'a rien à dire sur ce book, c'est clair, concis, bien schématisé. Je viens de me faire la partie sur les branches car je commence à en avoir besoin sur plusieurs projets comme Piclodio2

Un autre site avec plein d'article sur git

Quelques best practices