Git

Графический редактор

Если вам приходится работать с интерфейсами, то без графического редактора не обойтись. Он поможет нарисовать кнопку или открыть PSD-макет страницы.

В нем можно обработать фотографию для фона или нарисовать какой-нибудь элемент интерфейса с помощью кистей или векторной графики. Также можно открывать макеты, работать со слоями и так далее.

Бесплатный аналог Photoshop. У него почти такой же, но менее проработанный функционал. Подойдет тем, кому нужен приличный редактор, но без наворотов и платной подписки.

Программа для работы с изображениями в системах Linux. У нее неплохой набор инструментов, которого вполне хватает среднему разработчику.

Есть как более простые, так и более продвинутые графические редакторы, но этих программисту хватит с лихвой.

Инструмент 3: Отслеживание ошибок

В Github центр для отслеживания ошибок — это issues. Несмотря на то, что они в основном предназначены для отслеживания ошибок, также полезно использовать «Issues» следующими способами:

• Ошибки: вещи, которые явно сломаны и нуждаются в исправлениях
• Особенности: Удивительные крутые новые идеи для реализации
• Список дел: контрольный список задач для завершения

Давайте рассмотрим некоторые особенности проблем:

1. Labels: цветные категории для каждого issue. Они полезны для фильтрации.
2. Milestones: они относятся к категориям, которые могут быть связаны с каждым issue, и полезны для определения того, какие проблемы необходимо обрабатывать для следующего релиза. Кроме того, поскольку этапы связаны с проблемами, то автоматически обновляется индикатор выполнения при закрытии каждой связанной проблемы.
3. Search: Автокомплит поиска для issues и milestones
4. Assignment: каждый вопрос может быть назначен ответственному лицу для исправления проблемы. Еще одна полезная функция — посмотреть, над чем мы должны работать.
5. Автоматическое закрытие: сообщения в коммитах вида  автоматически закроют issue.
6. Mentions: каждый может оставить примечание, просто указывая в своих сообщениях. Поскольку номера issue являются гиперссылками, это позволяет легко упоминать связанные issue во время обсуждения.

5 систем контроля версий с открытым исходным кодом

CVS

CVS является самой популярной и широко применяемой системой контроля версий на сегодняшний день. После выпуска в 1986 году она быстро стала общепринятым стандартом. CVS приобрела популярность благодаря простой системе поддержки файлов и ревизий в актуальном состоянии.

Существует ряд IDE для CVS, включая Xcode (Mac), Eclipse, NetBeans и Emacs.

Достоинства

• Это проверенная временем система, которая используется более трех десятилетий;
• Существует много IDE, которые используют CVS.

Недостатки

• Перемещение или переименование файлов не включается в обновление версии;
• Предоставление символических ссылок на файлы связано с некоторыми рисками безопасности;
• Отсутствие поддержки атомарных операций может привести к повреждению исходного кода;
• Медленные операции установления меток и ветвления;
• Слабая поддержка двоичных файлов.

SVN

Еще одна распространенная система управления версиями. Большинство проектов с открытым исходным кодом и крупные платформы, такие как Ruby, Python Apache, используют SVN. Из-за огромной популярности существует множество версий и доступных IDE.

Достоинства системы контроля версий SVN

• Новая и значительно улучшенная система, основанная на CVS;
• Допускает атомарные операции;
• Операции в ветке проекта малозатратны;
• Доступны различные плагины IDE.

Недостатки

• Выдает ошибки при переименовании файлов и каталогов;
• Недостаточно команд для управления репозиторием;
• SVN работает медленнее по сравнению с другими системами управления версиями.

GIT

Благодаря распределенной форме управления без необходимости использования оригинального программного обеспечения многие проекты с открытым исходным кодом предпочитают Git.

Достоинства

• Почти все отрицательные черты CVS/SVN устранены;
• Высокая скорость работы распределенной системы контроля версий;
• Легкость проведения различных операций с ветками проекта;
• Пользователи могут получить доступ к полному дереву истории в режиме офлайн;
• Предлагает высоко распределенную одноранговую модель.

Недостатки

• Высокий порог вхождения для пользователей SVN;
• Ограниченная поддержка Windows по сравнению с Linux.

Mercurial

Считается эффективной для крупных проектов, в которых участвует много разработчиков и проектировщиков. Mercurial – это высокопроизводительная система, предлагающая оптимальную скорость. Она также известна своей простотой и подробной документацией.

Достоинства Mercurial системы контроля версий

• Низкий порог вхождения по сравнению с Git;
• Подробная документация;
• Распределенная модель;
• Высокопроизводительная система с отличной скоростью.

Недостатки

• Нельзя объединить две родительские ветки;
• Основана на расширениях, а не сценариях;
• Недостаточно гибкая, чтобы выполнять операции по умолчанию.

Bazaar

Уникальна тем, что может использоваться с распределенной и централизованной базой кода. Это делает ее универсальной системой контроля версий. Кроме этого Bazaar позволяет использовать детальный уровень управления. Ее можно легко развернуть в самых разных сценариях, что делает ее адаптивной и гибкой для всевозможных проектов.

Достоинства

• Идеально подходит для разнообразных проектов;
• Предоставляет гораздо более продвинутый набор команд и поддержку IDE;
• Включает в себя настраиваемый набор функций, который подходит для разнообразных проектов.

Недостатки

• Является новой и недостаточно проработанной системой управления версиями;
• Отсутствует поддержка IDE.

Что касается популярности, порога вхождения, производительности и адаптивности, рассмотренные в этой статье системы контроля версий существенно превосходят другие.

Пожалуйста, оставляйте свои отзывы по текущей теме материала. Мы очень благодарим вас за ваши комментарии, отклики, лайки, дизлайки, подписки!

Пожалуйста, оставляйте ваши отзывы по текущей теме материала. Мы очень благодарим вас за ваши комментарии, дизлайки, лайки, отклики, подписки!

МЛМария Логутенкоавтор-переводчик

Просмотр истории коммитов

Не все коммиты будете делать вы, какие-то будут делать ваши коллеги по команде, поэтому вам может понадобиться изучить историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда .

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда имеет очень большое количество опций для поиска коммитов по разным критериям.

Одним из самых полезных аргументов является или , который показывает разницу, внесенную в каждый коммит. Можно ограничить количество записей в выводе команды, используя параметр :

Как делить на коммиты

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

Ревью

Вы решили исправить баг, но внезапно оказалось, что ругается линтер из-за слишком длинной строчки. Вы решили переименовать переменную, так как её название было излишне длинным. Тут возникает соблазн сделать все одним коммитом. Но ревьюверам такой merge request с одним коммитом будет очень сложно смотреть, так как из сотен строк, которые просто переименовывают переменную, нужно будет отыскать пару-тройку строк, которые действительно исправляют логику. В идеале это надо оформить в виде двух коммитов — первый переименовывает, второй — исправляет баг. Но вообще удобнее, если баг чинится одним коммитом.

Перенос изменений

В процессе реализации новой фичи вы нашли серьезный баг в безопасности. Не дожидаясь конца отладки новой фичи вы исправили этот баг, после доделали фичу и сделали коммит. И вот так лучше не делать, так как правку серьезного бага скорее всего захотят влить и в старые ветки уже выпущенных релизов или побыстрее влить в мастер в случае облачного продукта. А с фичами спешки скорее всего нет. Если все сделать в одном коммите, то придется вместе с фиксом бага обязательно вливать новую фичу, которая потребует провести полный цикл тестирования.

Декомпозиция

Вам поручили сделать новую фичу, и пусть это даже новый небольшой микросервис в отдельном репозитории. Но все мы люди, и выдать за один раз кусок кода размером в 5000 строчек мало кому под силу. Так что несмотря на то, что с точки зрения менеджеров это одна задача, вам будет удобнее эту задачу декомпозировать:

1. Добавить шаблон микросервиса.

2. Добавить пару базовых методов и работу с базой.

3. Добавить взаимодействие с сервисом X.

4. Добавить еще методов.

5. Добавить обработку каких-то сложных случаев и дополнительных параметров в первые два метода.

6. …

Можно конечно все это сделать одним коммитом. Но скорее всего за один день это сделать не получится, так что встанет вопрос о сохранении промежуточной работы. Во-вторых, начальник захочет отслеживать ваш прогресс и если делаете отдельными коммитами — это будет гораздо проще. Да и самому удобно наметить какой-то план работы и на каждый пункт этого плана делать коммит.

Бывают ситуации, когда вы вошли в раж и починили три бага и реализовали пару фич и только потом вспомнили, что эти изменения надо еще и куда-то послать. В этом случае поможет интерактивный коммит. Подробно останавливаться на нем не буду, так как иначе статья получится слишком большая. Запускается командой:

Позволяет добавить в разные коммиты даже изменения в одном файле.

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

• fix compilation

• fix tests

• fix linter

Это коммиты, которые чинят предыдущие коммиты в этой же серии. Никому не интересен тот факт, что вы при написании кода допустили ошибку и сразу же её исправили, интересен только конечный результат. Всё это лучше проверить и исправить до того, как будет сделан коммит. Если забыли и закоммитили а оказалось, что тесты не проходят, то от таких коммитов надо избавляться. Каким образом — в следующей главе.

Использование Github не для разработки

Большинство думает использовать Github только для программных проектов. В конце концов, Github был создан специально для создания кода. Но есть некоторые классные репозитории Github, которые используются для проектов, не связанных с кодом, и они были одинаково великолепны для сотрудничества и обсуждения. Поскольку эти проекты также доступны с открытым исходным кодом, и каждый может внести свой вклад, быстро исправлять ошибки, легко сообщать об ошибках и эффективно сотрудничать с единомышленниками. Просто ради интереса, вот некоторые из них:

• Исправления для дома: отслеживание проблем в качестве инструмента мониторинга
• Книги: Маленькая книга по MongoDB, Основы Backbone
• Тексты песен: JSConfEU Тексты песен
• Найти друга: boyfriend_require
• Наставничество: Wiki
• Геномические данные: эпидемия Ash Dieback
• Блоги: CSS Wizardry

И интересно, что думает об этом команда Github?

Централизованные и распределенные системы контроля версий

Системы контроля версий можно разделить на две группы: распределенные и централизованные.  

Централизованные системы контроля версий

Централизованные системы контроля версий представляют собой приложения типа клиент-сервер, когда репозиторий проекта существует в единственном экземпляре и хранится на сервере. Доступ к нему осуществлялся через специальное клиентское приложение. В качестве примеров таких программных продуктов можно привести CVS, Subversion.

CVS (Concurrent Versions System, Система одновременных версий) одна из первых систем получивших широкое распространение среди разработчиков, она возникла в конце 80-х годов прошлого века. В настоящее время этот продукт не развивается, это в первую очередь связано с рядом ключевых недостатков, таких как невозможность переименования файлов, неэффективное их хранение, практически полное отсутствие контроля целостности.

Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительным шагом вперед по сравнению с CVS. 

Распределенные системы контроля версий

Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

Большое преимущество такого подхода заключается в автономии разработчика при работе над проектом, гибкости общей системы и повышение надежности, благодаря тому, что каждый разработчик имеет локальную копию центрального репозитория. Две наиболее известные DVCS – это Git и Mercurial.

Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные , используют свои VCS.

Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git.

Особенности системы Git

Главной особенностью Git, заметно отличающей её от многих других СКВ является то, что она позволяет скопировать хранилище проекта со всей историей изменений и информацией об этих изменениях и работать с проектом отдельно. Git не имеет единого централизованного хранилища, но при этом эффективно отслеживает и контролирует и облегчает работу над проектом.

Благодаря возможностям Git можно, скопировав проект к себе на локальную машину, сколько угодно и как угодно вносить в него изменения в процессе работы над ним. В итоге, когда нужно будет объединить результаты работы (в том числе и от других разработчиков) в независимый общий проект, Git легко с этим справится. В случае сложных коллизий всегда можно вернуть предшествующее состояние проекта вне зависимости от того, сколько и каких было сделано изменений и итераций разработки. Хотя такие ситуации довольно редки в силу продуманной логики работы Git.

Ещё одним достоинством Git является интеллектуальная система сжатия данных, позволяющая существенно экономить на затратах для хранения истории изменений. Поскольку Git очень эффективно отслеживает и объединяет изменения даже из локальных хранилищ, это даёт возможность использовать эту систему не только для разработки (для чего она изначально была разработана), но и для задач по системному администрированию.

Commit message

Написать хороший заголовок лучше чем ничего (то есть плохой заголовок). Но если в проекте много участников, сформировалась значительная кодовая база и проект планируется поддерживать еще долгое время (больше полугода). То нужно писать и тело commit message.

Основное правило — не нужно писать, что делает коммит, нужно писать, для чего он это делает. То есть если это фикс бага — конкретно о том, что это фикс бага будет указано в заголовке. А в теле коммита нужно поподробнее описать, что это за баг, когда он проявляется и, самое главное, почему ваши правки в коде этот баг исправляют.

Ссылки не должны заменять текст коммита. Если баг описан в жире, то вместо того, чтобы просто вставлять ссылку на жиру, надо кратко пересказать, что там написано, прямо в теле commit message.

По оформлению: не следует писать все в одну строку, желательно переносить по границе 72 символов. Так же следует использовать повелительное наклонение в предложениях, где описано, что делает этот коммит.

Пример хорошего commit message (из проекта libvirt):

Откат и сброс изменений в GIT

Если вы запороли проект, но еще не сделали commit, то сбросить изменения можно командой

git reset --hard HEAD

например создадим файл bad.txt

$sudo touch bad.txt
$git add bad.txt

Теперь удалим изменения

git reset --hard HEAD
HEAD is now at 825d300 Added readme.txt file

git сообщил нам что мы вернулись к коммиту «Added readme.txt file». Если теперь проверить директорию с помощью команды

ll | grep bad.txt

Мы увидим что файла bad.txt нет.

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

git reset --hard HEAD~3

Отменит 3 последних коммита.

Если вы просто хотите восстановить только один единственный файл, предположим hello.rb, то выполните git checkout

$ git checkout -- hello.rb
$ git checkout HEAD hello.rb

Первая команда восстановит hello.rb до версии хранящейся в индексе, и команда «git diff hello.rb» не покажет отличий. Вторая команда восстановит hello.rb до версии в ревизии HEAD, таким образом обе команды «git diff hello.rb» и «git diff —cached hello.rb» не покажут отличий.

Коммиты

Коммит в git репозитории хранит снимок всех файлов в репозитории. Почти как огромная копия, только эффективнее.

Git пытается быть лёгким и быстрым, так что он не просто слепо копирует весь проект каждый раз, а ужимает коммит в набор изменений или «дельту» между текущей версией и предыдущей. Это позволяет занимать меньше места.

Также Git хранит всю историю о том, когда какой коммит был сделан и кем

Это очень важно, можно посмотреть из-за кого упал прод и навалять ему. Файлы в репозитории могут находиться в 3 различных “областях”

Файлы в репозитории могут находиться в 3 различных “областях”.

• HEAD
• Индекс
• Рабочий каталог

Наш проект сейчас пуст. Давайте создадим первый файл:

На данном этапе только область “Рабочий каталог” содержит данные.

Рабочий проект это ваша папка с файлами, в данном случае это . Две другие области сохраняют свое содержимое внутри каталога в понятном и удобном для git формате, но не понятном для человека. Рабочий Каталог распаковывает их в файлы, что упрощает для нас их редактирование.

Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед коммитом. На данном этапе вы можете в любой момент очистить все изменения и вернуться к последнему коммиту.

Сделаем снимок текущего состояния проекта, то есть сделаем коммит. Для этого необходимо сначала добавить содержимое “Рабочего Каталога” в Индекс. Индекс — это черновик коммита. Только файлы из индекса попадают в коммит.

Без добавления файла в Индекс у нас не получится создать коммит, проверьте это сами:

Для добавления в Индекс используется следующая команда:

Когда у вас много файлов, вы можете добавить их все разом .

Теперь сделаем наш первый коммит, выполнив команду . Тем самым мы сохраним содержимое Индекса как неизменяемый снимок в области . Хорошей практикой считается коротко описать, что было изменено, для этого используется флаг :

Все, коммит готов. И файл попал в область . будет родителем следующего созданного коммита. Как правило, самое простое считать снимком вашего последнего коммита. Возможно пока не совсем понятно что такое , но о нем мы еще поговорим.

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

Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.

Теперь посмотрим, какие изменения произошли в git:

Нам подсказывают, что изменения не попадут в коммит, пока мы не сделаем . Выполним эту комманду чуть позже, пока добавим новый файл:

Еще раз проверяем статус репозитория:

Новый файл появился в списке не отслеживаемых, то есть в Рабочем Каталоге. Давайте добавим в отслеживание этот файл, а так же измененный ранее.

Теперь у нас есть изменения, которые будут включены в коммит. Значит можно сделать второй коммит:

Я уже упоминал, что у коммитов есть родитель, который указывает на предыдущий коммит. Из таких цепочек складывается “ветка”. О ветках мы поговорим в следующей статье. Пока достаточно знать, что по умолчанию у нас уже есть ветка .

Для удобства восприятия визуализируем наши коммиты. Кружочки это коммиты, а стрелочки между ними указывают на родителей.

Отмена нескольких коммитов

С помощью вы можете вернуться к любой предыдущей фиксации.

Например, чтобы переместить текущую ветку на три коммита назад, вы должны использовать:

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

Другой способ вернуться к конкретной фиксации — передать идентификатор фиксации команде .

Используйте чтобы найти идентификаторы фиксации:

Команда отобразит список всех коммитов, включая идентификатор и первую строку сообщения о фиксации:

Как только вы узнаете идентификатор коммита, на который хотите выполнить сброс, просто передайте его в команду :

Навигация

Прежде чем перейти к более продвинутым фичам Git, важно понять различные способы перемещения по коммитам вашего проекта

Detaching HEAD

Давайте разберемся, как нам откатиться к более старой версии нашего репозитория.

У git есть указатели на коммиты, своеобразный ярлыки (бирка), которые перемещаются от коммита к коммиту. Одним из таких ярлыков-указателей является .

— это символическое имя текущего выбранного коммита. По сути это, тот коммит, над которым мы в данным момент работаем.

Указатели могут ссылаться на другие указатели, обычно указывает на имя ветки. Но это можно изменить, например указать hash нужного коммита, чтобы откатиться к нему.

Создадим еще один файл и сделаем третий коммит:

Мы видим, что сейчас указывает на , это тоже указатель, обозначающий ветку. То есть указывает на , который в свою очередь указывает на коммит . Отделение (detaching) означает лишь присвоение его не ветке, а конкретному коммиту.

Представим, что нам надо посмотреть, как выглядел наш репозиторий после второго коммита. Для этого используем команду и хэш второго коммита. Кстати, можно не указывать его целиком, достаточно первых 5 символов.

Таким образом мы переключились на состояние второго коммита, в котором у нас еще не было файла , проверим это:

Вызвав видим, что теперь указывает на второй коммит:

При этом мы не потеряли третий коммит и все изменения в нем, можем убедиться в этом с помощью следующей команды:

Вернем указатель на :

Относительные ссылки

Передвигаться по коммитам при помощи указания хешей неудобно. Поэтому Git поддерживает относительные ссылки. С относительными ссылками можно начать с какого-либо удобного места и двигаться от него.

Относительные ссылки — мощный инструмент, но мы разберем два простых способа использования:

• Перемещение на один коммит назад
• Перемещение на коммитов назад

Для начала рассмотрим оператор каретки Когда мы добавляем его к имени указателя, Git воспринимает это как команду найти родителя выбранного коммита. Так что означает “первый родитель ветки main”. означает прародитель (родитель родителя) .

Давайте переключимся на коммит выше :

Да, мы снова попали на второй коммит, то есть сейчас вновь указывает на второй коммит.

Может показаться, нужно еще раз вызвать команду , чтобы попасть на первый коммит. Но это не так, указатель остался на третьем коммите, мы сдвинули . Поэтому запросит снова родителя третьего коммита.

Чтобы попасть на первый коммит, можно использовать указатель . Попробуем перейти к первому коммиту:

Вернемся на третий коммит:

Оператор Предположим, нужно переместиться на много шагов назад. Было бы неудобно печатать несколько раз, так что Git поддерживает также оператор тильда .

Опционально к тильде можно добавить количество родительских коммитов, через которые нужно пройти. Посмотрим, как это работает.

Мы переместились на первый коммит. Вернемся:

Github разработка в команде

В этом руководстве предполагается, что вы уже знакомы с Git, распределенной системой управления версиями с открытым исходным кодом, созданной Линусом Торвальдсом в 2005 году. Если вам нужна ревизия или поиск в Git, посетите наш предыдущий курс скринкастов или даже несколько статей на эту тему. Кроме того, у вас уже должна быть учетная запись Github, а также некоторые базовые функции, такие как создание репозитория и внесение изменений в Github. Если нет, обратитесь к предыдущим учебникам.

В мире разработки при создании своего проекта работа в команде будет неизбежной. В этом руководстве по совместной разработке на Github мы изучим некоторые из наиболее распространенных инструментов, которые нам обычно нужны при работе с командами разработчиков программного обеспечения. Обсуждаемые инструменты:

1. Добавление членов команды — организация и соавторы
2. Pull Requests — Отправка и слияние
3. Отслеживание ошибок — issues Github
4. Аналитика — Графики и сети
5. Управление проектами — Trello & Pivotal Tracker
6. Непрерывная интеграция — Travis CI
7. Ревью кода — комментарии к строкам и URL-запросы
8. Документация — Wiki & Hubot