Git root idea

IntelliJ-IDEA version control introduction, mainly about git

IntelliJ-IDEA pre-installed version control introduction

This makes many people think that IntelliJ IDEA comes with version control tools such as SVN or Git, and thinks that as long as IntelliJ IDEA is installed, you can fully use the features that version control should have. This is completely a misinterpretation. IntelliJ IDEA comes with a support plugin for these version control tools, but what version of the version control client is still installed. It can be seen that it also comes with the github plugin, because too many people use Github for collaboration or project version management.

Git. exe and Github configuration

Make sure Git and TortoiseGit are installed on your computer. Then configure the git client

Configure Github

Then you can checkout the project on GitHub.

If there are multiple projects on GitHub, you can choose one of them.

After clicking clone, IntelliJ-IDEA will start the clone project.

Upload local projects to Github

1. The version control for this project is GIT 2. Show directories with changed descendants means that the files in the subdirectory have been modified, and all the upper directories of the file show the color whose version control is modified (recommended check)

Confimation confirmation information panel

Tips for adding new files and deleting files

Ignored Files panel

This is a file that is not set to be added to version control.

Commit file panel introduction

Show Diff can compare the difference between local and server files

Move to Another ChangeList

This option can be used to place the changed files in a folder. After the modification, they can be submitted together (usually used in sub-module development, that is, when a module is developed, the code changed on this module can be set to In a folder and then pray together)

View submission information

Fourth, the entrance of the project branch setting

If you use Git version control, you can see the relevant control entry in the lower right corner.

Similar to Github, Gitlab is a code-managed website. The biggest difference is that projects created by Gitlab can be freely private, don’t have to be charged like Github, and Gitlab can build its own private service. So open source projects are generally placed on Github, personal projects can be placed on the public network Gitlab, and the company’s private projects can be placed on their own Gitlab.

Publish the project to gitlab

Create a project locally first first add the project to version control

After adding to version control, we can see that the files are all green.

Then submit the project locally

Fill in the information about the submission

Noteperform code analysisDo not tick, this option will automatically check the code, it will be very slow then push the project to the server Click on push below

Next you need to define the remote service

At this point, you need to set the url in the popup box. We first create a new project in gitlab, so that the purpose is to get the relevant url. After filling in the url, click on push

You will also need to fill in the password on gitlab.

After the push is successful, there will be such a prompt, this is a successful prompt:

Then look at the project information on gitlab, you can see the submitted code, as shown below

Invalid VCS root mapping. The path is registered as a Git root, but no Git repositories were found there.

Error details: Invalid VCS root mapping The directory <path is registered as a Git root, but no Git repositories were found there.

Reason: The git project shown in the directory does not exist, causing this error

Solution: Select the non-existent item in the version contral in as and delete it:

As shown in the figure:

Intelligent Recommendation

Unregistered VCS root detected

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

UPDATE: на момент публикации уже будет доступен новый UI гитхаба, и некоторые иконки будут не там, где показано это в статье. Вы не пугайтесь: просто нужно будет либо не переходить на новый UI, либо поискать их.

Клонируем проект локально

Здесь есть два варианта.

Чтобы клонировать проект с гитхаба, нужно скопировать ссылку на проект и передать ее в IntelliJ IDEA:

Работа с репозиторием

Чтобы дальше работать, нужно запомнить несколько очень полезных горячих клавиш:

Что мы хотим?

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

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

Что для этого нужно сделать?

Далее уже зависит от ваших задач и фантазии.

Получить изменения с удаленного сервера?

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

Вводим ctrl + t:

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

Создать новую ветку на основе master

Здесь все просто.

Переходим в правый нижний угол и нажимаем на Git: master, выбираем + New Branch.

Оставляем галочку Checkout branch и пишем имя новой ветки. Для меня это будет readme-improver.

После этого Git: master сменится на Git: readme-improver.

Имитируем параллельную работу

Чтобы конфликты появились, их кто-то должен создать 😀

Я через браузер отредактирую README новым коммитом и таким образом сымитирую параллельную работу. Мол кто-то во время моей работы сделал изменения в том же файле, что и я, что приведет к конфликту. Я удалю слово “полностью” из 10 строки.

Реализовать свою функциональность

Задача стоит в том, чтобы поменять README и добавить описание к новой статье, то есть то, что работа в гите идет через Intellij IDEA. Добавляем это:

Изменения выполнены, теперь можно создать коммит. Нажимаем горячую клавишу ctrl + k, получим:

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

В секции Commit Message пишем текст коммита, и чтобы он создался, нужно нажать кнопку Commit. Я так и не нашел, как бы так сделать это горячей клавишей, так что если кто-то найдет — пишите, я буду очень рад.

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

Проверить, не изменилась ли основная ветка

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

Поэтому переходим на master ветку. Для этого нужно в правом нижнем углу сделать то, что показано ниже на рисунке:

В master ветке нажимаем ctrl + t, чтобы получить ее последние изменения с удаленного сервера. Если посмотреть, какие были изменения, легко можно заметить, что произошло:

Как видим, было удалено слово “полностью”. Быть может, это был кто-то из маркетинга и решил, что так нельзя писать и дал разработчикам задачу обновить это.

Теперь у нас локально последняя версия master ветки. Переходим обратно на readme-improver.

Теперь нужно заребейзить изменения из мастер ветки в нашу. Делаем:

Если вы все правильно выполняли со мной, в результате должен показаться конфликт в README файле:

Здесь также много информации, которую нужно бы понять и впитать. Здесь показан список (в нашем случае из одного элемента) файлов, в которых есть конфликты. Мы можем выбрать три опции:

Непонятно, что там изменилось, и если уж изменения находятся в мастере, значит они нужны там, и просто принять наши изменения нельзя, поэтому выбираем merge:

Здесь видно, что есть три части:

Нам нужно таким образом собрать результат, чтобы он всех удовлетворил. Поэтому изучили, что сделали ДО нас, поняли, что просто убрали слово “полностью”. Ну окей, без проблем. Значит и мы его уберем в результате и добавим наши изменения. Как только поправим результат, можно нажать Apply.

После этого всплывет оповещение, что ребейз прошел успешно:

Вот так мы зарезолвили свой первый конфликт через Intellij IDEA 😀

Запушить изменения на удаленный сервер

Следующий шаг — запушить изменения на удаленный сервер и создавать пул-реквест. Для этого просто нажимаем ctrl + shift + k, после чего получим:

Слева будет список коммитов, которые не запушены на удаленный репозиторий, а справа будут все файлы, которые изменены. И все: нажимаем Push, и будет вам счастье 🙂

При успешном пуше будет вот такое уведомление в нижнем правом углу:

Как использовать Git в IDE Intellij IDEA / Webstorm

В предыдущей статье было подробно описано, каким образом можно работать с Git, используя интерфейс командной строки (терминал). В данной статье мы покажем, как можно выполнить самые часто используемые Git команды в IDE на примере продуктов компании Jet Brains — Intellij IDEA или Webstorm (интерфейс у них одинаковый).

Клонирование удаленного репозитория

Клонировать проект с удаленного репозитория с помощью IDE можно двумя способами.

Индексирование / отслеживание изменений

Там же, в инспекторе файлов можно увидеть, какие из файлов были добавлены или изменены, по цвету имени файла.

На картинке выше:

Примечание

На этой же картинке можно увидеть, что папка «.idea» была добавлена в «.gitignore» и не отслеживается Git. Одной из очень часто встречаемых ошибок новичков является добавление файлов из папки «.idea» в локальный / удаленный репозиторий.

Работа с ветками

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

Если вы не видите надписи Git и имени ветки, скорее всего ваш проект не инициализирован как Git репозиторий. Чтобы данное меню было доступно, вы должны работать либо в проекте, в котором ранее была выполнена команда git init, либо в проекте, который был склонирован с удаленного репозитория (в таком случае подвязка проекта к Git происходит автоматически).

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

Для создания новой ветки необходимо нажать + New Branch, и в открывшемся окне ввести имя новой ветки. Галочка Checkout branch позволяет после создания сразу же переключиться на новую ветку.

Важно!

Новая ветка будет создана на основании той ветки, на которой вы находились до этого (то есть будет ее точной копией). При работе на реальных проектах, не забудьте убедиться, что при создании новой ветки вы находитесь на ветке «master» или «develop» — чаще всего вам будет нужно именно это.

Чтобы переключиться на другую локальную ветку, необходимо кликнуть на имя ветки в разделе Local Branches, и выбрать пункт Checkout.

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

Чтобы вмерджить одну ветку в другую, вам нужно выполнить несколько шагов:

Также вы можете сравнить какие файлы и чем отличаются в двух ветках. Для этого, находясь на одной из веток, нажмите в меню на имя другой ветки, которая вас интересует, и выберите пункт Compare with Current.

Откроется диалоговое окно, в котором вы сможете увидеть список всех файлов, которые отличаются в этих двух ветках. Там же вы можете посмотреть, какие именно изменения были внесены в тот или иной файл (нажав правой кнопкой на файл и выбрав пункт Show Diff, либо с помощью комбинации клавиш Ctrl + D).

Чтобы удалить ветку, в меню нажмите на имя ветки, и выберите пункт Delete.

Если вы удаляете локальную ветку, для которой существует удаленная ветка, в диалоговом окне после удаления локальной ветки вы увидите ссылку по имени Delete Tracked Branch. Нажав на эту ссылку, вы сможете сразу удалить также и удаленную ветку, которая была подвязана под локальную.

Работа с удаленным репозиторием

Кнопки для работы с удаленным репозиторием находятся в правом верхнем углу интерфейса программы. Там рядом с надписью Git содержится две кнопки. Первая позволяет получить все изменения из удаленного репозитория для текущей ветки. Вторая наоборот — отправить свои изменения в удаленный репозиторий.

Pull

Первая кнопка по сути выполняет команду git pull. Когда вы нажмете на нее в первый раз, у вас появится диалоговое окно с выбором опций, как вы хотите стянуть изменения. В данном окне ничего менять не нужно.

Если не отметить галочку Do not show this dialog in the future, вы будете видеть данное окно каждый раз при нажатии кнопки Pull. Поэтому можете смело отмечать галочку, так как для 99% случаев вам подойдут указанные настройки по умолчанию. А если нет, в будущем вы сможете их изменить.

Push

Вторая кнопка позволяет выполнить две команды — git commit и git push. При нажатии данной кнопки, если вы вносили изменения в проект после последнего коммита, у вас откроется диалоговое окно, в котором будут показаны все измененные файлы, которые должны попасть в коммит.

Здесь вы можете галочками отметить, какие файлы должны попасть в коммит, а какие нет. Например, часть файлов, которые относятся к одной части функционала, вы можете добавить в один коммит, оставшиеся файлы — в другой.

Кликнув правой кнопкой на файле и выбрав команду Show Diff, вы сможете в отдельном окне увидеть, какие именно изменения были сделаны в этом файле. Иногда перед большим коммитом бывает полезно просмотреть все изменения, которые вы сделали, по всем файлам, чтобы убедиться, что вы ничего не забыли, и не оставили ничего лишнего в коде (например, записей console.log() или debugger).

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

После того, как вы убедились, что с коммитом все хорошо, вам необходимо в этом же модальном окне в соответствующем поле ввести Commit message, и подтвердить коммит.

Нажимаем кнопку Push и радуемся 🙂

Изменения внутри файла

Когда мы работаем в любом текстовом файле, IDE показывает нам все места, где мы сделали изменения в этом файле. Такие места показываются на полях слева от документа.

На рисунке выше:

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

А здесь можно увидеть, какая строка кода была удалена.

Нажав на кнопку Rollback lines, можно полностью отменить конкретно это изменение, и вернуть данную строку или строки кода в исходное состояние.

История изменений

IDE позволяет очень удобно просматрировать историю изменений, как в отдельном файле, так и во всем проекте в целом.

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

Чтобы посмотреть историю всех коммитов в проекте, в нижнем меню выберите пункт Version Control, и в открывшемся окне выберите вкладку Log.

Здесь вы сможете увидеть историю всех коммитов в проекте и информацию о них — кто коммитил, когда, в какую ветку, какие файлы входили в каждый коммит. Линиями слева наглядно показана история работы с ветками, их слияния. Также слева вверху есть очень удобный поиск по Commit message, чтобы быстро можно было найти интересующий вас коммит (вот почему сообщения должны быть осмысленными).

Основы работы с системой контроля версий Git

Гит — это так называемая система контроля версий. У нее очень много функций и возможностей. Для того, чтобы начать понимать, как это работает и зачем это нужно, начнем с самых азов.

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

На начальных этапах, когда мы будем работать сами, гит нам нужен лишь для того, чтобы хранить удаленно свои проекты и давать ссылки ментору на проверку. То есть, если вернуться к вышеупомянутому процессу, ментор — это человек из пункта 3. С поправкой лишь на то, что изменения к вам в проект он вносить не будет 🙂

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

Итак, ниже — инструкция, как все-таки начать работать с гитом.

Терминология

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

Установка Git

Для начала надо установить программу Git себе на компьютер.

Инструкции по установке для разных операционных систем.

Далее нам нужно открыть на компьютере терминал, в любой папке. В операционной системе Windows это можно сделать нажав правой клавишей мыши в папке, и выбрав пункт меню Открыть терминал или Git bash here. Ниже красным цветом выделены строки-команды для терминала.

Только что мы установили глобальные настройки для гита — дали ему знать, кто с ним общается и как нас найти. Эти команды необходимо выполнить только один раз после установки гита, более они нам не понадобятся.

Привязка проекта к Git

Чтобы создать проект, который будет управляться с помощью Git, необходимо выполнить следующие шаги:

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

• У вас еще нет проекта на гитлабе и нет проекта на компьютере. Все создаем с нуля. В таком случае переходим к Варианту 1.
• У вас нет проекта на гитлабе, но есть папка с файлами на компьютере, которую вы отныне хотите хранить на гитлабе. В таком случае переходим к Варианту 2.

Вариант 1. Создание нового Git проекта

У вас нет ни проекта на гитлабе, ни папки на компьютере, вы только стартуете работу, и решили начать сначала с подключения гита в проект. Для этого, после выполнения предыдущих четырех шагов:

Для внесения последующих изменений в проект переходим к следующему одноименному разделу.

Вариант 2. Подключение существующего проекта к Git

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

Внесение последующих изменений в проект

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

Неотслеживаемые файлы

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

Когда это нужно? Например, при работе с IDE Intellij IDEA или Webstorm при открытии любого проекта у вас в нем автоматически создается папка под названием .idea. Это системная папка, которая нужна для работы вашего редактора кода. Там в определенном формате указывается техническая информация о проекте, с которым вы работаете, а также разные настройки конкретно для вашей IDE.

Проблема в том, что другой разработчик, который работает с вами на этом проекте, тоже может иметь свою локальную папку .idea на своем компьютере. И содержимое этих папок у вас будет отличаться, если вы используете разные программы, или даже разные версии одной и той же программы. И если вам на локальный компьютер попадут настройки чей-то чужой IDE, это может привести к тому, что вы больше не сможете открыть этот проект — IDE сломается.

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

Для помощи разработчикам при работе с такого рода файлами и папками, в гите существует специальный файл, который называется .gitignore. Именно так — названия файла нет, расширение файла — .gitignore. Этот файл должен лежать в корне вашего проекта, и его содержимое будет говорить гиту, какие из файлов и папок никогда не нужно отслеживать и добавлять в коммиты, даже при выполнении команды git add ..

Внутри это обычный текстовый файл. Каждое правило (ссылка на файл / папку) должны находиться на новой строке.

Если вы хотите добавить какую-то папку в .gitignore, напишите имя папки, и поставьте после имени слеш /. Если вы хотите добавить какой-то файл, просто напишите полное имя файла с расширением.

Допускается использование спецсимволов. Например, символ * означает «любой».

Если вы работаете с Intellij IDEA или с Webstorm, минимальный файл .gitignore у вас должен включать папку .idea, а также все файлы с расширением .iml — это тоже системный файл с описанием проекта, который иногда может автоматически появляться у вас в корне проекта. Выглядеть такой .gitignore файл будет следующим образом:

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

Введение

Расскажу как работать с git, используя встроенные инструменты IntelliJ Idea (аналогичные Android Studio). Мы создадим проект (в новом интерфейсе Idea) и опубликуем на GitHub, попутно отредактировав файл gitignore, чтобы на сервер не загружались ненужные для отслеживания файлы. И все это не выходя из среды разработки.

В конце создадим ветку, правильно придумаем сообщение коммита, опубликуем ее и создадим pull request. Процесс будет демонстрироваться на примере взаимодействия с учениками, проходящими практику по основам Kotlin в боте. Этот процесс –имитация сдачи задач и ревью кода в реальной продуктовой разработке. Этим навыком необходимо владеть, чтобы вас сразу приняли за своего.

Как работает Git

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

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

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

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

Как правило жизненный цикл ветки кода соответствует жизненному циклу бизнес-задачи. Чтобы лучше понять, как код доходит до финальной версии и зачем нужны другие ветки, здесь придется быстро затронуть жизненный цикл задачи. Это похоже на наше взаимодействие в спринте по Kotlin.

Жизненный цикл задачи

Добавлю пару слов про репозиторий. Гит-репозиторий – это и есть хранилище кода с вашим проектом. Это хранилище (по сути папка) может существовать локально на компьютере, также используя систему контроля версий. Или может быть “запушена” (отправлена) в удаленный гит-репозиторий, как раз для совместной разработки. Такие хранилища предоставляются разными сервисами, один из них GitHub. Вам уже нужно иметь там аккаунт, если что это бесплатно.

Git в IDEA

Окей. Создаем новый проект для задач в Idea.

Мы создали проект, сейчас это просто папка с файлами на компьюторе. В эту папку нужно подключить систему контроля версий, чтобы файлы начали отслеживаться. Вообще есть множество разных гит клиентов, но в Idea встроен собственный. Жмем на пункт меню Version Control System и выбираем активацию контроля версий. В окне выбора системы оставляем Git и жмем окей.

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

Gitignore

Теперь смотрим на иерархию файлов. Они окрасились в красноватый цвет, это значит, что система отслеживания их видит, но пока еще не отслеживает. Иначе можно сказать эти файлы еще не в стейдже. В зависимости от состояния файлов (добавлен в стейдж, создан новый, изменен, закомичен) они будут менять свой цвет.

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

Видим список файлов, которые еще не участвуют в контроле версий (изначально это все файлы). Однако, Идея предлагает начать отслеживать много лишнего. Вернемся во вкладку Project. При создании/открытии проекта генерируется ряд файлов. Папки и файлы с точкой вначале – это скрытые папки, системные. Там хранятся файлы, описывающий ваш проект. Как правило, все файлы, которые генерируются, не хранятся в репозитории. Папки .gradle и .idea нам не нужны (для отслеживания). Поэтому нужно сообщить гиту, чтобы он игнорировал их, если внутри будут какие-то изменения.

Среда разработки сначала предложит создать файл в случае его отсутствия. Потом предложит добавить созданный файл в отслеживание. Здесь можно установить галку “Больше не спрашивать”, таким образом все новые файлы автоматически будут добавляться в отслеживание (или в стейдж).

Хорошо, открылся созданный .gitignore с добавленной папкой. Пропишем туда еще и папку с настройками Idea. Но остался еще один штрих. Если нажать на знак молотка – запустится сборка проекта. Она всегда запускается перед тем, как вы запускаете какой-либо код. После сборки появится новая сгенерированная папка build. Она нам тоже не нужна для отслеживания, добавим в игнор, чтобы не захламлять стейдж.

Великолепно. Возвращаемся во вкладку Commit и жмем обновить. Остались только нужные файлы. Отмечаем все, что осталось. Теперь можем создать первый коммит в нашем локальном репозитории. Пишем его название в окне ниже. Как правило он так и называется First Commit или Initial Commit. Жмем кнопку.

Мы сделали первый коммит в основную и единственную ветку master. Все коммиты проекта можно увидеть, нажав на раздел Git внизу, в панели инструментов. Там будут все ветки, все коммиты и информация по изменениям файлов для конкретного коммита.

Публикация репозитория на GitHub

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

Заходим на гитхаб в раздел репозитории и видим проект, который запушили. Здесь указывается название последнего коммита, с которым были внесены изменения. Можно походить по файлам. Созданный .gitignore тоже залился, благодаря чему здесь отсутствуют лишние файлы настроек, необходимые для локальной сборки.

Окей. Переходим в рабочий флоу и сейчас стоят такие цели:

Создание ветки

Делается это в пару кликов, но при создании ветки нужно убедиться, что мы “бранчимся” от правильной ветки. Мы сейчас в “мастере”, все ок. Но в будущем при создании веток для других задач не забывайте переключаться на мастер, прежде чем создавать новую ветку. Если вы делаете задачи параллельно, вам придется делать это часто. Жмем на New Branch. Название также рекомендуется делать осмысленное, связанное с названием задачи. Предположим мы собрались делать первую задачу первого урока. Слова разделяются дефисом. Галка checkout говорит о том, что после создания мы переключимся на эту ветку.

Нейминг комитов

Теперь внесем какой-то код в качестве решения. Я рекомендую организовывать код для наших задач так: отдельный пакет для урока, отдельный файл для задачи.

Далее оставляем осмысленный коммит. Кстати, просматривая измененные файлы можно полностью откатывать изменения выбрав Rollback из контекстного меню файла. Название коммита у меня будет таким KS-1-1, сначала обычно пишется краткое обозначение проекта, в нашем случае это Kotlin Sprint, далее порядковый номер урока и задачи, чтобы можно было удобно навигироваться. Наконец, осмысленный короткий текст, что было сделано. Желательно на английском, но не обязательно. Главное – в едином стиле в рамках всего репозитория. Все, не забываем отметить нужные файлы галкой и сразу пушим эту ветку на сервер GitHub, в свой удаленный репозиторий.

Создание Pull request

Отлично. Вот так выглядит страница созданного pull request. Такой ее увидит проверяющий. Копируем ссылку на него из браузера и отсылаем в бот для конкретной задачи конкретного урока и ждем обратной связи. После принятия решения бот пришлет уведомление, нужно ли вам внести правки или решение принято. Как правило в продуктовой разработке тоже есть разного рода интеграции с чатами (слаком, телеграммом и прочим). Они уведомляют о новых ревью и необходимости правок или влития. В простом случае – можно пользоваться письмами в электронной почте.

Мердж

Только после принятия задачи нажимайте кнопку Merge pull request. Тогда изменения из рабочей ветки вольются в основную production ветку master. На всякий случай проверяем все на основной вкладке. Все работает. Для выполнения новых задач не забывай переключаться на master в Idea и только от нее создавать новые ветки.

Реальная практика тебя ждет в боте, заходи.

Для тех, кто собрался стать Android-разработчиком

Пошаговаясхема

Описание процесса обучения от основ Kotlin до Android-разработчика

Бесплатныеуроки

Авторский бесплатный курс по основам языка программирования Kotlin

Обучающийбот

Тренажер и самоучитель по Котлин – бесплатные тесты и практика