To remove all merged branches(except current -v ‘*’):

git branch --merged | grep -v '*' | xargs git branch -D

also I made such command for repo complete clean up:

alias git-clean="git branch  | grep -v '*' | grep -v 'master' | xargs git branch -D  && git reset --hard && git clean -d -x -f"

Git pre-push hook будет выглядеть вот так:

[shell]
#!/bin/sh
grunt test
RETVAL=$?
if [ $RETVAL -ne 0 ]
then
echo "Grunt task failed, exiting…"
exit 1
fi

echo "Complete."
[/shell]

Как видите ничего сложного. Теперь при каждом пуше будет вызываться “grunt test“. Важно не забыть сделать этот файл исполняемым (chmod +x pre-push)

Есть еще один момент: когда вы попытались запушить поломанный код – тесты не прошли – вы починили код, но при этом забыли закоммитить – тесты прошли – и поломанный код попал на сервер (так как фикс не был закоммичен).

Поэтому перед началом тестов прячем все незакоммиченные изменения (git stash), а потом возвращаем их назад:

[shell]
#!/bin/sh
CHANGES=$(git diff –numstat | wc -l)
CHANGES_CACHED=$(git diff –cached –numstat | wc -l)
TOTAL_CHANGES=$(($CHANGES + $CHANGES_CACHED))

git stash -k
grunt test

RETVAL=$?

if [ $TOTAL_CHANGES -ne "0" ]
then
echo "Popping" $TOTAL_CHANGES "changes off the stack…"
git stash pop -q
fi

if [ $RETVAL -ne 0 ]
then
echo "Grunt task failed, exiting…"
exit 1
fi

echo "Complete."
[/shell]

Полный код тут. Идея взята от сюда.

Прописываем информацию о себе

Если вы еще этого не сделали, то крайне рекомендую – серьезно повышает читабельность логов:

[user]
name = Ivanov Ivan
email = ivan.ivanov@gmail.com

Алиасы команд

[alias]
co = checkout
ci = commit
br = branch
st = status --short
clean = branch -D
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

подбирается индивидуально по предпочтениям и частоте использования полных команд

Добавляем цветов

[color]
ui = true

Прописываем gitignore глобально

Вместо того, чтобы каждый раз прописывать какие-то файлы настроек, которые создает IDE(например .idea для продуктов JetBrains), в .gitignore, можно вынести их один раз в глобальные настройки.

[core]
excludesfile = ~/.gitexcludes

Задаем редактор

Командой (она добавит несколько параметров в конфиг)

$ git config --global core.editor sourcetree

в моем случае это sourcetree. Теперь все конфликты и дифы будет обрабатываться в нем.

commit-сообщения по умолчанию

тоже вероятно упростит жизнь для мелких коммитов и коммитов, которые должны следовать определенному шаблону

[commit]
template = ~/.commit-template

Если вдохновило – полный ман тут.

сначала добавляем, то что забыли:

git add .

потом вносим правку:

git commit --amend

так же можно дописать комментарий:

git commit --amend -m 'really serious changes'

* для git-гуру понятно дело ничего нового нет

git branch --merged | grep -v '*' | xargs git branch -D

еще для себя я сделал такую алиас-команду для полной зачистки репозитория от изменений и старых веток:

alias git-clean="git branch  | grep -v '*' | grep -v 'develop' | xargs git branch -D  && git reset --hard && git clean -d -x -f"

критика приветствуется.

Настраивая систему разворачивания проекта с репозитория, мы задумались над вопросом чистоты кода репозитория, ибо тесты на самом сервере – это хорошо, но в системе контроля версий также совсем не помешает держать рабочий код, особенно в “стабильной” ветке.

Как вариант решения:  сделать git-hook, который бы проверял каждый push на репозиторий и не давал заливать “плохой” код. (Под “плохой” мы будем понимать код, который не прошел юнит-тестов либо валидации JSHint)

О самом  git hook можно почитать подробно на официальном сайте. Расскажу только некоторые детали реализации.

Все хуки лежат в директории ./git/hooks/. Там же есть уже готовые примеры реализованные на shell-скрипте(с расширением .sample).

Список возможных действий, на которые можно повесить обработчик:

• applypatch-msg
• post-commit
• post-update
• pre-commit
• update
• commit-msg
• post-receive
• pre-applypatch
• pre-rebase

– подробное описание можно посмотреть тут.

Все перехватчики(hooks) можно разделить по месту их выполнения на клиентские и серверные. В нашем случае мы можем проверять код как на стороне клиента перед отправкой, так и на стороне сервера после получения. В первом случае решение будет менее строгим, т.к. позволит разработчику отключить или изменить его в случае чего. Для этого создаем файл pre-commit, где будет описание действия нашего перехватчика.

Теперь стоит подумать как лучше реализовать код перехватчика. Сначала была мысль написать shell-скрипт, но потом мы вспомнили о grunt, который уже прекрасно работал с проектом, и просто добавили еще одно задание(task) в него – pre-commit-test, в котором описали все необходимые проверки. Осталось только вызывать сборщик из hook-скрипта. Вот весь код:

#!/bin/sh

GRUNTJS_DIR='/path_to_project/project_dir'
GRUNT_CMD=grunt
cd $GRUNTJS_DIR
$GRUNT_CMD pre-commit-test
EXIT_CODE=$?
[ $EXIT_CODE -gt 0 ] && echo && echo validation fail! && echo
exit $EXIT_CODE

Немного комментариев:

GRUNT_CMD=grunt

пусть к команде grunt(в случае, если она не глобальная)

[ $EXIT_CODE -gt 0 ]

проверяем выдал ли что-то валидатор и в случае чего – прерываем выполнение.

подробнее на офсайте.