Комментарии 46
Как-то случайно добавил в коммит секретный файл с паролями. Как его оттуда вытащить без переделки всей истории?
Вообще, сложнее, чем хотелось бы. Если уже запушили — используйте git revert хеш_коммита, чтобы создать новый коммит, который удалит пароли. Если ещё локально — git reset HEAD~1, отредактируйте файл и сделайте новый коммит
Самое полное и понятное how-to по удалению секретов из гита.
git revert всё равно оставит секрет в истории коммитов, поэтому ПОЛНОЕ удаление только через перезапись истории и force push новой.
Если не запушили, переписать историю и выдохнуть.
Если запушили
Покаяться начальнику
Если начальник грамотный, он решит поменять пароли.
Force push может скрыть проблему, но, как ранее писали, мы не знаем как там на условном гитхабе организована уборка мусора (и никто не гарантирует, что там все служебные файлы гита не реплицируются куда нибудь без удаления, просто на всякий случай).
Ротация паролей. Иного выхода нет
Да, странно рассказывать про git и не начать с .gitignore
Не кидайтесь тапками, но я вообще не понимаю, зачем писать описание коммита( Почему просто не написать «фикс»?
Понятно, что в моменте это кажется излишней душнотой, но полное описание коммита — некая инвестиция в будущее. Через год, когда нужно будет найти «когда мы добавили ту кнопку», «фикс» нам не скажет ничего.
Мы, например, пишем: «fix: убрали дублирование кнопки в футере»
Описания здорово помогают, когда git blame обнаруживает регресс в коде возрастом 5+ лет.
Чтобы в логе было понятно, что кто делал
Гораздо лучше выглядит "(CW-1234) Fixed wrong padding on investor page", чем "trying to fix an issue"
Git blame — да, полезно для поиска виноватых. Но в больших командах как найти автора по хешу коммита быстро? Интеграция с Jira или с чем-то ещё?
Лет через 10 на Хабре будут статьи вида "Что такое монитор и как на него смотреть"
Как то очень оптимистично, судя по темпам деградации, это случится уже в новом 2026 году
Если вы хоть раз писали код, то видели файлы с названиями типа проект_v1, проект_финал2 и проект_самый_последний_точно_финал123. А потом пытались вспомнить, чем они отличаются и где же рабочая версия. Ещё веселее становится, когда над проектом трудится команда: кто-то что-то поменял и всё сломалось. Кто виноват, что делать
, а судьи кто— непонятно.Чтобы такого хаоса не было, и придумали Git.
Да пожалуйста.
Если вы хоть раз смотрели в окно, то видели одну и ту же улицу, только с каретами, или без карет, или с прохожими, или даже с полицейским на лошади. А потом пытались вспомнить, чем они отличаются и что же на самом деле видно в окне. Ещё веселее становится, когда в окно одновременно смотрит вся семья: кто-то видит городового, кто-то затылок того, кто видит городового, а кто-то разбил очки и всё сломалось. Кто виноват, что делать
, а судьи кто— непонятно.Чтобы такого хаоса не было, и придумали Телевидение.
(Откуда взялся монитор и что это такое — см. в части два, а пока читайте мой канал.)
Про коммиты: Conventional Commits в бонусе - супер, но как заставить команду их использовать? У нас все пишут "fix" и "update"
Conventional Commits внедряем через шаблоны в GitHub (.github/pull_request_template.md) и хуки pre-commit. Плюс, мы обычно проводим код-ревью с фидбеком — так что все уже привыкли
Бесит мержи в ветку main. Лучше ребейз.. 100500 коммитов, половина из которых не несёт смысловой нагрузки
И когда заходит пулл реквест. Он свершится и в описании коммита целая история изменения ветки. Почему все это не слить в один коммита перед тем как отправлять ПР в главную ветку?
Согласны, куча мелких коммитов в main усложняют чтение истории. Можно перед Pull Request выполнить git rebase -i HEAD~10 и объединить их в 1-2 содержательных коммита. Или настроить в GitHub опцию Squash and merge — история останется чистой
Потому что сквош коммитов уничтожает историю того что когда было сделано и зачем. То что коммиты не несут смысловой нагрузки это скилл ишью, надо подписывать нормально. То что они мешают лог смотреть это тоже скилл ишью, флаг —first-parent для этого существует.
Скрытый текст
Ох уж эта перезапись ветки... Но почему ничего не сказали про git reflog для восстановления после force push?
Гид по Git
Если бы не рифма, наверняка бы написали «гайд»?
А так, интересно. Я долго думал, надо ли мне разбираться с гитом? Понял, что, пожалуй, не надо. Эта система хороша для командной работы, а я всю жизнь программировал один. Однако проблема контроля версий существуют и в этом случае. Для ее решения пришлось разрабатывать собственную систему «итерационно-модульного» программирования.
Для итераций я просто копирую старый проект в новый. Условие перехода – более-менее реализованная «фича», в текущей итерации. Она описывается в doc-файле, сопровождающий данный проект. Если в новой итерации код заглючил – откатываюсь на предыдущую, что меня не раз выручало.
По модульности. Пример можно посмотреть в моей статье: «Модульное программирование в C++. Статические и динамические плагины» – https://habr.com/ru/articles/566864/ .Теоретически, эту идею можно использовать и в команде. Каждый участник работает над собственным, динамическим плагином, которые автоматически подгружается из папки плагинов программы. После завершения проекта командой, можно от динамических плагинов перейти к статическим, что делает её более быстрой, но монолитной.
Сейчас, вот, думаю над второй версией своей обучающей программы, которую хочу переписать в подобном, «плагино-ориентированном» стиле. Посмотрим, что получится. Если результат понравится, то, возможно, опубликую здесь.
Эта система хороша для командной работы, а я всю жизнь программировал один.
Эта система отлично подходит и для случая единственного разработчика, поскольку позволяет легко просматривать изменения, создавать бекапы, ориентироваться по истории и делать многие другие полезные вещи. И для этого даже не обязательно знать консольные команды - все можно сделать с помощью какого-нибудь современного GUI.
Однако проблема контроля версий существуют и в этом случае. Для ее решения пришлось разрабатывать собственную систему «итерационно-модульного» программирования.
Похоже на изобретение велосипеда.
Для итераций я просто копирую старый проект в новый. Условие перехода – более-менее реализованная «фича», в текущей итерации. Она описывается в doc-файле, сопровождающий данный проект.
Кажется, что это слишком трудоемко и ненадежно. Тем более если использовать doc файлы, а не обычные текстовые. Как в этом случае оценивать изменения?
Если в новой итерации код заглючил – откатываюсь на предыдущую, что меня не раз выручало.
В гите это делается элементарно. Можно легко откатиться на любой другой коммит
Эта система отлично подходит и для случая единственного разработчика
Согласен! Но, есть еще удобство работы и привычка.
И для этого даже не обязательно знать консольные команды - все можно сделать с помощью какого-нибудь современного GUI.
Дело не консольных командах, это, вообще, не проблема, а в наличии посредника. «Зачем нам кузнец? Кузнец нам не нужен!».
Единственный смысл осваивать гит, я вижу, если надумаю публиковаться на Гитхабе. Пока, еще не решил, нужно ли мне это?
Похоже на изобретение велосипеда.
Может быть, только прототип этого «велосипеда» не удалось найти, особенно, по части модульности в C++ для GUI. Судя по обсуждению под статьей, все эту модульность понимают как пакеты в Питоне, а я как плагины.
В принципе, графические плагины поддерживают многие оконные программы (доступные в бинарном виде), но, скорее, как дополнительный инструмент, чем, основной. А вот полный опенсорс на эту тему я не нашел.
Кажется, что это слишком трудоемко и ненадежно. Тем более если использовать doc файлы, а не обычные текстовые. Как в этом случае оценивать изменения?
Мне, лично, нравится! Doc-файлы просто комфортней читать, чем текстовые. В новой итерации я либо добавляю новый класс либо обработку нового события. Об этом и пишу. Если новый класс, либо один из его обработчиков заглючил, я просто возвращаюсь в предыдущую итерацию, где все работало нормально. Этот механизм достаточно эффективен, и ничего сложного я в нём не вижу.
Да, могут быть структурные изменения либо рефакторинг, но, тогда откатываюсь на подходящую итерацию, вплоть до первоначальной, при необходимости, и создаю новую «итерационную ветвь», по которой иду дальше. Например, в моем проекте, с минималистским графическим интерфейсом, загрузчика видео-файлов из «народного» видео-хостинга, рабочая ветвь составила 25 итераций, хотя программа не слишком сложная, всего лишь, надстройка над консольным загрузчиком «yt-dlp.exe» (код можно найти в моей статье, здесь: https://habr.com/ru/articles/955838/ ).
В гите это делается элементарно. Можно легко откатиться на любой другой коммит
У меня тоже, всё тривиально. Скопировал, например, папку «Main024» в папку «Main025» и работаешь, дальше, с ней, какие проблемы?
Дело не консольных командах, это, вообще, не проблема, а в наличии посредника.
Doc-файлы просто комфортней читать, чем текстовые
А использование сторонних приложений для док не является посредником?) Или это другое уже. Тот же Markdown имеет в целом неплохие возможности форматирования, чем не комфорт? И зачем эти посредники ;)
какие проблемы?
Время это проблема. Ваша текущая схема крайне затратная по сравнению с гитом, и имеет лишнюю когнитивную нагрузку. Уж про удобство работы с изменениями я молчу. Как у вас посмотреть разницу в кодовой базе между некоторыми версиями? Окей, прогоняем дифф, а если перемешение файлов было?
Единственный смысл осваивать гит, я вижу, если надумаю публиковаться на Гитхабе. Пока, еще не решил, нужно ли мне это?
Вам не обязательно именно "публиковаться". Вы на гитхабе можете хранить приватную репу чисто на случай бекапа. Окей, не хотите вообще гитхаб, можно просто использовать локальный bare репо на флешке. Да и вообще, кто сказал, вам обязательно вообще надо куда-то пушить, нам достаточно просто удобно локально работать с историей ( примечание, гит и гитхаб - не совсем одно и то же, и гитом можно пользоваться без публикации куда-либо )
Вы же не диффы храните ведь в своей системе? Значит размер кодовой базы просто умножается, когда вы делаете "новую ветку"? Гит в этом плане сильно экономнее, храня только диффы
Вообще, кажется, что гит вы даже и не пытались щупть руками, не пытались применять. Очень вам советую попробовать это сделать, потом сами же будете смеяться с вашего "удобно" ;) Пишу как человек, который занимался абсолютно идентичной бессмысленной чепухой с копипастой директории, в конце концов превращающейся в помойку, хотя казалось очень удобным ( спойлер, нет, это помойка ) и тоже думал, что одиночке гит не нужен.
А использование сторонних приложений для док не является посредником?) Или это другое уже. Тот же Markdown имеет в целом неплохие возможности форматирования, чем не комфорт? И зачем эти посредники ;)
В данном случае, doc-файл используется только для информации о текущей итерации. С таким же успехом я могу писать об этом в тетрадке, никакой разницы. Ничего не изменится, если я буду вести «дневник итераций» в Notepad++. Кстати, последний я постоянно использую, но для других целей.
Время это проблема.
Для индивидуального разработчика это не проблема. Свою работу я организую на основе здравого смысла. Появились нюансы, осмысляешь их и вносишь соответствующие изменения.
Проблема – это выбор концепции разработки. На примере своей обучающей системы «L'école», могу сказать, что уже было несколько разных версий, под разными названиями. Первые варианты были еще десять лет назад. За это время много чего изменилось в концепции, но, буквально, сегодня, пришел к её новому переосмыслению. Надеюсь, реализовать её в следующей версии. Всё остальное – мелочи!
Ваша текущая схема крайне затратная по сравнению с гитом, и имеет лишнюю когнитивную нагрузку. Уж про удобство работы с изменениями я молчу.
Мне так не кажется! У меня итерации отличаются на уровне одного модуля либо одного класса, либо, даже, на уровне одной функции. Чем чаще я их делаю, тем легче откатываться назад, просто берешь предыдущую итерацию всего проекта и работаешь с ней.
Как у вас посмотреть разницу в кодовой базе между некоторыми версиями? Окей, прогоняем дифф, а если перемещение файлов было?
Мне эта «разница» ни разу не понадобилась. Если участок кода, который я в данный момент изменял, перестал работать нормально, я просто беру этот кусок из предыдущей итерации, где всё работало нормально и прохожу его заново. Плюс система логирования, которая тоже весьма полезна. В дебажной версии программы внешние, достаточно подробные, логи формируются автоматически, а в релизной версии, логирование отключается и «наружу» ничего не выходит. Для меня очень удобно.
«Перемещение файлов» тоже не проблема. Если надо сделать их замену, то это уже повод для новой итерации проекта, «перемещение» делаю уже там, соответственно, этот процесс описываю в «дневнике итераций».
Вам не обязательно именно "публиковаться". Вы на гитхабе можете хранить приватную репу чисто на случай бекапа. Окей, не хотите вообще гитхаб, можно просто использовать локальный bare репо на флешке.
Ну, почему не обязательно? Если пет-проект создан и автору он нравится, то грех не поделиться им с обществом. Вначале это могут быть одни бинарники и данные к ним, не потому, что код – это «коммерческая тайна», а просто потому, что «первый блин всегда комом», т.е., не хочется получать лишнюю критику по качеству кода. Хотя, критику работы программы и её концепции – приветствую.
В этом смысле, «Хабр» – достойная площадка, а архивы можно хранить на «Яндекс-Диске» и на своих, бесплатных сайтах. Что я и делаю. И, пока, всё нравится!
А, когда, в новой версии, код стабилизируется и его не стыдно буде показать людям, то тогда можно будет и «опубликовать». Почему бы и да?
Вы же не диффы храните ведь в своей системе? Значит размер кодовой базы просто умножается, когда вы делаете "новую ветку"? Гит в этом плане сильно экономнее, храня только диффы
Со временем, тупиковые ветви я удаляю, хотя, не «взлетевшие» проекты могут «висеть», на компьютере, годами. «Экономить» особой необходимости нет. Так, код всех моих проектов это – мегабайты, используемые данные – гигабайты, а места на моих дисках – терабайты. Скорее, забываешь, что где находится, поскольку проекты имеют тенденцию распространятся, равномерно, по всему компьютеру. Иной раз, найдешь старый проект десятилетней давности и думаешь: «Это, что я написал? Дали бы под другим авторством – поверил бы!».
Поэтому, работал бы в команде, играл бы по другим правилам, а так, могу позволить себе «оставаться самим собой».
Вообще, кажется, что гит вы даже и не пытались щупть руками, не пытались применять.
Естественно! Я же так и написал, что раздумывал, стоит ли мне разбираться в гите или нет? Пока решил, что если надумаю работать с Гитхабом, то займусь этим, иначе, особого стимула не вижу.
Очень вам советую попробовать это сделать, потом сами же будете смеяться с вашего "удобно" ;)
Я приму это к сведению, ибо никогда не знаешь, что будет завтра? Однако, сейчас, мой «здравый смысл» противится этому. К сожалению!
Пишу как человек, который занимался абсолютно идентичной бессмысленной чепухой с копипастой директории, в конце концов превращающейся в помойку, хотя казалось очень удобным ( спойлер, нет, это помойка ) и тоже думал, что одиночке гит не нужен.
Я вас хорошо понимаю ибо у меня ситуация похожая. Только копии каталогов у меня создают не «помойку» а проблему поиска в старых проектах, которые могут располагаться «чёрт знает, где». Места хранения текущих проектов я, более-менее, помню. Соответственно, гит должен иметь дело со всеми, весьма разнородными проектами сразу, а способен ли он на это, я не знаю. Для одного проекта, необходимости в гите я пока не вижу. Как увижу, так сразу займусь им!
Только копии каталогов у меня создают не «помойку» а проблему поиска в старых проектах, которые могут располагаться «чёрт знает, где». Места хранения текущих проектов я, более-менее, помню. Соответственно, гит должен иметь дело со всеми, весьма разнородными проектами сразу, а способен ли он на это, я не знаю.
Для этих проектов можно использовать единый Git репозиторий. А если нужно иметь именно физически несколько папочек, то существует git worktree - он позволяет работать над разными ветками в разных папках, причем все это работает в рамках единого репозитория (в отличие от обычных копий). Кстати, это фича недооцененная и далеко не все про нее знают/пользуются.
Кстати, это фича недооцененная и далеко не все про нее знают/пользуются.
Здорово, конечно! Только, начинать работать с этим надо было на заре своей «компьютерной юности». Сейчас сделать ревизию все своих проектов, за многие годы – нереально. Практически, нужно брать новый чистый диск и переносить туда, постепенно, в упорядоченном виде, всю полезную информацию из старых дисков. Когда-то пытался делать подобное, однако, на это надо «бесконечно» много времени, которого, как всегда, нет. Так и живем! Порядок надо поддерживать, хотя бы, в новых проектах, что и пытаюсь делать.
Мне, лично, нравится! Doc-файлы просто комфортней читать, чем текстовые.
Это проприетарный формат, для открытия таких файлов еще нужна дополнительная программа. К тому же не текстовый - не удобно дифать. Markdown - разумный компромисс между читабельностью, и он подходит для системы контроля версий.
Дело не консольных командах, это, вообще, не проблема, а в наличии посредника. «Зачем нам кузнец? Кузнец нам не нужен!».
Тогда и посредник в виде doc файлов не нужен.
Единственный смысл осваивать гит, я вижу, если надумаю публиковаться на Гитхабе. Пока, еще не решил, нужно ли мне это?
Не обязательно куда-то публиковаться, если использовать гит.
Может быть, только прототип этого «велосипеда» не удалось найти, особенно, по части модульности в C++ для GUI. Судя по обсуждению под статьей, все эту модульность понимают как пакеты в Питоне, а я как плагины.
Может потому что он неудобный и не особо нужный?
У меня тоже, всё тривиально. Скопировал, например, папку «Main024» в папку «Main025» и работаешь, дальше, с ней, какие проблемы?
Непонятно как понять, что изменилось между версиям, файлы дублицируются, непонятные названия, в целом бардак - git решает все эти проблемы.
Да, могут быть структурные изменения либо рефакторинг, но, тогда откатываюсь на подходящую итерацию, вплоть до первоначальной, при необходимости, и создаю новую «итерационную ветвь»
Звучит как страшный сон. Вообще писать без системы контроля версий на C++ это кажется еще более страшным, чем на другом более простом языке. Там же можно случайно отстрелить себе ногу и долго разбираться, в чем же была ошибка. Откатываться на какую-то прошлую версию похоже на потерю огромного количества времени.
Спор о том нужен гит или нет равноценен спору нужен бэкап или нет.
Например, получив определенный опыт, у меня и бэкап по правилу 3-2-1 и гит с синхронизацией на Гитхаб как очередной бэкап но для кода. Хват с меня приключений.
Это проприетарный формат, для открытия таких файлов еще нужна дополнительная программа. К тому же не текстовый - не удобно дифать. Markdown - разумный компромисс между читабельностью, и он подходит для системы контроля версий.
Конечно, абстрактно, вы правы! Но, без «Ворда» и «Эксела» в мире «Форточек» – никуда! Однако, «Ворд», в моём случае, не принципиален. Могу, спокойно, заменить его на Notepad++. Markdown, думаю, больше нужен для «Линукса», чем для «Виндоуз».
Тогда и посредник в виде doc файлов не нужен.
Не нужен, согласен! Ибо никакой функциональной нагрузки не несет. Кстати, а rtf-формат вас устроит?
Может потому что он неудобный и не особо нужный?
Я не считаю C++/ WTL «не особо нужным». Для меня, это идеальное средство разработки GUI-приложений, как и Питон для обработки данных. И я очень рад, что могу позволить себе думать так, не считаясь с мнением «большинства».
Что касается модульности в C++/ WTL, то там удобно считать модулем любой объект, который взаимодействует с другими объектами по определенному протоколу, например:
– обмен сообщениям между окнами;
– клиент-серверное взаимодействие с внешними объектами, вроде, баз данных, типа Sqlite;
– использование виртуальных интерфейсов (плагины, внешние конфигурации и т.п.);
– обычное использование вспомогательных функций (но тут возникает повод думать о переносе их на другой слой кода, скажем, в родительский класс);
и т.д.
Лично я вижу во всём этом и «удобство» и «нужность».
А вы потратьте денёк. На самом первом этапе вам понадобятся 3 команды: разово git init, дальше git add и git commit. Чуть позднее разово git remote, после git pull и git push. Всё.
Потом добавите с гитом достаточно команд: git clone, git checkout (команда которая делает почти всё, сейчас, вроде, рекомендуют более узкими командами, вроде git switch пользоваться но не суть), git branch, git merge. Этого, пожалуй, достаточно для работы что одному, что в команде.
Научиться работать с ними не долго. Навык потом прилипает, примерно как навык езды на велосипеде. Жизнь упрощает, радикально, из возможных проблем, нужно уметь не коммитить ключи и пароли.
Всякие штуки по переписыванию истории... если вы боитесь и вам не очень надо, вам не очень надо. Если очень надо, разбираетеесь и уже не боитесь, но соблюдаете осторожность. Но в реальности, вам не очень надо. Не знаю с чем это связано, но есть люди, которые как то легко воспринимают операции по работе с историей, и те, которые даже смотреть в эту сторону боятся, что на остальной работе сказывается скорее никак. Так что можете выучить необходимый минимум, и жить спокойно.
долго думал, надо ли мне разбираться с гитом?
Тоже долго думал, нужно ли мне учиться пользоваться колесом. Пока просто ношу вещи на руках. В моём случае работает, но иногда хочется посмотреть, что там человечество за тысячу лет навертело.
Классно, в папочках довольно удобно работать, чем всё изменять в одной папке. А папочки дают историю разработки и возможность вернуться к предыдущей версии. Удобно.
Но иногда не хватает названия папки для отличия других версий - ведь имя папки может быть только одной строкой, и некоторые символы запрещены. А ведь можно сделать маленькую папку, и там в файлике хранить расширенную информацию о только что созданной папки с версией кода. О! Туда можно добавить ещё метаданные типа даты создания папки (ведь виндовская (системная) дата не всегда удобна), и написать, от какой версии (папки) создал эту папку.
А для удобства сделал маленькую программку, которая это делает, прям в консоли, одной командой от текущей папки.
Сделал, классно! Очень нравится, ведь это то же самое, что и было, плюс служебная папка с описанием папок.
А ведь теперь можно сделать поиск по описанию папок, которые теперь в этой служебной папке хранятся! Можно, сделал, очень удобно, можно сказать - уютно! Как же я сам не додумался раньше?
Запарился вспоминать, в какой папке у меня текущая версия, в которой работаю. Давай сделаю малюсенькую программку, которая из текущей папки будет копировать проект в папку с названием current. Нет, давай назовём trunk!
Вот теперь всё отлично! Можно теперь плотно работать над проектом! Но что-то свербит в памяти, что-то я такое где-то слышал... Вспомнил! Я сделал систему управления версиями SVN! Блин! Я стал как все! Всё, удалю все эти программки, вернусь к обычным папочкам! Ведь так удобно было, лампово!
Я стал как все!
Понятно, о чём вы говорите. Есть же принцип, не трогай программу, которая работает! Тоже можно сказать и о «системе контроля версиями» ПО. Вещь, в принципе, полезная и нужная. Но, если ничего не «свербит в памяти» и не зудит в других «пикантных местах», то, зачем искать себе лишние проблемы? Тимлида над головой нет, техдолга – тоже. Никто в шею не гонит, руководствуюсь исключительно здравым смыслом. А он подсказывает, что «всему – свое время!». Понадобился Питон, для обработки данных – освоил. Возникла необходимость использовать расширения Хром и JS – использовал и весьма эффективно. Заинтересовали оффлайн-модели Vosk по распознаванию речи – применил. Увлёкся китайской библиотекой DuiLib – разобрался! И т.д. и т.п. Т.е., я хочу сказать, что мне много раз повторять не нужно. Услышал, краем уха, интересную информацию – принял к сведению. Возникла подходящая ситуация по ее применению – применил! В этом и состоят нехитрые принципы использования «здравого смысла». Делать все по необходимости, а не «искусства, ради».
Вместо git push --force лучше всегда делать git push --force-with-lease. В чем разница? Допустим вы с Васей работаете над одной общей веткой и хотите исправить текст нового коммита, который вы только что отправили, но если Вася в это время отправил свой коммит, то git push --force просто молча выкинет его коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда как git push --force-with-lease запрещает переписывание ветки, если там есть новые чужие коммиты. Я лично использую алиас git pf.
Еще одна совершенно пустая мусорная статья на Хабре. Ждем в 26 году серию статей "как пользоваться тарелкой", "как пользоваться чашкой" etc?! Нуачо, особенно если там ИИ-ассистент будет — даже тематично для сайта. Ксюша, перед тем, как писать и публиковать подобноную дисиллированную воду, я, старый ворчун, рекомендую вырасти в самоощущении хотя бы Ксении, тогда будет проще понимать, чем стоит заниматься, а что само пройдет.
PS: даже не вторичный, а третичный продукт переработки не интересен совершенно, в нем нет никакой добавленной ценности
Классная тут команда собралась. Одна статью про гит, другой про велосипед из копий проекта. Скоро действительно будут статьи про использование монитора
Гид по Git — глазами бывшего джуна