Курсы по программированию

Формула программиста
основатель — Волосатов Евгений Витольдович
Шаблоны Проектирования / Java

Git Hub / Merge

  • На этом уроке мы продолжаем работу с ветками.
    Сравним разницу между ветками относительно друг друга.
    У нас появилась необходимости слияния ветки scanner
    с основной веткой, в этот раз мы рассмотрим вариант
    когда процесс слияния запущен из основной ветки.
    Исправим возникший конфликт при слиянии.
  • Дата отправки отчёта: вчера в 16:34
  • Задание выполнено: за 15 мин.
  • Чему научился: Ничему
  • Что было сложным: найти время
  • Комментарии: Хороший урок, но данная последовательность мержа между ветками не приемлема в командной работе, так как ветка master основная, при большом потоке коммитом нельзя, чтобы эта ветка тратила время на фикс мержей, этим занимаются каждый, кто хочет отправить коммит или целую ветку, они вначале доводят до актуального состояния свои наработки, а потом отправляют на рассмотрение в основную ветку, если всё ок, то коммит одобряют и слияние проходит моментально, если же что-то не то, можно будет в реальном времени дорабатывать и как только ваш запрос будет актуален и подходить по всем фронтам, его одобрят и закоммитят. Как видно на скриншоте, я перешёл в ветку scanner, запустил мерж оттуда, чтобы ветка scanner стала актуальна ветке master и если возникают конфликты, то именно человек, который занимается веткой scanner исправляет конфликты исходя из логики его нововведений, после чего создаётся ещё один коммит, который как бы шлифует ветку, чтобы она не конфликтовала с изменениями основной ветки master. После того как переключился на ветку master и запустил команду "git merge scanner" всё прошло идеально. На скриншоте так же видно, что после того как слияние прошло успешно, HEAD находится над обеими ветками одновременно, потому что их индексы последних коммитов совпадают, чего небыло при фиксе конфликтов в ветке master на видео, там ветка scanner оказалась позади после окончательного слияния.
  • Оценка видео-уроку:
Отчёт от 10558 за Git Hub / Merge


Отчёт от 10558 за Git Hub / Merge




Оцени работу

 
Сохранить страницу:

10558. Иван Воронин
Иван Воронин
ответить
→  Сергей Соколов  # Git Hub / Merge / 2017-01-22 02:09

В этом курсе пока что только базовые знания предоставлены, при разработке в команде есть ещё некоторые фишки, которые помогают удобнее распределять задачи между разработчиками и ещё удобнее контролировать каждую ветку, которую ктолибо разрабатывает и хочет, чтобы она попала в master. Отличная штука, этот гит, всегда можно посмотреть, кто что в той или иной ветке делает, можно прокомментировать любую строчку, задавая вопросы, обсуждать идеи, когда ветка полностью будет готова и она подходит по смыслу для ветки master, её простым движением руки подтверждают и она становится частью основной ветки, а человек, который занимался разработкой данной ветки, становится один из разработчиков проекта, это всё указывается на сайте в виде удобной статистики.


10558. Иван Воронин
Иван Воронин
ответить
→  Алексей В.  # Git Hub / Merge / 2017-01-22 02:04

Спасибо, да, очень много лет проб и ошибок, а с лета 2015 года начал активно принимать участие в разработках, где общение на английском, а люди в команде из разных стран, основатели проекта из Германии.


10670. Сергей Соколов
Сергей Соколов
ответить
→  Иван Воронин  # Git Hub / Merge / 2017-01-21 22:58

Спасибо за такой подробный отчёт. В командной работе наверное действительно правильнее так как ты написал!


10494. Алексей В.
Алексей В.
ответить
→  Иван Воронин  # Git Hub / Merge / 2017-01-21 22:52

Отлично, Иван. Чувствуется, что давно работаешь с этой программой.


10558. Иван Воронин
Иван Воронин
ответить
# Git Hub / Merge / 2017-01-21 16:35

Залил второй скрин, чтобы показать, на сколько конфликт меньше размером и более понятный, минимальные корректировки получаются, если всё делать правильно, git помогает правильно формировать строки кода =)


10558. Иван Воронин
Иван Воронин
ответить
# Git Hub / Merge / 2017-01-21 16:08

Обычно, после того как ветку слили в основную, она удаляется, иногда появляются новые идеи и её начинают дорабатывать и повторно отправлять на слияние, именно в той последовательности, что я реализовал, это не составит труда, а вот если бы фиксы исправили в ветке мастер, потом использование ветки scanner было бы головной болью, так как она не знает, как было всё исправлено и при попытке обновления ветки scanner до актуальности, опять надо было бы фиксить ошибки, которые породили бы ошибки, короче, лишние коммиты, которые никому не нужны и только вводят в заблуждение, ведь уже это было исправлено ранее в основной ветке, а потом ветка scanner внесёт эти фиксы и не факт, что опять не будет конфликта, можно провести эксперимент, но опыт уже был, не думаю что с тех пор git стал умнее, в любом случае, лучше придерживаться правилам, сэкономите много нервов =)


  • Отчёт оценивали:
    10558Иван Воронин+1   1Евгений Витольдович+1   12301r2d20   6925Артём+1   10494Алексей В.+1   10670Сергей Соколов+1   459Сергей Сергеевич+1   791Валерий+1   6452Lik_Kirill+1   12393Артур0   1901Neverwinter 2+1  

Начинаем практику по языку C#




Чтобы стать хорошим программистом — нужно писать программы. На нашем сайте очень много практических упражнений.

После заполнения формы ты будешь подписан на рассылку «C# Вебинары и Видеоуроки», у тебя появится доступ к видеоурокам и консольным задачам.

Несколько раз в неделю тебе будут приходить письма — приглашения на вебинары, информация об акциях и скидках, полезная информация по C#.

Ты в любой момент сможешь отписаться от рассылки.
Научился: git merge *branchname* Объединять *вручную* выбирая среди конфликтующих строк какие изменения войдут в итог слияния.
Трудности: Было интересно.
С помощью системы гит можно попытаться разобраться в путешествии во времени.
Научился: Научился делать merge
Трудности: ничего
отличный курс появился. Я узнал как работать с git коммандами. Теперь лучше буду понимать что происходит даже если буду использовать графический интерфейс.