не совсем. в гите есть git command --help, которая выводит краткую информацию о ключах команды и есть git help command — которая предоставляет полноценный ман.
Вот интересно как автор решает проблемы с бинарными файлами в репозитории (если они возникают конечно).
Поясню, что имею ввиду: хранить бинарники в vcs не очень хорошая идея, но иногда нет выхода. К примеру это может быть файл с ресурсами для флешки, картинки или схожие ресурсы у которых нету текстовых исходников.
Так вот, если разработка svn-like — то проблемы особо нет — ктото предупреждает остальных, что файл будет им изменен, меняет, заливает и освобождает этот ресурс. Но вот в случае если в мастер принимаются патчи и мёржатся одним человеком — пока он не смержит изменения — никто не может менять файл.
Я вижу пока только 2 варианта — не хранить файлы в vcs, но тогда дополнительно надо иметь доступ к хранилищу этих файлов (samba, NFS), а также у них не будет исптории. Или хранить в отдельном репозитории с svn-like подходом.
Согласен, я лишь хотел заметить, что запретить коммитить в отдельно взятый бранч в одном репозитории возможно.
А в ядре, насколько я знаю, в основном пулят, а не пушат изменения.
В принципе если работа происходит в офисе и у суперразработчика есть доступ на все машины по ssh — то можно пулить в свой репозиторий прямо с персональных репозиториев;)
Но если в комманде есть редиска, который ходит на работу с ноутбуком — то всё становится тяжелее;)
Ерундой может оказаться случайно измененный файл (ненужный пробел, перевод строки, ...), вывод отладочной информации (к примеру излишне подробный логгинг) и тому подобные изменения.
Лучше всё-таки просматривать код до коммита (git add -p, git gui). В крайнем случае — git status + git diff + git commit -a.
Но в одном репозитории нельзя разделить доступ к отдельным бранчам, т.е. нельзя разрешить писать в репозиторий новые бранчи и при этом запретить изменять актуальную ветку.
можно. используя pre-receive хук:
#!/bin/sh
while read a; do
branch=`echo $a | cut -d" " -f3`
if [ $branch == "refs/heads/master" -o $branch == "refs/heads/stage" ]; then
username=`whoami`
if [ $username != 'superuser1' -a $username != 'superuser2' ]; then
echo "* You not authorized to commit to $branch branch!!! *" 1>&2
exit 1
fi
fi
done
Также можно отослать себе email — с нотификацией, что кто-то хотел залиться в мастер.
Ну в придачу ещё две полезные комманды: git rerere — позволяет записывать решение конфликтов и при повторном мерже использовать их. Помогает в случае если бранч живет долго и часто возникает необходимость мержится с другими бранчами. Включается просто: git config --global rerere.enabled 1
И git rebase --onto. Позволяет перенести ветку с одним основанием на другое. Когда полезно: Есть мастер в котором происходит активная разработка. В определенный момент был начат бранч с новой независимой фичей, но от текущего мастера. Фича сделана и в принципе может быть внесена в стабильную ветку, но из-за того что она была начата на от стабильной ветки, при обычном мерже потянет за собой коммиты, которые не должны попасть в стабильную версию. На выручку приходит git rebase --onto, который позволяет создать ветку которая будет начинаться от стабильной версии и содержать все коммиты, которые были сделаны в ветке от мастера.
чем атомарнее коммит — там легче мёрж. так как коммит происходит на локальной машине без оверхеда работы по сети — то коммиты можно делать хоть раз в 5 минут
но иногда закапываешься в какую-то проблему, попутно исправляешь какие-то баги — в итоге в файле накапливаются изменения не связаные друг — с другом.
в таком случае лучше закоммитить по ханкам — всё что относится к одной фиче — в один коммит, что к другой — в другой коммит.
кроме того, очень полезная комманда: git cherry-pick. использовать можно так — есть бранч, в котором новая фича и его нельзя пока мержить в мастер. Но там попутно исправлено пару багов, а вас просят влить эти исправления в мастер. Делается в бранче сделаном от мастера
git cherry-pick BUGFIX_COMMIT_SHA1
и не надо заново вносить изменения или как-то менять историю (в этом случае вы подумаете, что «как хорошо, что я дулал коммиты атомарными и этот багфикс не тянет за собой кучу изменений связаных с новой фичей»)
X11Forwarding не так интересен как агент ssh и форвардинг агента.
Чтоб не вводить пароль каждый раз при коннекте к серваку (ключь без пароля не следует использовать) можно использовать ssh-agent.
Скорее всего при старте иксов он уже запущен и достаточно сделать
ssh-add
И ввести ключик один раз. Далее пока жив терминал в котором введена комманда — пароль к ключу спрашиваться не будет.
Если же ssh-add говорит, что агент не найден — смело делаем
ssh-agent bash
А внутри запущенного шела — пишем — ssh-add.
Ну а ещё полезнее фича называемая — SSH-Forwarding.
Она позволяет использовать агент на машине пользователя при коннекте к группе серверов. Тоесть зашел на один сервер, а с него без ввода пароля и пароля к ключу — простой коммандой ssh hostname — перейти на другой сервер.
Скоммандлайна надо использовать
ssh -A hostname
Ну а лучше в конфиге клиента ssh (/etc/ssh/ssh_config) прописать
Использую git, svn.
Спасибо за хинт по TortoiseGit. Может он поможет перевести всех девелоперов только на git.
Чуть больше года назад имел опыт перевода комманды с svn на git. Линуховая часть довольно легко приспособилась, а вод с виндузятниками были большие проблемы (использовали msysgit, скорость и стабильность которого оставляли желать лучшего). Тогда ещё не было TortoiseGit, хотя я его искал;)
Сейчас виндузятники на svn, а линуксоиды на git. Самописным скриптом общие части репозитория синхронизируются в обе стороны (с использованием git-svn, но так чтоб история в основном гитовом репозитории не выпрямлялась).
Ну тут дело не в преимуществе одного метода над другим, а выборе верного метода под конкретную задачу. К примеру:
1. git/svn/hg/… — для контроля версий
2. deb/rpm/… — для хранения бинарных данных, трекинга зависимостей, менеджмента версий средствами ОС
3. capistrano/vlad the deployer/… — для автоматизации работы на нескольких серверах, автоматизации выливки и отката изменений и тд.
Для простого сайта на одном сервере, выливка на который сводится только к обновлению версии кода, вполне подойдет использование сугубо vcs.
Для сайта на одном-двух серверах, который состоит из нескольких модулей и сложными зависимостями на установленые приложения (либо включает в себя компоненты на с/c++, которые должны быть собраны в бинарники) — оптимальным будет использование пакетов, так как часть работы ложится на пакетный менеджер ОС.
Для развернутых на большом числе машин и сложной системой развартывания — лучше использовать специальные системы деплоя типа capistrano. Причем можно использовать в комбинации как с vcs, так и с теми же пакетами.
У меня мало опыта работы с системами автоматического деплоя, но есть планы по внедрению capistrano в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
Да именно — код на php, swf-ки, верстка, статические картинки. Ну а так же все демоны, обслуживающие сайт. Как раз из-за демонов и было прийнято решение перейти на пакеты.
Используя пакеты вместо VCS облегчается сама выливка. И её может проводить не программист, а админ (который умеет работать с пакетной системой и не хочет знать что такое код и как его выливать).
Для выливок сугубо скриптовой части, в принципе, подойдут и Capistrano, Vlad the Deployer и похожие утилиты (они могут забирать исходики с VCS, но это не отменяет того, что их можно использовать в комбинации с пакетами).
Раньше мы использовали такую схему: на офисном сервере делали чекаут конкретной версии исходников, rsync-ом заливали код на все сервера и билдили демоны на каждой машине. Тогда боевые сервера были на Gentoo и такой метод был приемлем, хотя и вызывал более длительные выливки чем нам хотелось. Сейчас мы перешли на Debian и использовать его пакетную систему было логично. К слову раньше минимальная выливка занимала около полу часа (пока зальются все изменения, пока соберется код). Теперь все пакеты загружены на сервер до выливки. Админ вызывает apt-get install, рестартует демоны и проводит небольшую проверку. Это занимает отсилы 5 минут.
А пулить код с боевого сервера не такая уж и хорошая идея. Недавняя история с уязвимостю с svn подтверждает это. Лучше пушить код на сервер, который ничего не знает о сервере, где код хранится. Но это сугубо моё личное мнение.
У нас как раз пакет собирается на локальной машине с Ubuntu, а заливается на офисный сервер с Ubuntu Server и на площадку на Debian Lenny.
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
Можно попробовать использовать git svn, но я не использую там теги — поэтому не знаю получится ли залить их в svn.
В крайнем случае можно использовать номер ревизии с git-svn-id, а версию делать 1.0.НОМЕР_РЕВИЗИИ
По этим ссылкам недавно обучался один знакомый с нуля.
Туториалы на английском
Большая статья на gamedev.net (перевод, но тут говориться про lua 4.0.1 — а с тех пор язык достаточно изменился, но для начала можно почитать)
Поясню, что имею ввиду: хранить бинарники в vcs не очень хорошая идея, но иногда нет выхода. К примеру это может быть файл с ресурсами для флешки, картинки или схожие ресурсы у которых нету текстовых исходников.
Так вот, если разработка svn-like — то проблемы особо нет — ктото предупреждает остальных, что файл будет им изменен, меняет, заливает и освобождает этот ресурс. Но вот в случае если в мастер принимаются патчи и мёржатся одним человеком — пока он не смержит изменения — никто не может менять файл.
Я вижу пока только 2 варианта — не хранить файлы в vcs, но тогда дополнительно надо иметь доступ к хранилищу этих файлов (samba, NFS), а также у них не будет исптории. Или хранить в отдельном репозитории с svn-like подходом.
А в ядре, насколько я знаю, в основном пулят, а не пушат изменения.
В принципе если работа происходит в офисе и у суперразработчика есть доступ на все машины по ssh — то можно пулить в свой репозиторий прямо с персональных репозиториев;)
Но если в комманде есть редиска, который ходит на работу с ноутбуком — то всё становится тяжелее;)
Лучше всё-таки просматривать код до коммита (git add -p, git gui). В крайнем случае — git status + git diff + git commit -a.
можно. используя pre-receive хук:
#!/bin/sh while read a; do branch=`echo $a | cut -d" " -f3` if [ $branch == "refs/heads/master" -o $branch == "refs/heads/stage" ]; then username=`whoami` if [ $username != 'superuser1' -a $username != 'superuser2' ]; then echo "* You not authorized to commit to $branch branch!!! *" 1>&2 exit 1 fi fi doneТакже можно отослать себе email — с нотификацией, что кто-то хотел залиться в мастер.
git rerere — позволяет записывать решение конфликтов и при повторном мерже использовать их. Помогает в случае если бранч живет долго и часто возникает необходимость мержится с другими бранчами. Включается просто: git config --global rerere.enabled 1
И git rebase --onto. Позволяет перенести ветку с одним основанием на другое. Когда полезно: Есть мастер в котором происходит активная разработка. В определенный момент был начат бранч с новой независимой фичей, но от текущего мастера. Фича сделана и в принципе может быть внесена в стабильную ветку, но из-за того что она была начата на от стабильной ветки, при обычном мерже потянет за собой коммиты, которые не должны попасть в стабильную версию. На выручку приходит git rebase --onto, который позволяет создать ветку которая будет начинаться от стабильной версии и содержать все коммиты, которые были сделаны в ветке от мастера.
но иногда закапываешься в какую-то проблему, попутно исправляешь какие-то баги — в итоге в файле накапливаются изменения не связаные друг — с другом.
в таком случае лучше закоммитить по ханкам — всё что относится к одной фиче — в один коммит, что к другой — в другой коммит.
кроме того, очень полезная комманда: git cherry-pick. использовать можно так — есть бранч, в котором новая фича и его нельзя пока мержить в мастер. Но там попутно исправлено пару багов, а вас просят влить эти исправления в мастер. Делается в бранче сделаном от мастера
git cherry-pick BUGFIX_COMMIT_SHA1
и не надо заново вносить изменения или как-то менять историю (в этом случае вы подумаете, что «как хорошо, что я дулал коммиты атомарными и этот багфикс не тянет за собой кучу изменений связаных с новой фичей»)
Чтоб не вводить пароль каждый раз при коннекте к серваку (ключь без пароля не следует использовать) можно использовать ssh-agent.
Скорее всего при старте иксов он уже запущен и достаточно сделать
И ввести ключик один раз. Далее пока жив терминал в котором введена комманда — пароль к ключу спрашиваться не будет.
Если же ssh-add говорит, что агент не найден — смело делаем
А внутри запущенного шела — пишем — ssh-add.
Ну а ещё полезнее фича называемая — SSH-Forwarding.
Она позволяет использовать агент на машине пользователя при коннекте к группе серверов. Тоесть зашел на один сервер, а с него без ввода пароля и пароля к ключу — простой коммандой ssh hostname — перейти на другой сервер.
Скоммандлайна надо использовать
Ну а лучше в конфиге клиента ssh (/etc/ssh/ssh_config) прописать
Спасибо за хинт по TortoiseGit. Может он поможет перевести всех девелоперов только на git.
Чуть больше года назад имел опыт перевода комманды с svn на git. Линуховая часть довольно легко приспособилась, а вод с виндузятниками были большие проблемы (использовали msysgit, скорость и стабильность которого оставляли желать лучшего). Тогда ещё не было TortoiseGit, хотя я его искал;)
Сейчас виндузятники на svn, а линуксоиды на git. Самописным скриптом общие части репозитория синхронизируются в обе стороны (с использованием git-svn, но так чтоб история в основном гитовом репозитории не выпрямлялась).
1. git/svn/hg/… — для контроля версий
2. deb/rpm/… — для хранения бинарных данных, трекинга зависимостей, менеджмента версий средствами ОС
3. capistrano/vlad the deployer/… — для автоматизации работы на нескольких серверах, автоматизации выливки и отката изменений и тд.
Для простого сайта на одном сервере, выливка на который сводится только к обновлению версии кода, вполне подойдет использование сугубо vcs.
Для сайта на одном-двух серверах, который состоит из нескольких модулей и сложными зависимостями на установленые приложения (либо включает в себя компоненты на с/c++, которые должны быть собраны в бинарники) — оптимальным будет использование пакетов, так как часть работы ложится на пакетный менеджер ОС.
Для развернутых на большом числе машин и сложной системой развартывания — лучше использовать специальные системы деплоя типа capistrano. Причем можно использовать в комбинации как с vcs, так и с теми же пакетами.
У меня мало опыта работы с системами автоматического деплоя, но есть планы по внедрению capistrano в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
Используя пакеты вместо VCS облегчается сама выливка. И её может проводить не программист, а админ (который умеет работать с пакетной системой и не хочет знать что такое код и как его выливать).
Для выливок сугубо скриптовой части, в принципе, подойдут и Capistrano, Vlad the Deployer и похожие утилиты (они могут забирать исходики с VCS, но это не отменяет того, что их можно использовать в комбинации с пакетами).
Раньше мы использовали такую схему: на офисном сервере делали чекаут конкретной версии исходников, rsync-ом заливали код на все сервера и билдили демоны на каждой машине. Тогда боевые сервера были на Gentoo и такой метод был приемлем, хотя и вызывал более длительные выливки чем нам хотелось. Сейчас мы перешли на Debian и использовать его пакетную систему было логично. К слову раньше минимальная выливка занимала около полу часа (пока зальются все изменения, пока соберется код). Теперь все пакеты загружены на сервер до выливки. Админ вызывает apt-get install, рестартует демоны и проводит небольшую проверку. Это занимает отсилы 5 минут.
А пулить код с боевого сервера не такая уж и хорошая идея. Недавняя история с уязвимостю с svn подтверждает это. Лучше пушить код на сервер, который ничего не знает о сервере, где код хранится. Но это сугубо моё личное мнение.
А какие преимущества он даст (ну окромя автоматической генерации зависимостей пакета)?
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
В крайнем случае можно использовать номер ревизии с git-svn-id, а версию делать 1.0.НОМЕР_РЕВИЗИИ