Parce que je ne m'en souviens jamais de la commande magique : git rebase -i HEAD~X
où X et le nombre de commits à fusionner depuis le HEAD (HEAD inclus)
Puis penser à remplacer de bas en haut les pick
des lignes du début par des squash
(tout ce qui est squash
sera fusionné avec le commit de la ligne au-dessus).
Pour toi @Philou ! Ce peut être intéressant de surveiller certains fichiers sensibles de nos répos (je pense via notre GitBot) afin de détecter des commits dessus.
Le script à mettre dans .git/hooks/post-merge
#!/usr/bin/env bash
# On met ici tous les fichiers (ou pattern de nom) qu'on veut surveiller
# changez les pour les adapter à votre projet
files=('settings.py' 'migrations');
# on récupère tous les noms de fichiers modifiés depuis le dernier merge
modified_files=`git diff "HEAD@{1}" --name-only`
# on boucle sur chaque nom de fichier surveillé
for watched_file in "${files[@]}"; do
# on liste tous les fichiers modifiés qui correspondent à ce nom de
# fichier surveillé
modified_watched_files=(`echo "$modified_files" | grep $watched_file`)
# si le nombre de fichiers correspondant est plus grand que 0
if [ ${#modified_watched_files[@]} ]; then
# pour chaque fichier qui correspond, on affiche un avertissement
# en rouge
for modified_watched_file in "${modified_watched_files[@]}"; do
echo -e "\e[41m "$modified_watched_file" has changed \033[0m"
done
fi
done
Je copie colle ici :
#!/usr/bin/env bash
set -o errexit
# Author: David Underhill
# Script to permanently delete files/folders from your git repository. To use
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-remove-history path1 path2
#
# retrieved from: http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/
#
if [ $# -eq 0 ]; then
exit 0are still
fi
# make sure we're at the root of git repo
if [ ! -d .git ]; then
echo "Error: must run this script from the root of a git repository"
exit 1
fi
# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD
# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune
J'oublie tout le temps la manipe :
git checkout #hashLast
git reset --soft #hashFirst
git commit --amend -m '1 2 3 4 5'
git rebase HEAD master
Les mécanismes de versioning des applications ne sont pas forcément les mêmes en fonction des contextes.
Typiquement si un Product-Team n'est pas impactée par les problématiques de modification de version de Maven, des Project-Team qui modifient chacune des composants d'un gigantesque monolithe, quant à elles le sont.
Merci à Philou pour son lien ainsi que les deux suivants :
Un très bon article sur Git et les types de push. Je ne connaissais pas le --force-with-lease
et je pense que je vais l'utiliser.
Anisble Galaxy et Gitea comme repository de rôles.
La commande magique pour récupérer un rôle depuis un répo :
ansible-galaxy install -r "${YML_FILE}" --force -p "${ROLES_DIR}"
Comment récupérer le contenu d'un répo Git à un commit en particulier, sans récupérer tout l'historique ?
Assez simple avec les shallows clones via un fetch :
git fetch --depth=1 ../testrepo/.git $SHA1
Et a priori via un clone ce doit être pareil (pas testé) :
git clone --depth=1 ../testrepo/.git $SHA1
Lister les commiteurs d'un répo :
git log --pretty=format:"%an (%ae)" | tr '[:upper:]' '[:lower:]' | uniq | sort
Compter ce nombre de commiteurs :
git log --pretty=format:"%an (%ae)" | tr '[:upper:]' '[:lower:]' | uniq | wc -l
Et qui se connecte à autre chose que GitHub !!! :D #Neeeeeeed
On va pouvoir coder de nouveau sous Android dans le train.
Tuto très sympa. @Lenny, si tu as le temps, essaie de lire ce post. Il y a quelques idées à prendre 😃.
La structure de commit que je propose (en reprenant ce que dit l'article) :
Summarize changes in around 80 characters or less
More detailed explanatory text, if necessary. Wrap it to about 120 characters or so. In some contexts, the first line is
treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from
the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get
confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code
explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain
them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank
lines in between, but conventions vary here
If you use an issue tracker, put references to them at the bottom, like this:
Resolves: #123
See also: #456, #789
Montrer un historique des diffs via des animations CSS est une excellente idée !!!
Bravo
Meilleur site web que je n'ai jamais utilisé pour apprendre Git. Clairement, c'est une perle !
Via le styx
À faire en deux étapes :
# Supprimer le tag en local
git tag --delete <MON_TAG>
# Supprimer le tag du répo distant
git push --delete origin <MON_TAG>
En une infographie !
Tapez cette commande et voilà :
git config --global core.autocrlf input