Использование систем контроля версий

Введение в систему контроля версий в IntelliJ IDEA

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

В этой главе также будет представлено введение в систему контроля версий в IntelliJ IDEA, и мы начнем рассматривать некоторые из её удобных настроек. Надеюсь, вы сможете оценить элегантность IntelliJ IDEA с момента изучения этой главы.

> * Многие люди считают, что IntelliJ IDEA включает в себя инструменты контроля версий, такие как SVN или Git, и что установка IntelliJ IDEA обеспечивает полное использование всех функций системы контроля версий. Это совершенно неверное понимание. IntelliJ IDEA включает поддержку этих систем контроля версий в виде плагинов, но установка соответствующего клиента системы контроля версий всё равно требуется.

• Как показано на рисунке 1, поддержка систем контроля версий в IntelliJ IDEA реализуется в виде плагинов. Версия для профессионалов по умолчанию поддерживает наиболее популярные системы контроля версий: CVS, Subversion (SVN), Git, ClearCase, Mercurial, Perforce, TFS. Поскольку многие люди используют GitHub для совместной работы или управления версиями проекта, IntelliJ IDEA также включает в себя плагин для GitHub, что облегчает checkout и управление вашими проектами на GitHub.## Настройка SVN

Чтобы использовать SVN в IntelliJ IDEA, вам нужно установить клиент SVN или графический инструмент, такой как TortoiseSVN. Для Windows рекомендуется установить TortoiseSVN, так как это позволяет удобно управлять проектами даже без использования IntelliJ IDEA.

Основные версии SVN, которые используются, включают 1.6, 1.7, 1.8, а самая новая версия — 1.9. Рекомендуется использовать версию 1.8. Если ваш проект использует версию 1.6, вы можете обновить проект до версии 1.8 без каких-либо проблем, поэтому не стоит беспокоиться.

• Скачивание Subversion с официального сайта: https://subversion.apache.org/download/#recommended-release
• Скачивание TortoiseSVN с официального сайта: http://tortoisesvn.net/downloads.zh.html

> * Как показано стрелкой на рисунке выше, по умолчанию при установке TortoiseSVN не устанавливается command line client tools. Здесь рекомендуется выбрать этот пункт.

• Как показано на рисунке выше, отметка 1 указывает на выбор Use command line client.
• Как показано на рисунке выше, отметка 2 рекомендует выбрать путь к svn в соответствии с фактическим путем после установки, иначе IntelliJ IDEA может не распознать его и выдаст ошибку: Cannot run program "svn".
• Как показано на рисунке выше, отметка 3 указывает на возможность очистки кэша при возникновении различных проблем с SVN.По моему опыту использования, работа с SVN в IntelliJ IDEA не всегда приятна, по крайней мере, она менее удобна, чем Git, и часто возникают проблемы. Поэтому здесь я предупреждаю вас об этом. В случае экстренной ситуации, когда IntelliJ IDEA не может обновлять или отправлять изменения, используйте TortoiseSVN.

Настройка Git

Для использования Git в IntelliJ IDEA необходимо установить клиент Git. Рекомендуется установить версию с официального сайта.

Основные версии Git включают 1.X, 2.X, самая новая — 2.X. Выбор версии произвольный, но не стоит выбирать слишком новую версию, так как это может привести к несовместимости с более старыми версиями IntelliJ IDEA.

• Скачивание Git с официального сайта: http://git-scm.com/
• Скачивание TortoiseGit с официального сайта: http://download.tortoisegit.org/tgit/

Как показано на рисунке выше, отметка 1 указывает на проверку наличия исполняемого файла по указанному пути.

Настройка и использование GitHub

• Как показано на рисунке выше, отметка 1 указывает на ввод вашего логина и пароля GitHub для проверки подключения.

• Как показано на рисунке выше, отметка 1 указывает на возможность клонирования проекта с вашего GitHub аккаунта.

• Как показано на рисунке выше, отметка 1 указывает на возможность публикации вашего локального проекта на вашем GitHub-аккаунте.

• Как показано на рисунке выше, отметка 1 указывает на возможность создания Gist. Официальный сайт GitHub Gist: https://gist.github.com/

Основные кнопки для управления версиями

• Как показано на рисунке 1, это контекстное меню, вызываемое правым щелчком мыши по папке.

• Как показано на рисунке 1, это контекстное меню, вызываемое правым щелчком мыши по файлу.

> * Как показано на рисунке, обведенные красным кругом, это кнопки управления версиями на панели инструментов. Большинство пользователей используют именно эти кнопки для управления версиями.

• Первая кнопка: Update Project — обновление проекта.
• Вторая кнопка: Commit changes — коммит всех измененных файлов в проекте. При нажатии этой кнопки не происходит немедленного коммита всех файлов, а сначала отображается окно с перечнем всех измененных файлов. Подробное описание этой операции будет далее.
• Третья кнопка: Compare with the Same Repository Version — сравнение текущего файла с версией этого файла в репозитории. Если текущий файл не был изменен, кнопка становится серой и недоступной для нажатия.
• Четвертая кнопка: Show history — отображение истории изменений текущего файла.
• Пятая кнопка: Revert — откат текущего измененного файла к предыдущей версии. Если текущий файл не был изменен, кнопка становится серой и недоступной для нажатия.

• Как показано на рисунке 1, это область управления версиями в меню.

Общие настройки управления версиями

• Как показано на рисунке 1, текущий проект использует систему управления версиями Git. Если вы не хотите использовать управление версиями для этого проекта, вы можете нажать минусовую кнопку рядом с названием системы. Если вы хотите переключиться на другую систему управления версиями, вы можете нажать Git, и появится список всех поддерживаемых систем управления версиями IntelliJ IDEA. Однако обычно один проект использует одну систему управления версиями.
• Как показано на рисунке 2, Show directories with changed descendants — показывать директории, содержащие измененные файлы, в цвете управления версиями. По умолчанию этот параметр не отмечен, но я рекомендую его отметить.> * Как показано на рисунке 1, When files are created означает, что IntelliJ IDEA будет делать при появлении новых файлов в проекте. По умолчанию выбрано Show options before adding to version control, что означает отображение диалогового окна для выбора, добавлять ли новые файлы в систему версий или нет. Если вы не хотите видеть диалоговое окно, вы можете выбрать один из двух нижеследующих вариантов.
• Как показано на рисунке 2, When files are deleted означает, что IntelliJ IDEA будет делать при удалении файлов из проекта. По умолчанию выбрано Show options before removing from version control, что означает отображение диалогового окна для выбора, удалять ли удаленные файлы из системы версий или нет. Если вы не хотите видеть диалоговое окно, вы можете выбрать один из двух нижеследующих вариантов.

Изменения:

1. When files are created -> При создании файлов
2. Show options before adding to version control -> Показать опции перед добавлением в систему контроля версий
3. When files are deleted -> При удалении файлов
4. Show options before removing from version control -> Показать опции перед удалением из системы контроля версий

• Как показано на рисунке 1, для файлов, которые вы не хотите добавлять в систему версий, вы можете добавить их в список игнорируемых файлов. Однако, если файл уже добавлен в систему версий, использование этой функции означает, что файл или директория больше не могут использоваться в операциях версий, таких как коммит или обновление. В процессе моего использования я заметил, что эта функция работает не очень хорошо в SVN, но работает в Git.! Версийный контроль: часто используемые настройки> * Изображённое выше всплывающее окно представляет собой окно сводки изменений, которое появляется после нажатия кнопки Commit Changes.
• Как показано на рисунке, помеченном как 1, можно выполнить действия с помощью правого клика мыши по файлу.

• Show Diff Сравнивает текущий файл с версией этого файла на сервере.
• Move to Another Changelist Перемещает выбранные файлы в другой Change list. Change list — это важный концепт, который требует особого внимания. Часто при разработке проекта одновременно выполняется множество задач, каждая из которых может затрагивать разные файлы. Поэтому часто возникает ситуация, когда вы изменили 30 файлов, из которых 15 относятся к заказам, а остальные 15 — к членству. В этом случае вы хотите, чтобы при коммите кода файлы были разделены по бизнес-логике, чтобы было легче описать Commit Message, а также легче было различать бизнес-модули среди множества файлов. Поэтому я обычно перемещаю 15 файлов, связанных с заказами, в другой Change list, чтобы сосредоточиться на 15 файлах, связанных с членством, и сначала сделать коммит для Change list членства, а затем для Change list заказов. Я также использую Change list для временного хранения файлов, которые не нужно коммитить сразу, и добавляю их в отдельный Change list.Когда я решу, что эти файлы нужно коммитить, я это сделаю, чтобы они не мешали текущему коммиту. В целом, Change list служит для лучшего управления версионными файлами и позволяет сосредоточиться на конкретных задачах, что повышает эффективность.
• Jump to Source Открывает и переходит к выбранному файлу.

• Как показано на рисунке, помеченном как 2, можно выполнить действия с помощью кнопок на панели инструментов. Объектом действий является выбранный файл, а для выбора нескольких файлов можно использовать клавишу Ctrl. Важно отметить, что это не связано с предыдущими флажками.
• Как показано на рисунке, помеченном как 3, можно выполнить некоторые действия с файлами перед коммитом (в данном проекте используется Git, поэтому некоторые кнопки могут отличаться для других систем контроля версий):

• Reformat code Форматирует код. Если вы работаете в области веб-разработки, не рекомендуется использовать этот параметр, так как форматирование JSP-файлов может быть неэффективным. Если все файлы — это Java-классы, можно смело форматировать код.
• Rearrange code Перестраивает код. IntelliJ IDEA поддерживает множество сложных настроек перестройки кода, что будет рассмотрено позже. После настройки функций форматирования кода можно попробовать использовать этот параметр для автоматической перестройки кода.>> * Optimize imports Оптимизировать импорты, автоматически удаляя неиспользуемые импорты. Выберите этот пункт, так как он влияет только на Java-классы, и не стоит беспокоиться о побочных эффектах.
• Perform code analysis Выполнить анализ кода. Этот пункт не следует обрабатывать при каждом коммите, а следует привыкнуть к анализу кода после завершения разработки. IntelliJ IDEA включает в себя интегрированный анализ кода.
• Check TODO Проверить TODO в коде. Функция TODO будет подробно рассмотрена в отдельной главе. Вкратце: это функция для отслеживания задач.
• Cleanup Очистить версионный控制系统，删除一些版本控制系统中的错误信息，建议选择（主要针对 SVN，Git 不适用）。

• Как показано на рисунке (4), заполните информацию о коммите.
• Как показано на рисунке (5), Change list список изменений, это выпадающий список, который позволяет переключаться между различными списками изменений и коммитить соответствующие файлы.
• Как показано стрелкой на рисунке, можно просмотреть используемые Commit Message в истории коммитов. Иногда приходится выполнять одну и ту же задачу, но коммитить несколько раз. Для лучшего управления проектом рекомендуется использовать единообразные сообщения коммитов. ! Версионного контроля связанные с ним часто используемые настройки> * Как показано на рисунке, с помощью стрелок, если вы используете Git, нажатие на указанное место позволяет переключаться между ветками, создавать новые ветки, а также выполнять слияние, удаление веток и другие операции.

Использование SVN

Этот окно в SVN называется Changes в некоторых версиях IntelliJ IDEA, а в других — Version Control. Причины такой разницы мне пока неизвестны, но для пользователя это не имеет большого значения, так как структура одинакова. Важно понимать, что это один и тот же функционал.

Вкладка Local Changes на рисунке показывает общее состояние всех файлов в проекте SVN. Здесь Default — это имя по умолчанию для списка изменений в IntelliJ IDEA, а no commit — это список изменений, который я создал сам. Я привык хранить временно не отправленные изменения в этом списке. Списки изменений очень полезны и важны, поэтому им стоит уделить особое внимание. Unversioned Files — это файлы, которые не были добавлены в систему контроля версий. Вы можете нажать Click to browse, чтобы увидеть список этих файлов.

Вкладка Repository отображает сводку информации о проекте SVN, которая очень подробна и часто используется мной. Если вы не видите данных на этой вкладке, вам нужно нажать кнопку обновления, обозначенную красным кругом на рисунке. По умолчанию фильтры не настроены так, как показано на рисунке, поэтому я настроил фильтр по User. Выбрав User, как показано стрелкой 1 на рисунке, вы увидите список всех пользователей, которые участвовали в коммитах. Выбрав одного из пользователей, как показано стрелкой 2, вы увидите список всех его коммитов. Выбрав один из коммитов, как показано стрелкой 2, вы увидите детали этого коммита, как показано стрелкой 3. Вы можете выполнять правые клики на этих файлах для выполнения различных операций, которые аналогичны тем, что были упомянуты выше.В целом, функционал SVN очень полезен для управления и проверки кода команды разработчиков, поэтому настоятельно рекомендуется овладеть этим функционалом.## Часто задаваемые вопросы по Git

• При обновлении появляется ошибка: Can't update: no tracked branch
  • Решение: Откройте git-bash (путь: C:\Program Files\Git\git-bash.exe), перейдите в корневую директорию проекта, который не обновляется, и введите: git branch --set-upstream-to origin/master master. После нажатия Enter обновите проект в IntelliJ IDEA, и проблема должна быть решена.
• После ввода неверного пароля, окно для ввода пароля больше не появляется:
  • Решение представлено на рисунке ниже: выберите Не сохранять, забывать пароли после перезапуска. После того, как вы убедитесь, что ввели правильный пароль, выберите опцию для сохранения пароля.

Введение в Git Flow

Основные понятия Git Flow- Git Flow — это набор расширений для Git, предоставляющий высокоуровневые операции над репозиторием в соответствии с моделью ветвления Винсента Дриессена. Основное внимание уделяется модели ветвления Винсента Дриессена, и все последующие объяснения основаны на этой модели.

- Мнение Винсента Дриессена: <http://nvie.com/posts/a-successful-git-branching-model/>
- `Git Flow — это набор расширений для Git` можно рассматривать Git Flow как плагин для Git, который упрощает использование сложных команд Git. Например, одна команда Git Flow может заменить 10 команд в стандартном Git.
- Git Flow не влияет на стандартный Git, вы можете продолжать использовать стандартные команды Git или использовать команды Git Flow.

• Существуют и другие модели управления ветвями, подробнее можно посмотреть здесь: http://www.ruanyifeng.com/blog/2015/12/git-workflow.html### Основные концепции Git Flow

Два обязательных основных ветви (долгосрочные ветви): - master, по умолчанию основная ветвь в репозитории Git. Код на этой ветви обычно считается стабильным и не подлежит изменению, кроме слияния других ветвей. - develop, используется для хранения кода в процессе разработки и также не подлежит изменению, кроме слияния других вспомогательных ветвей.

Вспомогательные ветви (временные ветви), создаваемые по мере необходимости: - feature branches (ветви функций) - Создаются на основе ветви develop - После завершения разработки сливаются в ветвь develop - При начале разработки новой функции создается feature branch. После завершения разработки и утверждения новой функции она сливается обратно в develop. - Для одиночной разработки feature branches, после start можно завершить разработку и завершить (finish). - Для коллективной разработки feature branches, после start необходимо опубликовать (publish) для слияния с другими разработчиками, после завершения всех разработок завершить (finish). Этот подход применим и к другим вспомогательным ветвям. - При обнаружении ошибок в процессе разработки feature branches, они могут быть исправлены и отправлены на ветви feature branches. - release branches (ветви предрелизного состояния) - Создаются на основе ветви develop - После тестирования и утверждения новых функций, сливаются в develop и master - Используются для подготовки к выпуску новой версии, на них можно выполнять небольшие исправления ошибок, подготовку версий и другие мелкие изменения, связанные с выпуском. Это позволяет подготовиться к выпуску, не влияя на разработку новых функций в ветви develop. - hotfix branches (ветви быстрого исправления) - Создаются на основе ветви master - После исправления и тестирования, сливаются в master и develop - Используются для быстрого исправления ошибок в рабочей среде версии. ### Установка Git Flow- Windows: Если вы установили Git с помощью Git for Windows, то Git Flow уже встроен.

• Mac: brew install git-flow-avh
• Linux: wget --no-check-certificate -q https://raw.githubusercontent.com/petervanderdoes/gitflow--avh/develop/contrib/gitflow-installer.sh && sudo bash gitflow-installer.sh install stable; rm gitflow-installer.sh
• Дополнительные версии: https://github.com/petervanderdoes/gitflow-avh/wiki/Installation
• После установки на систему, установите плагин поддержки Git Flow для IntelliJ IDEA: https://plugins.jetbrains.com/plugin/7315-git-flow-integration

Основные команды Git Flow

• https://danielkummer.github.io/git-flow-cheatsheet/index.ru.html
• http://www.jianshu.com/p/9e4291078853
• http://stormzhang.com/git/2014/01/29/git-flow/

Использование плагина Git Flow Integration

• Если вы уже понимаете теорию, представленную выше, то эти скриншоты помогут вам понять, что они означают.