Simulative Git Module

Hello, GitHub!

Домашнее задание

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

Итак, представьте себе: Вы – разработчик в IT-компании. Вместе с командой других разработчиков Вы делаете наикрутейший проект, в котором используется сторонняя библиотека с открытым исходным кодом. В какой-то момент работы над проектом вы замечаете, что ваш проект работает не так, как вы ожидаете - всему виной оказывается ошибка в коде сторонней библиотеки! Вы отправляетесь в Issues репозитория библиотеки, чтобы завести сообщение об ошибке и попросить разработчиков библиотеки исправить её, но оказывается, что эту ошибку ранее уже заметил и решил исправить один из мейнтейнеров официального репозитория. К несчастью, этот мейнтейнер покинул команду, и задача осталась недоделанной. Вы решаете взять дело в свои руки, ведь так Вы и вклад в развитие библиотеки внесёте, и своему проекту поможете!

Каков план действий?

1. Поскольку разработкой сторонней библиотеки занимается другая команда, коммитить напрямую в официальный репозиторий Вы не сможете. Не беда, ведь можно создать форк, сделать там нужную работу, а затем отправить изменения обратно в официальный репозиторий посредством пулл-реквеста. Давайте начнём с первого пункта: создайте форк репозитория со всеми его ветками.
2. Отлично, Вы скопировали официальный репозиторий и теперь имеете свой собственный репозиторий, но удалённый. Качественно вести разработику в удалённом практически невозможно, поэтому теперь вам необходимо клонировать ваш удалённый репозиторий на рабочий компьютер.
3. Из описания проблемы в Issues вы увидели, что мейнтейнер работал в ветке experiment основного репозитория. Поскольку вы создали форк со всеми ветками основного репозитория, то у вас эта ветка тоже есть. Самое время на неё переключиться.
4. Изучив содержимое файлов и журнал коммитов этой ветки, вы поняли, что для решения задачи часть последних коммитов просто не нужна, а другая часть нуждается в минорных изменениях. Свою работу Вы решили начать с наиболее раннего коммита, где требуются исправления: это коммит с заголовком "Update experiment.txt". Найдите в истории коммитов его идентификатор, переключитесь на него и создайте из него новую ветку с именем homework.
5. Теперь - самое главное: исправляем ошибку в коде. Для этого достаточно в содержимом файла experiment.txt заменить слово experiment на homework.
6. Вы всё протестировали и убедились в том, что ваши изменения действительно решают исходную проблему. Ура! Осталось проделать обратный путь и отправить изменения в официальный репозиторий. Но если вы прямо сейчас отправите свои текущие изменения в свой же удалённый репозиторий и откроете пулл-реквест в основную (master) ветку официального репозитория, то ничего не выйдет: Причина в том, что пока тот мейнтейнер делал работу, ветка master убежала вперёд. Вам нужно нагнать изменения в ней, вмержив её изменения в свою ветку homework. Однако, использовав git merge, история вашей ветки будет не самой красивой: Появился merge-коммит! Это не смертельно, но в данном случае можно обойтись и без него, немножко переписав историю: Как этого добиться? Поскольку с вашей веткой, кроме вас, сейчас никто не работает, можно абсолютно безопасно использовать git rebase. Сделайте это: синтаксис команды запуска ребейза можно подсмотреть с помощью git rebase --help, а то, что делать после начала ребейза, вам подскажет сам git. Читайте предельно внимательно, ничего не пропускайте. Это важно! И помните, что при разрешении конфликта вам нужно просто выбрать ту версию изменений, которую вы хотите оставить, стерев всё ненужное и оставив только нужное.
7. Теперь, когда все изменения внесены, тесты проведены, а история ветки приняла окончательный вид, можно отправлять работу на проверку. Но сначала - в свой удалённый репозиторий.
8. Последний шаг: можно открывать пулл-реквест! Внимательно проверьте ветки - как исходную (то есть ветку в своём удалённом репозитории, изменения из которой вы хотите внести), так и конечную (ветку в официальном репозитории, в которую вы хотите внести ваши изменения). Всё проверили? Тогда остаётся только нажать Create Pull-Request и ждать ответа мейнтейнеров!