Pull to refresh
  • by relevance
  • by date
  • by rating

Постигаем Git

Website development *Git *Version control systems *
Translation
От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.
Читать дальше →
Total votes 126: ↑120 and ↓6 +114
Views 54K
Comments 91

Ежедневная работа с Git

Git *Version control systems *
Tutorial
Я совсем не долго изучаю и использую git практически везде, где только можно. Однако, за это время я успел многому научиться и хочу поделиться своим опытом с сообществом.

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:
  • можно ли git «подстроить» под тот процесс разработки, который мне нужен?
  • будет ли менеджер и заказчик удовлетворён этим процессом?
  • будет ли легко работать разработчикам?
  • смогут ли новички быстро включиться в процесс?
  • можно ли процесс относительно легко и быстро изменить?


Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Далее очень много букв случайным образом превратились в пост.
Total votes 200: ↑194 and ↓6 +188
Views 809K
Comments 44

Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение

Badoo corporate blog Website development *IT systems testing *

В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.

О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.
  • GIT Workflow. Каждая задача в отдельной ветке;
  • Использование JIRA, TeamCity и AIDA;
  • Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).
Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.
  • Что мы используем;
  • Как гоняем тесты;
  • Code Coverage;
  • Пускалка. 18000 тестов за 3,5 минуты.
Девелоперское окружение в команде, разрабатывающей сложную распределенную систему
И рекомендации от ребят: полезные книги, статьи и т.д.

Читать полностью
Total votes 121: ↑92 and ↓29 +63
Views 41K
Comments 41

Вливание legacy-истории в дерево: нахождение оптимальной точки ответвления

Git *Version control systems *
По долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:

  • было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
  • конкретные инсталляции делались путем:
    • в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
    • в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте

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

Знакомо?
Total votes 15: ↑15 and ↓0 +15
Views 4K
Comments 1

Изменение коммитов в Git

Git *
Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».
Читать дальше →
Total votes 94: ↑80 and ↓14 +66
Views 231K
Comments 21

Правильные способы исключения файлов в Git

Git *
Иногда встречаю в файле .gitignore то, чего там быть никак не должно. Например, папка .idea, в которой лежат конфиги известных IDE от JetBrains. Это часть вашего рабочего окружения и она никаким боком не относится к проекту и репозиторию. Если над проектом работает несколько человек и каждый из них добавит конфиги своего окружения в .gitignore, то он превратится в нечитаемую помойку.

В этом топике я расскажу о правильных способах исключения файлов и о том когда какой способ использовать.
Читать дальше →
Total votes 98: ↑74 and ↓24 +50
Views 197K
Comments 68

3 режима команды git reset: --soft, --mixed(по умолчанию), --hard

Git *
К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.
Читать дальше →
Total votes 75: ↑64 and ↓11 +53
Views 215K
Comments 15

Tig — консольный GUI для Git

Git *
Никогда не был фанатом gitk и пользовался им редко, предпочитая консоль и настроенные алиасы. Благодаря хабраюзеру grossws, я открыл для себя tig. Это то, чего мне не хватало. После месяца использования его в работе хочу поделиться находкой с вами.

Tig это консольный GUI(TUI) для Git, основанный на Ncurses.
Основные преимущества:

  • потрясающая скорость, 20,000 коммитов готовы к просмотру за четверть секунды
  • консольный
  • управление в vim стиле

Cкриншоты основных режимов и сравнение с gitk.
Читать дальше →
Total votes 64: ↑60 and ↓4 +56
Views 36K
Comments 46

Наконец-то полноценный контроль версий для дизайнеров!

GitHub
Вчера Github объявил о поддержке PSD в дополнение к текущим графическим форматам. Появился отличный повод облегчить жизнь дизайнерам и фронтэндщикам, очень надеюсь на понимание первыми необходимости и приобщение.
Ссылка на новость в блоге гитхаба.
Total votes 37: ↑23 and ↓14 +9
Views 15K
Comments 19

Работа с Git без использования локальных веток

Git *
Sandbox
Прочитав очередную статью про Git, я просто не мог не описать свой подход к решению вопроса, не претендующий на особую оригинальность. Я уже последний год успешно пользуюсь гитом, создавая минимум локальных веток. Не буду настаивать на том, что так делать правильно или неправильно — просто делюсь опытом. А для всех, кому интересно «как» — прошу под кат.
Читать дальше →
Total votes 12: ↑5 and ↓7 -2
Views 10K
Comments 15

GitLab Flow

Softmart corporate blog Git *Version control systems *
Translation

Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:




Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:


  • Не описан точным образом весь рабочий процесс,
  • Вносится ненужная сложность,
  • Нет связи с трекером задач (issue tracker).

Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:



Читать дальше →
Total votes 29: ↑29 and ↓0 +29
Views 75K
Comments 21

Серия видеоуроков по Git для новичков

Git *GitHub
Tutorial
Скорее всего, если вас привлекло название статьи, то вы начинаете свой путь знакомства с системой контроля версий Git. В данной статье я приведу 10+ видео о пошаговом вхождении в контроль версии используя Git. Данного курса будет вполне чем достаточно для работы с такими популярными сервисами как GitHub и Bitbucket.

Однажды мой знакомый, который только начинал свой путь в ИТ кинул мне данный мемчик что слева, с вопросом "А чем плохо то?", поэтому чтобы понимать данную шутку и уметь работать с самым популярным на сегодня VCS (Version Control System) рекомендую к ознакомлению серии видеоуроков, которую я привел ниже.
Читать дальше →
Total votes 58: ↑49 and ↓9 +40
Views 106K
Comments 43

Для чего программисту Continuous Integration и с чего начинать

Git *Version control systems *GitHub Build automation *DevOps *
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Читать дальше →
Total votes 58: ↑52 and ↓6 +46
Views 50K
Comments 56

GitLab для Continuous Delivery проекта на технологиях InterSystems

InterSystems corporate blog Git *Version control systems *GitHub Development Management *
Tutorial

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.


Рассмотрим такие темы как:


  • Git 101
  • Методологии разработки (Git flow)
    • GitHub flow
    • GitLab flow
  • GitLab
  • GitLab CI
Читать дальше →
Total votes 18: ↑18 and ↓0 +18
Views 11K
Comments 3

GitLab для Continuous Delivery проекта на технологиях InterSystems: Контейнеры

InterSystems corporate blog Git *Version control systems *GitHub Development Management *
Tutorial

Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.


Рассмотрим такие темы как:


  • Контейнеры 101
  • Контейнеры на разных этапах цикла разработки ПО
  • Continuous Delivery с контейнерами
Читать дальше →
Total votes 19: ↑17 and ↓2 +15
Views 6.1K
Comments 6

Введение в Git

Git *Version control systems *
Tutorial

Оглавление


Предисловие
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).
Читать дальше →
Total votes 40: ↑34 and ↓6 +28
Views 82K
Comments 27

Переписывание истории репозитория кода, или почему иногда можно git push -f

FUNCORP corporate blog Programming *Git *


Одно из первых наставлений, которое молодой падаван получает вместе с доступом к git-репозиториям, звучит так: «никогда не ешь жёлтый снег делай git push -f». Поскольку это одна из сотен максим, которые нужно усвоить начинающему инженеру-разработчику ПО, никто не тратит время на уточнение, почему именно так нельзя делать. Это как младенцы и огонь: «спички детям не игрушки» и баста. Но мы растём и развиваемся как люди и как профессионалы, и однажды вопрос «а почему, собственно?» встаёт в полный рост. Эта статья написана по мотивам нашего внутреннего митапа, на тему: «Когда можно и нужно переписывать историю коммитов».
Читать дальше →
Total votes 51: ↑48 and ↓3 +45
Views 14K
Comments 31

Поддерживаем разработку нескольких версий продукта в Git. Станислав Лукьянов (GridGain)

Git *Version control systems *IT Standards *Development Management *DevOps *


Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.

Total votes 16: ↑16 and ↓0 +16
Views 4.6K
Comments 2
1