Представьте, что у вас два грузовика. Сначала они были одинаково пусты, потом вы загрузили в один грузовик пару мешков с песком, а в другой - мешок с углем.
Условно первый грузовик - master, второй - dev.
git checkout master
git merge dev
Теперь в master у нас мешки с песком и мешок с углем
А в dev, как и прежде, только мешок с углем.
Так что у вас не только те папки, которые в development, но и те, которые были в master.
Если вы пушили ветку development, то при clone она тоже должна была стянуться, просто на данный момент git смотрит на master. Напишите git status чтобы проверить, в какой вы ветке, и переключитесь на нужную.
Если ветки development нет, сначала вам предстоит её запушить.
В случае, если в двух ветках разные файлы (не противоречащие друг другу), то merge просто размещает их все вместе, как будто вы скопировали файлы из одной ветки в другую.
Но если в двух ветках в файлах с одинаковыми именами разное содержимое, выполняется auto-merging, т.е. попытка автоматически объединить два содержимых в одно. Эта операция успешна, например, если вы в одной из веток просто добавили в конец файла ещё одну строку, а в другой ветке не трогали файл вовсе.
Если содержимое менялось и в той и в другой ветке, происходит конфликт. Git вставляет в место спорного контента что-то вроде
<<<<HEAD
один контент
<<< commit1111
другой контент
<<<end
Вам придётся решить, что делать с таким содержимым: что убрать а что оставить.
После того как конфликт разрешен, вы просто коммитите свое решение, как будто бы никогда и не было двух разных версий файлов, а сразу была та версия, которую вы закоммитили в процессе решения конфликта.
