Все исходные тексты в ООО “Сигранд” находятся в централизованных репозиториях git.
В репозиториях исходных текстов могут хранится только исходные тексты.
(source code): Набор данных (data set), файл, содержимое которого создано непосредственно человеком и находящимся в начале цепи возможных последующих преобразований.
Исходный текст может создаваться, например, через редактор текстов или интерактивный генератор файлов конфигурации или редактор изображений.
Любые файлы, порождаемые автоматически или полуавтоматически из других файлов, не являются исходными текстами.
Репозитории исходных текстов Сигранд можно посмотреть через web:
Доступ только на чтение для большинства репозиториев возможен для всех через протокол git:
git clone git://sigrand.ru/<REPO>.git
где <REPO> - имя одного из репозиториев.
Далее читайте 00README-GIT внутри.
Доступ с правами записи (изменения репозитория) возможен только через протокол ssh.
Права доступа к репозиториям, веткам, файлам индивидуальны и обеспечиваются gitolite.
Для получения доступа каждому новому разработчику нужно выполнить следующие обязательные требования:
Иметь личное имя пользователя (login name) на своей рабочей станции UNIX.
login name - это то, что выводится по команде “id -un”.
Иметь личный e-mail адрес.
Иметь заполненную секцию [User] в файле .gitconfig в домашнем каталоге пользователя.
Указанное имя пользователя используется для разграничения прав доступа к репозиториям и в коммитах.
Имена подобные ‘user’, ‘ubuntu’, ‘root’, <имя компании> - неприемлемы.
создать ssh ключ, если его ещё нет:
ssh-keygen -t rsa
прислать публичную часть ключа ($HOME/.ssh/id_rsa.pub) администратору репозитория.
прислать индивидуальный e-mail. Он будет включён в список для автоматической рассылки уведомлений об изменениях в репозитории.
После получения в ответ дополнительных инструкций и рекомендаций от администратора репозитория, доступ будет предоставлен.
git clone --recursive [-b <ВЕТКА-РАЗРАБОТЧИКА>] ssh://git@sigrand.ru/<REPO>.git
cd <REPO>
Каждому разработчику (или группе разработчиков) предоставляется ветка, на которую он имеет права записи. Все оcтальные ветки, как правило, доступны на чтение.
Ветка master поддерживается Главным Разработчиком.
Разработчик обязан время от времени обновлять свою ветку из ветки master:
git fetch
git merge origin/master
и заталкивать слитое обратно:
git push
Чем чаще это делается, тем легче проходят слияния и тем легче будет влить ветку разработчика в master.
Большинство проектов имеют субмодули git.
Команда “git submodule” покажет список субмодулей.
Пример:
git submodule
b0d05e916456bcfc40e2bfeb7704657337e6e483 common_xw (heads/master)
e2188babbc528869c59699865176fa34bfd48eeb sigticam/platform/ti_dm368/appro (CV_1.9_MERGE-3-ge2188ba)
5448ff8cf4ad59d1f6cd4a174c1c9d40db553173 sigticam/platform/ti_dm368/dvsdk (heads/devel_dm368_mt5-3.0.0)
9fa36da83f32c7a78e25752c0351d9604418b451 sigticam/platform/ti_dm368/u-boot (ipnc_dm36x_1.0.1-6-g9fa36da)
af381bff8591675cd01e6d0d4e799d3185e9bef9 sigticam/src/libebb (heads/master)
d340f9fd155dc40aa3aecfedb813d3ee4e0931f2 xwmake (heads/master)
При каждом обновлении проекта, имеющего субмодули, необходимо обновить и субмодули:
git submodule update --init
Следует учитывать, что при этом субмодули указывают последний коммит, как не принадлежащий никакой ветке:
pushd <submodule-path>
git branch
* (no branch)
master
git status
# Not currently on any branch.
nothing to commit (working directory clean)
Если разработчик не планирует вносить изменения в субмодуль, этого достаточно.
popd
Если же планируются изменения в субмодуле, необходимо переключить его на HEAD нужной ветки:
git checkout master
Ветвь субмодуля может быть не master, а другой, в зависимости от особенностей проекта и субмодуля, например:
pushd sigticam/platform/ti_dm368/appro
git checkout -b devel_dm368 origin/devel_dm368
popd
Последняя команда git делает удалённую ветку origin/devel_dm368 субмодуля текущей веткой devel_dm368, на голову которой и показывает надрепозиторий.
Осмысленные комментарии к коммитам обязательны. Комментарии пишутся либо на русском языке, либо на английском. Комментарии на русском языке хранятся в кодировке UTF-8.
Если разработчик использует другую кодировку, например, KOI8-R, то в местный репозиторий нужно поместить перекодирующий скрипт:
.git/hooks/commit-msg:
#!/bin/sh
case $LANG in
ru_RU.KOI8-R)
iconv -f KOI8-R -t UTF-8 $1 > $1.utf8 && mv $1.utf8 $1
exit $?
;;
esac
а в $HOME/.gitconfig в секцию [i18n]:
[i18n]
commitencoding = UTF-8
logOutputEncoding = KOI8-R
коммитить изменения в свой местный репозиторий “мелкими порциями”, каждое отдельное по смыслу или по части исходных текстов изменение должны быть отдельным commit. Это наименее понимаемое, но наиболее важное положение.
Коммит с комментарием “Добавлено такая-то фича а заодно исправлены такие-то баги” неприемлем - это должны быть отдельные коммиты для каждой “фичи” и для каждого отдельного “бага”. Десяток мелких коммитов в день - обычная средняя работа.
периодически (при активной работе - не реже 1 раза в сутки, как правило, в конце рабочего дня) проталкивать (git push) изменения в своей ветке своего местного репозитория в ту же ветку центрального репозитория.
периодически сливать основную ветку master со своей:
git fetch
git merge origin/master
и заталкивать обратно:
git push
Рекомендуемый $HOME/.gitconfig:
[user]
name = Stupid Moron # I'm too stupid to change these two lines
email = stupid.moron@gmail.com
[core]
compression = 9
editor = nano -w
[alias]
st = status
ci = commit
co = checkout
br = branch
re = remote
what = whatchanged
sh = !git-sh
sub = submodule
[color]
branch = auto
diff = auto
interactive = auto
pager = true
ui = auto
status = true
[diff]
renames = copy # basic rename detection + detect copies
[commit]
# template = <file>
# Specify a file to use as the template for new commit messages.
[push]
default = matching # default
[rerere]
enabled = true
[merge]
log = false
renameLimit = 1000000
[mergetool]
keepBackup = true # true is the default
[receive]
fsckObjects = true
[status]
submodulesummary = true
[i18n]
commitencoding = UTF-8
#logOutputEncoding = KOI8-R