С нуля до Junior DevOps в 2026 году. Часть 3. Git и GitHub

[Emelian]

Представьте небольшую команду из двух разработчиков.

А если представить команду из нескольких разработчиков, которые делают одновременно несколько разных проектов, тогда один разработчик занимается (несколько делим на несколько – получаем единицу!) только одним проектом. Получается, что тогда Гит ему не нужен?

Другими словами, если я один пишу пет-проекты под «Форточки», на MS VS C++ / WTL, то вполне обхожусь без Гита уже много лет и если страдаю, то только из-за лени организовать порядок в бесконечной куче своих поделок. Это касается и скриптовых языков, которыми пользовался ранее и сейчас. Разных одноразовых скриптов было сотни, если не тысячи, но общее ядро кода если там и было, то все равно «плавающее», хотя и изменяющееся не так быстро, как одноразовый код.

В общем, Гит – вещь хорошая, когда тебя – больше одного, а когда ты один, то им можно и пренебречь…

[amaksr]

В общем, Гит – вещь хорошая, когда тебя – больше одного, а когда ты один, то им можно и пренебречь…

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

[Nyanny]

Ну "git init" - недостаточно.

Я буквально видел однажды студента, который сделал когда-то git init и серьезно считал, что он использует git. git add и gut commit ни разу не было сделаны.

[Emelian]

возможность посмотреть историю или откатиться часто оказывается очень полезна

Ну, любую задачу, не только в программировании, можно решать разными способами. Гит берет на себя организационную работу, но, не всегда это нужно. Мне удобней самому контролировать свои проекты. Для этого я использую итерационно-модульное программирование. Вот, допустим, мой проект создания графической обёртки для консольного загрузчика ( https://habr.com/ru/articles/955838/ ) занял 24 итерации. Напортачил в n-ой итерации, перешел на n-1 итерацию и продолжил ваять проект дальше. Новый проект можно начать не с первой итерации, а с m-ной итерации какого-нибудь прошлого, подходящего проекта. В каждой итерации описана суть полученных результатов и имеющихся проблем. Очень удобно. Пользуюсь этой системой много лет и не жалуюсь.

[Rive]

1) Если регулярно бэкапить свои проекты на удалённый репозиторий, гит тоже полезен.

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

3) Как только появляется удалённый сервер, для синхронизации с ним нужен какой-то инструмент. Кто-то обходится и Файлзиллой, но можно просто настроить синхронизацию по скрипту (будь то git, scp, sftp или что-нибудь ещё).

В целом гит - это реакция на большую сложность окружения. Если это краткосрочная задача для соло разработчика на одной машине, гит скорее бесполезен.

[Emelian]

Если это краткосрочная задача для соло разработчика на одной машине, гит скорее бесполезен.

У меня задачи не краткосрочные, даже если они одноразовые. Другое дело, задачи разные, их накопилось много за много лет, и распихались они по компьютеру, как Бог на душу положил. Бывает, просто, что-то найти очень тяжело. Систему распределения задач по каталогам и дискам, я так и не разработал за много лет. Если бы это была общая задача, то смотрел бы в сторону Гит, но задачи, по большей части, не связаны между собой. Плюс огромные накопленные массивы данных из Интернета. И выбросить жалко, как чемодан без ручки и нести тяжело. Зато иногда, случайно, находятся какие-то жемчужины информации, которым уже по 15-20 лет.

В общем, информационный перегруз. Как с этим бороться, я не знаю. Когда-то, купил 2-х терабайтный внешний USB-3 диск. Вот, думаю, сейчас создам на нем систему каталогов, куда постепенно буду переносить всю накопленную информацию из жестких дисков компа. Ага! Щас! В итоге, бардак как был, так и остался на жестких дисках, а теперь, вот, проявился и на новом внешнем диске.

[sergey-kuznetsov]

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

[Emelian]

Основное преимущество работы с гитом это отслеживание истории вашей работы.

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

[itdv]

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

[casablanque]

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