Git Pull Merge

Кому-то надо пройти креш-курс работы с git. И заодно осилить $EDITOR.

Ветку менять пробовали?

+

Мне сказали в мастере работать. (и работаю под виндой, делаю сайт, крутится локально на Денвере.) Такая хрень с самого начала. Что это за настройки такие по-умолчанию?

Учи гит.

Спасибо, «помощники».

:3

Мне сказали в мастере работать.

Мать, моя женщина! Начни хотя бы с этого: http://nvie.com/posts/a-successful-git-branching-model/

Все твои проблемы от банального непонимания, как оно работает.

Подскажу на пальцах: хоть ты и сидишь с своей директории, но репозиторий то один. Пока ты там ковырялся, другие уже успели накоммитеть и на пушить.

В git все копии репозитория (и твоя локальная и на bitbucket) равноправны.

Но твоя копия отстала от других. Поэтому, если ты настаиваешь работать в master (что плохо), тебе надо сначала сделать pull, замерижить чужие изменения в свою копию, и опушить это обратно на bitbucket.

Но лучше работать в отдельных ветках и отправлять только pull-request'ы. А scrum-master там уже их закомитит в master или ещё куда.

Удачи держать кучу проектов в одном репозитории.

Какая разница сколько там проектов? Хоть и один, над которыми работает толпа. Прилетевшие изменения не должны меня беспокоить и проситься закоммититься. Где-то в настройках моего Гита лажа, с самого начала сидит.

Где-то в настройках моего Гита лажа, с самого начала сидит.

За компьютером?

Лажа — это между клавиатурой и креслом. Git — это не CVS — тут всё чуть-чуть по-другому.

Git — это распределённая VCS, что значит, что у каждого участвующего полная копия репозитория.

И их надо синхронизировать, что ты и наблюдаешь, когда все срут в master.

Для контраста: в централизованных системах, вроде CVS/SVN нет необходимости синхронизации, т.к. есть только один центральный репозиторий. (Но там свои и другие проблемы)

А о чем ты мне вообще рассказываешь? О последовательности действий? О понимании очередности выполнения команд на основе деятельности всех разработчиков проекта (проектов)? Я это все знаю. Проблема в приехавших изменениях, которые просятся закоммититься! Зачем??? Они уже и так есть в репозитории, они же мне слились оттуда. У всех остальных все молча прилетает и оседает. И они только свои коммиты пушат как и должно быть, а я вынужден и чужие отправлять назад.

Ещё раз — у тебя нет понимания. Перечитай ещё раз всё с начала.

Они уже и так есть в репозитории

В твоём репозитории их нет.

Как насчёт трахать мозги своим коллегам?

Коли нечего толкового оставить от себя, то нефиг остроумить попусту.

Вроде все верно. Пока создаешь свой коммит на сервере появляются чужие коммиты. Командой pull ты синхронизируешь свой репозиторий с удаленным, вносишь свои изменения, которые фиксируются в виде коммита. Логично, что прилетело до твоего коммита и в логе будет стоять раньше. Теперь сделав push на сервер улетит твой коммит, который встанет в общую череду коммитов от других разработчиков.

И, да, фраза «Склонировал себе репозиторий с bitbucket.org В папке кроме моего проекта находятся еще несколько, с которыми работают другие люди» означает, что проект один и никакого разделения между участниками нет. Различие в том, что чей-то коммит затрагивает один каталог, а чей-то коммит - другой каталог, но если ветка репозитория одна, то и последовательность коммитов в логе будет общая. Посмотри кто автор и даты коммитов, которые прилетают после pull.

А получается, что гит сам меняет файлы после pull и, наверное, думает, что это мои изменения требующие отправки назад.

Именно так. Чтобы это не происходило, используй git pull --rebase. Но лучше, конечно, изучить git.

Создаешь ветку, в ней ковыряешь, потом комитишь и делаешь мержреквест в мастер.

кроме моего проекта находятся еще несколько, с которыми работают другие люди

O\

Ок, конечно… Делаю pull и (не упоминая о редакторе предлагающем вставить мой комментарий при мерже) в итоге в git log вижу каскад коммитов перед моим.

ну челы запушили в ту репу, с которой ты пуллишь, понятно, что там будут коммиты от них

Это, наверное, после некоторых изменений касательно редактора vim он сам коммитит.

интересно, когда vim научился сам коммитить?

И когда делаю push, то весь этот склад улетает вместе с моим коммитом. Этого не должно быть!

он не может туда улетать, хотя бы потому что в удаленном репозитории они все есть

А получается, что гит сам меняет файлы после pull и, наверное, думает, что это мои изменения требующие отправки назад.

нет

На оф. сайте гита есть прекрасный мануал, переведенный на множество языков. https://git-scm.com/book/ru/v1 Разжевывать вам конкретный вопрос лично я не буду, потому что неизвестно насколько глубоко вы не знаете азы.

это бесполезно, он не слышитчитает никого кроме себя.