Авторизация идёт по ключу. Ключи брать у Asmodeus’a.
Прописать путь к ключу в /etc/ssh/ssh_config

Host abills.net.ua
 IdentityFile **Путь к ключу**

Указываем свои даные

# git config --global user.name *Имя разработчика*
# git config --global user.mail *e-mail разработчика*

Клонирование репозитория

# cd /usr
# git clone git@abills.net.ua:abills.git

*Если просит пароль для git, значит не подхватило ключ.

Для примера, рассмотрим правку модуля Msgs. Переходим в dev:

# git checkout dev

Стягиваем обновления из dev

# git pull origin dev 

Отделяем ветку

# git branch Msgs

Переходим в новую ветку

# git checkout Msgs

Можно одной командой

# git checkout -b Msgs

Создаём новую ветку для задачи Msgs

# git checkout -b Msgs

В новой ветке:
Повторить нужное количество раз:
<эти действия>
Редактируем до достижения результата.

# edit some files\\
Фиксируем изменения:\\
# git commit -a -m ‘(описание изменений)’\\

</эти действия>

Заливаем в основной репозиторий в ветку Msgs

# git push origin Msgs

Перемещаем свою папку abills
Клонируем репозиторий
Отделяем ветку
Вносим свои изменения из копии
Фиксируем.

Conflict Если несколько человек редактировали один файл, может возникнуть конфликт слияния.
После git pull и сообщения о возникновения конфликта

# vimdiff *путь к файлу*

ищем »»>HEAD
…..
===========
…..
««««<Msgs
Оставляем нужную часть, сохраняем
добавляем в index

# git add *путь к файлу*

Фиксируем,
Повторяем git pull

возврат к коммиту:

# git revert (hash-код комита)

возврат на 5 коммитов назад:

# git reset HEAD~5

Посмотреть историю коммитов для текущей ветки

# git log

Посмотреть, кто что правил в файле

# git blame <путь/к/файлу/имя файла>

 Если во время работы над одной веткой, нужно перейти в другую, без фиксации изменений
“Прячем” изменения:

# git stash

Переходим в другую ветку:

# git checkout branch2

Редактируем:

# edit some files

Фиксируем:

# git commit -a -m ‘message’

Возвращаемся в первую ветку:

# git checkout branch1

Применяем спрятанные изменения:

# git stash pop

Git log варианты вывода

git log --graph --pretty=format:"%C(yellow)%h%Creset%C(blue)%d%Creset %C(white bold)%s%Creset %C(white dim)(by %an %ar)%Creset" --all

# git remote update origin --prune

Вставить в ~/.gitconfig в секцию [alias]

[alias]
  st=status

  pl = pull
  ph = push
  b = branch
  ch = checkout
  df = diff

  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
  type = cat-file -t
  dump = cat-file -p

Подготовка кода к review

1. Убедиться, что функционал работает
   

• Если это подключаемый функционал (через права или опцию в конфиге), убедиться что при выключении функционала система работает так же, как и до внесения изменений.
  1. Просмотреть код и убрать всё, что использовалось при отладке (_bp, Dumper, импорт модулей с этими функциями)
  2. Для алгоритмически сложных частей написать в комментариях, что именно делает код и почему использовалось именно это решение.

Залить код для проверки

1. Залить в отдельную ветку для review (текущая_ветка_review)
2. Слить основную ветку (dev или ветку review'ера)
3. Поменять статус задачи на «На тестировании». Написать имя ветки в комментариях к задаче.
4. Уведомить ответственного за review гарантированным методом (личный контакт или по договорённости)

Обработать результат review
После получения ответа
Если задача перемещена в статус «Обратная связь»

• Слить (merge) ветку _review в ветку задачи.
• В комментариях задачи просмотреть замечания (если есть)

Если задача перемещена в статус «Решена»

• Ожидать решения ПМ по закрытию задачи.

1. Перейти на ветку для проверки задачи
2. Проверить выполнение
3. Проверить функционал
4. Проверить код (отметить подозрительные места, если есть). Где надо, выставить пометки # TODO: comments.
5. Залить свою ветку в ветку _review
6. Оставить замечания в комментариях к задаче.
7. Выставить нужный статус (Решена или Обратная связь )

http://asmodeus.com.ua/lib/category/programming/git/