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

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

Утро среды.
Вы медленно открываете meet/slack/rocket/etc и нажимаете на кнопку "📞"
Имена людей в групповом звонке вам давно известны. Слова, произносимые людьми вам тоже, кажется, известны. Но что-то было вами забыто, что-то очень важное, что будет так нужно вспомнить в тот момент, как очередь доберется по вашу душу.
Через окно солнце щекочет экран монитора, заставляя вас отклоняться то вправо, то влево, дабы увидеть символы на мониторе. На крутом подоконнике журчат жирные голуби, а над вами сверлит до боли {любимый} сосед.
Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.
Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.
Эта статья заставила меня поразмыслить и о других настройках git config, вероятно, не известных широкому кругу пользователей. Возможно, для этих настроек стоит задать по умолчанию иные значения, чем действуют сейчас.

Представьте ситуацию: вы нашли критический баг в проекте, исправили его в feature-ветке, но до полного слияния ещё далеко. Или вам срочно нужно перенести одно конкретное изменение из текущей ветки в другую. В таких случаях git cherry-pick становится вашим секретным оружием.
Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература
Git — самая популярная распределённая система контроля версиями.[1][2]
Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).
Эта статья для тех, кто имеет по крайней мере базовые знания и навык работы с git и желает расширить свои знания.
Здесь рассматриваются только технические аспекты git'а, для более подробного погружения в философию git'а и его внутреннюю реализацию, советую прочитать несколько полезных книг (см. Рекомендуемая литература).Читать полностью »
Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.
Рассмотрим такие темы как:
В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.
Рассмотрим такие темы как:
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.

Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Читать полностью »

Скорее всего, если вас привлекло название статьи, то вы начинаете свой путь знакомства с системой контроля версий Git. В данной статье я приведу 10+ видео о пошаговом вхождении в контроль версии используя Git. Данного курса будет вполне чем достаточно для работы с такими популярными сервисами как GitHub и Bitbucket.
Однажды мой знакомый, который только начинал свой путь в ИТ кинул мне данный мемчик что слева, с вопросом "А чем плохо то?", поэтому чтобы понимать данную шутку и уметь работать с самым популярным на сегодня VCS (Version Control System) рекомендую к ознакомлению серии видеоуроков, которую я привел ниже.
Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:
Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:
Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему: