Комментарии 10
Про ребейз я так и не понял - что в деталях делает эта операция. В примере произведена подмена терминологии: текущая и целевая ветка на: основная и новая; а термин ребейз заменён на слияние Что т там с коммитами D и Е не понятно. Почему пропадает коммит E? Вообще в картинках явно есть серьёзный огрех: все узлы отображаются одинаково и трудно отличить коммит от чего-то ещё!
Остался непонятным вопрос и того, как несколько людей работают над одной веткой и решают конфликты коммита изменения одного и того же объекта?
Так же остался непонятым процесс мерджа - понятно, что в этом процессе посути данные из одной ветке (или нескольких веток) переносятся в другую ветку? Но что делать дальше с исходными ветками? Чаще всего они нуждаются и в обратном мердже? Это так же надо делать отдельно? И ещё раз выполнять весь процесс слияния , в т.ч. обрабатывать все конфликты (и не говорите что их никогда не будет в этом случае)?
Наверное ещё много чего осталось мной не понятно о чём я не понимаю как спросить или стесняюсь своей неграмотности в этом вопросе. Для новичков статья плохо подходит, на мой взгляд (а я хоть с Git и не работал, но с системами версионирование работаю уж как лет 20)
Сколько читаю статьи о гите - все они или крайне недостаточны, или чрезмерно избыточны. При том есть масса вариантов работы с гитом, которые используют разные команды. Есть по ветке на каждый чих (фичу), если с отдельными именными ветками, мигрирующими через тестовую в релиз. Есть черри-пики, которые пробрасываются с тестовой ветки в релиз, с которыми геморроя часто больше, чем с полными мерджами. Есть когда все кидают в мастер-ветку сразу и тестят на ней, после чего принимают решение об очередном релизе. И временами кажется, что блокировочник (когда файл блокируется для изменения для всех остальных разрабов) не хуже в большинстве случаев внутренней разработки. А если у вас команда в тыщу разрабов - то да, гит тут рулез форева...
Лично мне концепция мерджей больше нравится, чем блокировка (я вообще не сторонних процесса блокировок где-бы то ни было - я за параллельность и свободу работы). Но так как я с не работал с Git - то не понимаю некоторых тонкостей
По-сути блокировка - это захват файла(ов). Поменял - выложил. Выкладывание - это фактически "полный мердж"- замена файлов в хранилище с сохранении истории.
и что с того
С того то, что отличий для небольшой команды минимум при почти полном отсутствии проблем с разруливанием конфликтов.
Ну, Git, для небольшой команды, может показаться, что и не особо нужен. Но тут, скорее вопрос в современных тенденциях, и освоить Git стоит пораньше, потом просто будет сложнее на него перейти.
Ну и даже для небольших команд некоторые фишки Git - например, многоветочность, - очень даже будут полезными. А мерджи очень хороши в случае когда в проекте есть, условно говоря, сторонние библиотеки в исходниках - которые периодически нужно обновлять, и в которые тоже вносятся изменения хоть командой, хоть даже одним программистом по месту их потребления!
А вот, за что минус выше поставили - я так и не понял!
Английские слова не склоняются. Не пытайтесь прикрутить к ним дополнительные окончания ни через дефис, ни через апостроф. Фраза «применение git'a» звучит так, будто вы пытаетесь изобразить икоту. А ещё надо помнить, что названия в английском всегда пишутся с заглавной буквы. Поэтому если мы говорим про систему управления версиями, то скажем «применение Git». Если непременно хочется просклонять слово, то и пишите его русскими буквами — «применение гита» — так тоже нормально.
Сложносоставные слова с несклоняемой первой частью напротив пишутся через дефис: Нон-фикшен-литература, Wi-Fi-роутер, Internet-кафе, онлайн-опрос, Web-браузер...
Нет смысла использовать термин «Мердж-коммит», так как merge переводится нормальным словом «слияние», а merge commit это просто «коммит слияния», merge conflict — «конфликт слияния».
Чекаут (checkout) — переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита.
Тут вы путаете сам репозиторий и его рабочий каталог. Репозиторий хранит историю всех состояний проекта. Чекаут это распаковка некоторого состояния проекта в рабочий каталог. Изменяются именно файлы в рабочем каталоге, а не в репозитории. Сам репозиторий содержит сущности, которые неизменяемы.
Ребейз (rebase) — перенос изменений текущей ветки «поверх» другой ветки.
Rebase (ребейз, перебазирование) — это пересборка некоторой цепочки коммитов на другой базовый коммит, с последующей перестановкой указателя ветки на вершину новой цепочки. Старая цепочка коммитов никуда не исчезает и у других членов команды ветка продолжит указывать на старую цепочку и поэтому начинаются сложности.
Перевод слова remote как «удаленный» не очень подходит в контексте гита. Получаются странные формулировки типа «удалить удаленный». Лучше говорить «внешний».
Есть локальный репозиторий и внешние репозитории по отношению к нему. Локальные ветки можно связать с их вышестоящими ветками во внешних репозиториях. При этом можно создать две разные связи, одну для получения изменений (fetch), другую для отправки (push). Но это не обязательно — мы всегда можем явно указать что и куда сливать.
Pull это два действия в одной команде. Внутри там делается сначала Fetch (получение всех обновлений) затем делается слияние какой-то ветки в текущую ветку методом merge, либо методом rebase, в зависимости от настроек гита, либо параметров самой команды pull.
Раскладываем Git по полочкам: терминология