На ruby писать приятно тем, что его текст легко читается и понимается другими программистами. Но это заслуга не столько ruby, сколько пишущего программиста, и к сожалению, так писать получается не всегда.
Поэтому приходится придерживаться правила:
Как только вы встречаете программный код, на понимание которого затратили какое-то время, сэкономьте это время коллегам: или перепишите понятнее или просто прокомментируйте.
В комментарии интересует не столько ЧТО делает код, но КАК он это делает.
В продолжении этой темы http://dapi.ru/git-branching-tags-git расскажу подробнее как создаются ветки по задачам в нашей команде.
Как показала практика переход на git затруднителен для разработчиков привыкших к subversion (svn), а тот, кто никогда ранее
не использовал системы контроля версий осваивается с git-ом за пару дней. Думаю что причина в том, что в svn все действия происходят с удаленным репозиторием, а git никак не привязан у удаленному репу. Сам каталог проекта (с подкаталогом .git в корне) является полноценным репозиторием, с ним и происходит вся работа. При этом на удаленном (тот, что на github) например могут происходить совершенно независимые вещи – ветки переименоваться илди удалиться и ваш локальный репо ничего об этом не будет знать. И не должен. В этом его преимущество – в не зависимости. Да, когда клонируете проект через git clone REPO_NAME git сохраняет в конфиге (.git/config) название склонированного источника и для краткости называет его origin. Это все что вас связывает с удаленным репом. Команды для работы с удаленным репом всего две:
> git pull origin ВЕТКА # влить последние комиты из ветки ВЕТКА репозитория origin в текущую > git push origin ВЕТКА # затолкнуть последние изменения в текущей ветке в ветку ВЕТКА репозитория origin
На самом деле команда git pull является комбинацией git fetch + git merge но это не столь важно.
http://help.github.com/linux-set-up-git/
Также сделайте (ниже написано зачем)
> git config --global push.default current
http://help.github.com/set-your-user-name-email-and-github-token/
git status должен возвращать что-то типа:
# On branch master nothing to commit (working directory clean)
Заметьте что мы находимся в ветке (branch) master. Если это не так, нужно в нее перейти:
> git checkout master
Убедимся/Вольем в эту ветку все изменения с сервера (github)
> git pull
Вообще master это ветка с которой начинаются разработка всех задач. В тоже время
сами разработчики в master никогда ни чего не заливают (за исключением
исключительных ситуаций), а все свои наработки кладут в ветки с понятными
названиями вида ИМЯ-НОМЕР_ТИКЕТА-КРАТКОЕ_ОПИСАНИЕ_ТИКЕТА. Например:
dapi-123-caching-subcribers. По названию ветки понято, что ее автор dapi и
работает он над issue 123, а именно над кешированием подписчиков.
> git checkout -b dapi-123-caching-subscribers Switched to a new branch ' dapi-123-caching-subscribers'
Мы создали новую ветку, которая один в один master.
Кодируем, меняем файлы.
Когда мы понимаем что, возможно задачу еще до конца не выполнили, но сделали важный участок кода, который уже работает и хотим сохранить свои изменения (на случай чтобы откатиться к ним, при необходимости, позже) делаем так:
> git add ИМЕНА_ФАЙЛОВ
То есть выводим на сцена (другими словами добавляем к текущему комиту) те файлы, изменения в которых хотим запомнить. Ну если хотите запомнить все, пишите:
> git add .
Далее делаем собственно коммит с понятным сообщением (заметьте, это не описание, не название, а именно сообщение другим разработчикам о том что делает этот коммит). Так как мы используем github issues, а они умеют читать ваши commit-messages то в сообщениям мы вставляем информацию помогающую соотносить их с этими issues. например:
> git commit -m "#123 Сделал кеширование"
Где #123 – номер issue. В случае если вы делаете завершающий коммит, сообщение может быть вида “Fix #123” или “Closed #123” (вообще любое из слов close, closes, closed, fixes, fixed) в таком случае issue под номером 123 автоматически закроется. Также вставка номеров задач в коммиты позволяет отображать на странице issues именно тот код, который отвечает за решение определенной задачи. Подробнее о том как github issues читают commit messages тут https://github.com/blog/411-github-issue-tracker
Если это ваши не последние изменния, то вы снова переходите к пункту 3, если последние, то идем дальше.
Често говоря это можно делать после каждого комита.
> git push -u
Ключил -u нужен для того чтобы локальная ветка связалась с удаленной ( см .git/config) и при последующем git pull вам не нужно было ее указывать снова.
Конфликт при пушинге означает что вы делаете что-то не то (пушаете не ту ветку не туда)
В какой-то момент вы понимаете что ваша ветка далеко убежала от master-а. Да и master уже не тот и появляется желание влить к себе изменения, который в нем произошли. Правильное ощущение, чем чаще его делать тем меньше будет проблем. Делается это так:
> git checkout master > git pull > git checkout ВАША)ВЕТКА > git rebase master
другой вариант:
> git pull --rebase origin master
Ваша рабочая ветка началась с мастера. Место начала называтеся HEAD. При ребейсе вы переносите ваш HEAD на последний комит в master.
Если в процессе мержинга у вас возник конфликт с которым вы не можете разобраться и хотите вернуть все назад:
> git merge --abort
или
> git reset --hard HEAD
Так же тут хорошие рекомендации на эту тему: http://stackoverflow.com/questions/101752/aborting-a-merge-in-git
Если в результата отката мержинга осталось много untracked files разобраться с ними поможет git clean:
> git clean -f
Лучше сначала запустить ее в сухую с параметром -n чтобы посмотреть что она собирается удалить.
Инфа по очистке http://stackoverflow.com/questions/61212/how-do-you-remove-untracked-files-fr...
Дальше у нас два варианта действий. Или мы начинаем делать новую задачу, для этого снова возвращаемся в master и т.д. все с 1-го пункта. Или вносим изменения в уже существующие задачи (ветки). Тогда вместо мастера берем их. Например нам надо поработать над старой задачей #001 (user authorization)
> git checkout dapi-001-user-authorization
Господа виндузятники, у вас скорее всего не настроено определение веток по-умолчанию, поэтому вместо
git pull; git push
нужно делать
git pull origin; git push origin
А иногда и указывать конкретную ветку, типа
git pull origin master
Чтобы этого не делать выполните:
> git config --global push.default current
Способ перейти в ветку скачав ее с сервера:
> git checkout -b ВЕТКА origin/ВЕТКА
Презентации с исчерпывающей информацией по rspec-у. Их удобно использовать как шпаргалки.
Мы также используем factory_girl, но старайтесь использовать мокинг вместо факторинга.
Во-первых такие тесты выполняются быстрее, а так как полный комплекс можно запускать по несколько раз в час, ждать 1 минуту вместо 10 гораздо приятнее. Во-вторых мокинг подразумевает что вы укажете через stub или should_receive все ожидаемые вызовы, а значит ваш тест будет более понятен как спецификация и более исчерпывающий как тест.
bdd подразумевает что вы сначала напишите спецификацию, а потом будете писать код. Прелесть в том, что эта спецификация является еще и тестом. Писать сначала спек, а потом код важно, потому что таким образом мы сначала задумываемся а что жы мы хотим сделать, какой метод имплементируем сначала, что он будет принимать и что делать с остальными объектами, а потом уже реализовывать это. Такой подход оправдывает затраты на написание спека, так как значительно снижаются затраты на написание кода – он получается более обдуманным.
Открытие
На маяке тикеты лучше открывать сразу как только вы их начинаете делать или приняли твердое решение что начнете кодить, а пока обдумываете. Так как не открытый тикет, даже если он назначен кому то могут и утащить, если он имеет важное значение для другой текущей задачи. В тоже время держать несколько открытых тикетов не этично. Сначала доделайте один, потом беритесь за другой.
При открытии на зебываем установить response на себя и конечно же поставит статус open.
Закрытие
После исполнения тикета ему ставится статус resolved. Далее мастер проекта после проверки кода или снова его откроет с комментариями или поставит ему verified и лучше через комментарий в коммите.
Priprity
Приоритет это не важность задачи, это их порядок выполнения. Сначала выполняются high, затем medium и low. Если вы работаете над задачей low, а на вас повесили high, не нужно бросать передыдущую и браться за эту, доделайте сначала то, чо начали. Если задача действительно важна вам об этом сообщат отдельно.
Работа с git-ом
Маяк имеет хорошую поддержку коммитов git-а. Для того чтобы прямо а лайтхаусе можно было посмотреть коммиты по задаче и не искать их на github-е удобно указывать номер тикета прямо в коммите: git commit -m "[#123] внедрил модуль такой-то" С git-а удобно менять статусы тикета, например закрывать его: git commit -m "[#123 state:resolved] Исправил ошибку с инвайтами в IE"Комментарии лучше писать как можно более подробнее, так как git log является основным журналом проекта и остальные разработчики по нему судят о происшествиях с проектом, поэтому все затрагивающие работу других модулей изменения должны отражаться в комментариях.
Например: vasya/123-facebook-connect. Где vasya - ник-девелопера, а 123-номер задачи.
По окончанию разработки девелопер заливает свою ветку на guthub и делает pull request в develop.Далее мастер проекта осуществляет code review: по необходимости обсуждает ее с девелопером, возможно запрашивает доработку. Основная цель мастера включать в проект чистый, сходу понятный другим разрабтчикам код, снабженный тестами и, естественно, не ломающий остальные тесты проекта.
В общем перед тем как делать pull request убедитесь что все тесты проходят.После мержинга ветки в develop мастер ее удаляет с сервера.Неплохой туториал по git-у - http://githowto.com/
