это?

git pull --rebase origin <branch>

не меняя ветку

А что мешает вам в разных веточках работать?

Нужно скачать (fetch) коммиты коллеги и объединить их со своими (merge origin/master). Гит сам позаботится о слиянии (в большинстве случаев). Далее в результате слияния создастся новый коммит. После этого можно делать push.

Если не нужно, чтобы потом работало, то вариантов полно, иначе: разрешать конфликты.

Рабочий процесс должен быть структурирован так, чтобы свести к нулю возможные конфликты.

Простейший способ - расшить на модули в первую очередь по функциональности, действиям, сущностям.

Нужно скачать (fetch) коммиты коллеги и объединить их со своими (merge origin/master)

если я сделаю слияние его коммитов (на wordpress) и своих (на drupal), то получится полная каша, смешанная из двух движков, в этом и есть суть проблемы - мой коммит должен, по сути, аннулировать все предыдущие коммиты. Как это сделать?

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

Плюсую fetch + rebase.

Ты одновременно хочешь

не меняя ветку и не убивая предыдущие коммиты

и

мой коммит должен, по сути, аннулировать все предыдущие коммиты

Что ты хочешь получить в итоге?

Ну так сделай ручное слияние, его изменения откидывай, свои оставляй.

Сейчас тебе кто-нибудь расскажет про ключ --force

Сейчас тебе кто-нибудь расскажет про ключ --force

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

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

да

Что ты хочешь получить в итоге?

хочу сделать новый коммит, в котором будет новый (не основанный на старом) сайт на новом движке

Плюсую fetch + rebase.

rebase знаю что такое, но не понимаю как он поможет в данном случае, можно поподробнее?

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

ну, это был бы вариант, если бы у меня еще не было новых коммитов и рабочий каталог был пустой

Ну так сделай ручное слияние, его изменения откидывай, свои оставляй.

как это сделать? там будут тысячи конфликтующих файлов, плюс неконфликтующие файлы от старого движка подлежат удалению. Как это сделать, приведите пример работающей команды

т.е. ты хочешь затереть чужие коммиты своими?

ты можешь сделать git rebase -i <hash commit'a>
далее ты окажешься в контексте того коммита и можешь делать всё что хочешь
коммитить, изменять файлы
советую изучить http://tonyganch.com/git/rebase/

т.е. ты хочешь затереть чужие коммиты своими?

Даааааа!!! :)

5. вот здесь возникает проблема: дело в том, что мои новые коммиты уже не основаны на предыдущих, так как я решил сменить фреймворк с Wordpress'а, на, предположим, Drupal и имею абсолютно новый сайт (коммит);
6. стало быть, я уже не могу выполнить слияние коммитов моего коллеги (его коммиты все еще на wordpress'е) со своими;

Вопрос из разряда «Я сменил самолёт на танк, смогу ли я использовать старую ВПП для взлёта?»

как грамотно разрулить такую ситуацию?

https://www.youtube.com/watch?v=wWKZD5CgQ0Q

Это что вообще за фирма такая, где один разработчик может насрать на коллег, и единолично сменить фреймворк, удалив чужие коммиты, не обсудив это с коллегами?

кажись можно ещё похардкору если ребэйз никак) Качаем в отдельную папку репозиторий, перезатираем содержимым из локальной репы и отправляем на сервер

крутой, крутой

мой коммит должен, по сути, аннулировать все предыдущие коммиты

А если там было что-то не связаное с движком?

ты можешь сделать git rebase -i <hash commit'a>
далее ты окажешься в контексте того коммита и можешь делать всё что
хочешь
коммитить, изменять файлы
советую изучить http://tonyganch.com/git/rebase/

спасибо, оказалось очень полезным

Вопрос из разряда «Я сменил самолёт на танк, смогу ли я использовать старую ВПП для взлёта?»

самолет на другой самолет - правильная аналогия

Это что вообще за фирма такая, где один разработчик может насрать на коллег, и единолично сменить фреймворк, удалив чужие коммиты, не обсудив это с коллегами?

это был пример, чтобы можно было наглядно разобрать ситуацию ))) не переживайте вы так.. )

Качаем в отдельную папку репозиторий, перезатираем содержимым из локальной репы и отправляем на сервер

а зачем отдельная папка?

git merge -s ours

вроде это решает все проблемы, не?

А если там было что-то не связаное с движком?

ну это уже была бы другая ситуация))

т.е. ты хочешь затереть чужие коммиты своими?

Даааааа!!! :)

Тогда тебе правильно посоветовали git merge -s ours. Но вообще, на будущее, если б каждый разработчик писал свои вещи в своей отдельно ветке, то сейчас бы ты не имел такого геморроя, а просто дропнул бы все ненужные ветки, а свою переименовал в master.

я бы завел новый репозиторий для нового сайта. Раз уж у старой и новой версии ничего общего кроме названия, тогда зачем извращаться? Старый репозиторий пускай тоже остается.

git pull --rebase origin <branch>

поясните пожалуйста что делает эта команда?

git rebase -i <hash commit'a>

а здесь опция -i какую роль выполняет?

ну и последний вопрос:
git merge -s ours
git rebase -i <hash commit'a>
применительно к моему случаю, в чем разница между ними и какую выбрать?

А какой смысл накатывать Вордпрессовые коммиты на Друпал?

Если же коммиты не имеют отношения к CMS, то зачем это тут упоминать? И вообще, зачем тебе коммиты коллеги, если ты хочешь их анулировать? Делай просто git push --force, тогда в удаленном репозитории останется только то, что есть у тебя. А коллеге скажи, чтобы он сначала изменения к себе забрал, прежде чем что-либо делать, иначе у него возникнуть трудности с объединением изменений.

чувак, почитай доку :)

И если вдруг, ты последуешь моему совету, то прочитай сначала вот это:

https://git-scm.com/book/en/v2/Git-Branching-Rebasing

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

Потому что git push -f

• изменит удаленный репозиторий,
• удалит оттуда все, что отсутствует в твоем резозитории.

Git — это просто!

Всем большое спасибо!

+1

При таких изменениях движка, какой смысл тогда в коммитах коллеги? Вы очень странные. Ещё и php.

При таких изменениях движка, какой смысл тогда в коммитах коллеги? Вы очень странные. Ещё и php.

как уже писалось выше, «такое» изменение движка рассмотрено только в качестве примера, равно как и php

не правильно вы ему советуете git push -f делать. ему историю нужно сохранить прежде чем репозиторий заменить. советчики блин хреновы

не правильно вы ему советуете git push -f делать. ему историю нужно сохранить прежде чем репозиторий заменить. советчики блин хреновы

да, историю сохранить нужно обязательно.
может я не правильно вопрос задал.
короче нужно следующее:

1. после того как я клонировал репозиторий, коллега делает несколько коммитов;
2. далее я, по идее, должен был бы сделать git pull, далее что-то типа нового коммита, который удаляет все существующие файлы, и далее еще один коммит с совершенно новым содержимым;
3. проблема в том, что я не могу сделать git pull (с последующими двумя коммитами), поскольку это самое новое содержимое уже закоммичино в моем локальном репозитории.

вопрос был как раз о том, как грамотно разрулить эту (уже сложившуюся) ситуацию?

именно это тебе и ответили в Git - как сделать push при невозможности выполнить слияние? (комментарий)

1. Скачать git коллеги
2. Руками стереть все содержимое рабочей папки
3. Руками скопировать все содержимое своей рабочей папки в эту пустую
4. Сделать git commit локально
5. Отправить содержимое git на сервер

Всем большое спасибо. Тема закрыта.