Как правильно мержить ветки в git?

Question

[nepster-web]

Напоролся на такую ситуация, у меня есть проект к примеру он состоит из 2 частей. Я создал 3 ветки, в результате получилось так:
test1- для примера эта ветка работает с 1 частью
test2 - а эта ветка работает со 2 частью приложения
development - это общая ветка, в которую мы мерджим все изменения и устраняем конфликты
master - основная ветка.

Теперь ситуация, к примеру я работаю с веткой test1 вношу изменения, добавляю фитчи и тп. Потом так же делаю с веткой test2. Вот настало время когда мне нужно обновить проект. Я хочу слить ветку test1 и test2 в ветку development , убедиться, что все действительно работает и обновить мастер.

Когда я сделал это, я наткнулся на ряд неприятных моментов с которыми не смог разобраться. Итак конкретный пример:
- в test1 я создал файл index.php
- дальше я перешел (git checkout development) в ветку разработки
- и попытался смержить: git merge test1

Теперь этот подлый index.php пропал из test1 и появился в development. Это так и должно быть?
Теперь я хочу продолжить разработку в test1, а у меня нет моего inde.php что делать?

Объясните пожалуйста как правильно мерджить ветки. Вот это дело вычитал в доках, но не понял почему так вышло.

Answer 1

[EXL]

Зачем разные части одного проекта помещать в отдельные ветки? Кажется, у вас неправильное представление смысла веток, которые используется в Git'е. Ветка в этой DCVS -- это всего лишь указатель на состояние рабочего каталога. И реализовать Work Flow, описанный вами на ветках Git'а не то чтобы сложновато, но зачем и для чего мучить бедный Git, который при каждом

git checkout
будет вам разворачивать поддерево то одного проекта в ваш рабочий каталог, то другого. Это во-первых, жутко неоптимально с точки зрения той же производительности, а во-вторых вы так совсем запутаетесь, тем более раз вы ещё включили в рабочий процесс слияния между этими ветками. Конфликтов слияния и трудностей таким образом можно достигнуть множество. Пожалуйста, обратите внимание на работающие подходы, используемые для разработки с использованием Git:

Если в ваших частях проекта выражена очень разная функциональность, то можно создать два отдельных репозитория (к примеру, fronted и backend), а затем, при необходимости, соединить их в один Git-суперрепозиторий в качестве его подмодулей.

Если одна часть -- зависимость от другой, то следует подключить эту зависимость submodule'ем или вообще поддеревом (см. главу 6.7. из книги Скотта Чакона - Pro Git).

Если это всё же монолитный проект, имеющий две части, например, первая часть содержит реализацию логики приложения в "./src/core", а вторая -- пользовательский интерфейс в "./src/ui", то их и вовсе не нужно разделять.

Answer 2

[evnuh]

Снова вы :)
Запомните - единица, с которой работает git - это коммит. Любое изменение в репозитории либо закомиченно, либо висит в активных изменениях. Поэтому git не мог удалить у вас файл, не сделав коммит :) Поищите по истории в каком из коммитов (в том числе и merge-коммитах) он мог удалиться.

А вообще вы явно что-то путаете, потому что checkout приводит вашу рабочую папку в состояние этой ветки, поэтому как вы могли понять что файл удалился из ветки test1, когда находитесь в ветке development - непонятно. После git co dev && git merge test1 сделайте git co test1 и скажите что происходит.

Да, и merge не удаляет изменения, а просто применяет все коммиты из одной ветки в другую.

Comments

[nepster-web]

Та да, не получается пока освоить гит для дальнейшей работы. =(

Вот я не все знал про checkout. По поводу удаленного файла, походу коммит не сделал в 1 из веток. Я начал на боевом проекте тестировать в результате чего все запорол =).

Подскажите пожалуйста еще такой момент.
Вот я разрабатываю в test1, к примеру ветка test1 будет посвящена модулю комментариев. Вот я его закончил и переходу в ветку test2 к примеру это админка. Вот у меня появляется мысля сделать например кнопку спам для комментариев. Что мне нужно сделать ? git checkout test1, разработка и мержить ветку с dev? Но если дев уже была слита с test2, а мы начудим лишнего.

Вот тупо в голову не лезет описание из доков. Нужен боевой пример.

[Tyranron]

Еще раз:
Коммит - это снапшот (слепок) всех файлов, добавленных в репозиторий (идентифицируется однозначно хешом).
Репозиторий состоит из последовательности коммитов.
Ветка или тег - всего лишь указатель на конкретный коммит.
Всё, это вся идея.

Таким образом, используя checkout, Вы просто переключаетесь на определенный слепок файлов, идентифицируя его по хешу коммита/ветке/тегу. Если Вы что-то не закоммитили и переходите в другую ветку, изменения потеряются, но git должен об этом предупредить.

Вообще, если уж Вы имеете дело с PHP, для наглядности советую воспользоваться PHPStorm'ом. Там примитивная, но достаточно неплохая поддержка git внутри IDE. Например, файл проекта будут выделен зеленым, если это новый файл, добавленный в проект, но еще не закоммичен, синим, если уже существующий файл изменен, но изменения не закоммичены, просто белым, если файл закоммичен и не изменялся с момента последнего коммита (или игнорируется репозиторием, например через .gitignore) и красным, если файл в папке есть но не добавлен в репозиторий вообще. Таким образом Вы больше не допустите ситуаций, что у Вас что-то не закоммичено или не добавлено в репозиторий перед тем как Вы хотите переключится на другую ветку, так как Вам будет наглядно видно что у Вас есть и в каком состоянии без дополнительных комманд с Вашей стороны. К тому же PHPStorm предлагает дополнительные возможности, например, запомнить сделанные в ветке изменения при переключении в другую, а потом при переключении обратно в первую, он их восстановит. Также PHPStorm имеет очень наглядный, понятный и удобный git log, который не позволит запутаться в коммитах. И самое главное - очень удобный diff для решения конфликтов.

Касательно Вашего момента:
Да, git checkout test1, разработка и мерджить с dev. Если Вы уже вливали test2 в dev, до этого, то ничего страшного в этом нет, это вполне штатная ситуация, git все сольет как надо, а что не сможет, выдаст Вам в виде конфликта, который нужно решить.

[evnuh]

@nepster09 в общем, вот вам нормальный рабочий процесс под которым работают все команды (называется github flow): https://guides.github.com/introduction/flow/index.html

Его суть описывается следующим:
есть всегда одна рабочая ветка (dev, например)
захотели сделать новую фичу - ответвились от dev, назвали её по названию фичи (comments, нарпимер) и хреначите в ней все, что связано с комментариями. Если у вас админка совсем не связана с сайтом (плохо), то она должна лежать в другом репозитории, а не в другой ветке. Хорошо когда админка и сайт всегда вместе. Тогда вы код и для админки и для сайта будете писать в одну ветку comments и при желании сможете откатить эту фичи (и не случится, что в админке комменты остались, а на сайте - нет).
Когда закончили функционал комментов - либо мержите ветку в dev и удаляете, либо делаете PR (красивше и типа для код ревью, но его не всегда есть кому проводить).

[nepster-web]

понял, походу дошло. Спасибо.