Данная ошибка кардинально меняет смысл текста. Но мы догадываемся, что автор наверное не хотел высказать такую странную мысль и сами додумываем правильный вариант. Всё это отвлекает от чтения исходного текста и заставляет терять драгоценное время на коррекцию ошибок. И теряется желание читать дальше.
Вы сравниваете на самом деле не Windows и Linux/macOS, а оболочки cmd/pwsh и bash/zsh. Они не привязаны к операционным системам и вполне себе кроссплатформенные. Мы же можем использовать Bash в Windows? Или PowerShell в юниксовых системах.
Когда секреты утекли в GitHub то считайте что они уже скомпрометированы. Есть боты, которые мгновенно скачивают всё, поэтому тут в любом случае нужно менять пароли.
А раз вы аннулировали утекшие секреты, то ничего страшного в том, что они остались где-то в истории. Если же вы всё таки решили пересобрать новую историю, то не используйте filter-branch
Пакет filter-branch сейчас заявлен устаревшим и не рекомендуется к использованию, так как может повредить репозитории, созданные актуальной версией гита. Пользуйтесь filter-repo – он быстрее и безопаснее.
Если вы быстро заметили проблему, то проще обойтись упомянутым выше reset --soft либо commit --amend чтобы поправить только последний коммит, а не пересобирать весь проект заново.
Это в ту же сторону. Вы предлагаете заменить компы на более современные, у которых есть USB-порт, но продолжить втыкать в них дискеты. Да и USB-приводов для 5-дюймовых дискет тоже никогда не существовало.
Что-то я не заметил ограничения 8 часов. Уже года 4 телефон в авиарежиме стоит, чтобы не попадать на роуминг, а название оператора показывает как MTS WIFI и не отваливается.
Английские слова не склоняются. Не пытайтесь прикрутить к ним дополнительные окончания ни через дефис, ни через апостроф. Фраза «применение git'a» звучит так, будто вы пытаетесь изобразить икоту. А ещё надо помнить, что названия в английском всегда пишутся с заглавной буквы. Поэтому если мы говорим про систему управления версиями, то скажем «применение Git». Если непременно хочется просклонять слово, то и пишите его русскими буквами — «применение гита» — так тоже нормально.
Сложносоставные слова с несклоняемой первой частью напротив пишутся через дефис: Нон-фикшен-литература, Wi-Fi-роутер, Internet-кафе, онлайн-опрос, Web-браузер... Нет смысла использовать термин «Мердж-коммит», так как merge переводится нормальным словом «слияние», а merge commit это просто «коммит слияния», merge conflict — «конфликт слияния».
Чекаут (checkout) — переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита.
Тут вы путаете сам репозиторий и его рабочий каталог. Репозиторий хранит историю всех состояний проекта. Чекаут это распаковка некоторого состояния проекта в рабочий каталог. Изменяются именно файлы в рабочем каталоге, а не в репозитории. Сам репозиторий содержит сущности, которые неизменяемы.
Ребейз (rebase) — перенос изменений текущей ветки «поверх» другой ветки.
Rebase (ребейз, перебазирование) — это пересборка некоторой цепочки коммитов на другой базовый коммит, с последующей перестановкой указателя ветки на вершину новой цепочки. Старая цепочка коммитов никуда не исчезает и у других членов команды ветка продолжит указывать на старую цепочку и поэтому начинаются сложности.
Перевод слова remote как «удаленный» не очень подходит в контексте гита. Получаются странные формулировки типа «удалить удаленный». Лучше говорить «внешний». Есть локальный репозиторий и внешние репозитории по отношению к нему. Локальные ветки можно связать с их вышестоящими ветками во внешних репозиториях. При этом можно создать две разные связи, одну для получения изменений (fetch), другую для отправки (push). Но это не обязательно — мы всегда можем явно указать что и куда сливать.
Pull это два действия в одной команде. Внутри там делается сначала Fetch (получение всех обновлений) затем делается слияние какой-то ветки в текущую ветку методом merge, либо методом rebase, в зависимости от настроек гита, либо параметров самой команды pull.
В гите, любой репозиторий, отличный от локального, может быть внешним (мне не нравится термин «удаленный», так как с ним порождаются странные языковые конструкции типа «удалить удаленный»)
Внешний или локальный это не свойство репозитория, а скорее отношения между разными экземплярами репо.
Так вот внешний репо может лежать и в соседнем каталоге того же компьютера, так и в сетевой шаре Windows. Мы с таким же успехом можем задать в remote полный путь к папке в сети вида \\комп\шара\каталог и спокойно синхронизироваться с коллегами в закрытой локальной сети. Никакие gitea или гитлабы тут не обязательны.
Bare-репозиторий создавать тоже нет особой нужды. Главное не пытаться делать push в активную ветку.
Авто с ДВС это точно дорогая игрушка. Когда я пересел на электрику в прошлом году, расходы на машину сократились в несколько раз. Теперь только жалею, что не сделал это ещё несколько лет назад.
Название статьи должно было звучать так: Как в Git залить контент другой ветки в master, избежав всех конфликтов
оказалось что практически тоже самое можно сделать одной командой
Ваша одна команда меняет только newmaster, а master остаётся сломанным. Забыли обновить сам master. Полное решение будет чуть длиннее:
git checkout newmaster — находясь в «хорошей» ветке
git merge --strategy=ours master — создать коммит слияния со сломанной веткой, полностью игнорируя содержимое сломанной ветки
git checkout master — перейти в сломанную ветку
git merge -ff newmaster — переместить указатель мастера на созданный коммит слияния
подписывая все хешики команд в блокнотик рядом
Вы знали, что сам Git ничего не удаляет и вообще записывает за вас все хешики в свой журнал reflog?
для того чтобы branch -f master сработал, ибо запрещено менять ветку на который сейчас находишься
Чем вам не понравился reset? Он делает то же самое, но на текущей ветке.
порядок указания предков определяет как графические утилиты будут показывать направление мерджа
Порядок предков в гите абсолютно ни на что не влияет.
А всю вашу длинную инструкцию можно заменить одной командой. Находясь в master сделать: git merge --ff $(git commit-tree -p newmaster -m "Override master with newmaster" newmaster^{tree})
Их мастер вы заменить не в стостоянии. Он же на их компьютерах.
Наверное проблема именно в неправильных формулировках. В том числе в том, как сформулирован заголовок вашей статьи. Я несколько раз его перечитал и не понял о чем речь. Лишь далее по тексту немного прояснилась хотелка.
Наверное надо было уточнить, что хочется не ветку заменить, а состояние проекта в этой ветке. Сама ветка остается там же и коллеги легко продолжат в ней работать обновившись через простой fetch/pull
Почему вы считаете, что push --force, упомянутый в заголовке, решает эту задачу? Коллеги не увидят вашего переименования и вам придется попросить их поудалять свои мастеры и распаковать заново вашу новую версию. Причем так потеряется история старого мастера.
Понять индексирование проще, чем объяснять, зачем надо заново добавлять в staging area после каждого изменения. Тут скорее add и cached выглядят нелогичными рудиментами.
Нестандартный порт помогает буквально на несколько минут. А банить по IP тоже бесполезно, так как брутят через ботнеты и каждая попытка идёт с нового адреса.
Дочитал до конца и так и не увидел демонстрации как эта синхронизация работает на мобильнике. Это боль.
Ну вы вот такой оборот используете:
«мне нравиться быть техническим специалистом»
— значит вы нравитесь быть?
Да?
Данная ошибка кардинально меняет смысл текста. Но мы догадываемся, что автор наверное не хотел высказать такую странную мысль и сами додумываем правильный вариант. Всё это отвлекает от чтения исходного текста и заставляет терять драгоценное время на коррекцию ошибок. И теряется желание читать дальше.
Вы сравниваете на самом деле не Windows и Linux/macOS, а оболочки cmd/pwsh и bash/zsh. Они не привязаны к операционным системам и вполне себе кроссплатформенные. Мы же можем использовать Bash в Windows? Или PowerShell в юниксовых системах.
Когда секреты утекли в GitHub то считайте что они уже скомпрометированы. Есть боты, которые мгновенно скачивают всё, поэтому тут в любом случае нужно менять пароли.
А раз вы аннулировали утекшие секреты, то ничего страшного в том, что они остались где-то в истории. Если же вы всё таки решили пересобрать новую историю, то не используйте filter-branch
Пакет filter-branch сейчас заявлен устаревшим и не рекомендуется к использованию, так как может повредить репозитории, созданные актуальной версией гита.
Пользуйтесь filter-repo – он быстрее и безопаснее.
Если вы быстро заметили проблему, то проще обойтись упомянутым выше reset --soft либо commit --amend чтобы поправить только последний коммит, а не пересобирать весь проект заново.
Это в ту же сторону. Вы предлагаете заменить компы на более современные, у которых есть USB-порт, но продолжить втыкать в них дискеты. Да и USB-приводов для 5-дюймовых дискет тоже никогда не существовало.
Что-то я не заметил ограничения 8 часов. Уже года 4 телефон в авиарежиме стоит, чтобы не попадать на роуминг, а название оператора показывает как MTS WIFI и не отваливается.
.
«Летом не рекомендуется … всегда мазаться солнцезащитным кремом»
Странная рекомендация, чем плох крем?
Английские слова не склоняются. Не пытайтесь прикрутить к ним дополнительные окончания ни через дефис, ни через апостроф. Фраза «применение git'a» звучит так, будто вы пытаетесь изобразить икоту. А ещё надо помнить, что названия в английском всегда пишутся с заглавной буквы. Поэтому если мы говорим про систему управления версиями, то скажем «применение Git». Если непременно хочется просклонять слово, то и пишите его русскими буквами — «применение гита» — так тоже нормально.
Сложносоставные слова с несклоняемой первой частью напротив пишутся через дефис: Нон-фикшен-литература, Wi-Fi-роутер, Internet-кафе, онлайн-опрос, Web-браузер...
Нет смысла использовать термин «Мердж-коммит», так как merge переводится нормальным словом «слияние», а merge commit это просто «коммит слияния», merge conflict — «конфликт слияния».
Чекаут (checkout) — переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита.
Тут вы путаете сам репозиторий и его рабочий каталог. Репозиторий хранит историю всех состояний проекта. Чекаут это распаковка некоторого состояния проекта в рабочий каталог. Изменяются именно файлы в рабочем каталоге, а не в репозитории. Сам репозиторий содержит сущности, которые неизменяемы.
Ребейз (rebase) — перенос изменений текущей ветки «поверх» другой ветки.
Rebase (ребейз, перебазирование) — это пересборка некоторой цепочки коммитов на другой базовый коммит, с последующей перестановкой указателя ветки на вершину новой цепочки. Старая цепочка коммитов никуда не исчезает и у других членов команды ветка продолжит указывать на старую цепочку и поэтому начинаются сложности.
Перевод слова remote как «удаленный» не очень подходит в контексте гита. Получаются странные формулировки типа «удалить удаленный». Лучше говорить «внешний».
Есть локальный репозиторий и внешние репозитории по отношению к нему. Локальные ветки можно связать с их вышестоящими ветками во внешних репозиториях. При этом можно создать две разные связи, одну для получения изменений (fetch), другую для отправки (push). Но это не обязательно — мы всегда можем явно указать что и куда сливать.
Pull это два действия в одной команде. Внутри там делается сначала Fetch (получение всех обновлений) затем делается слияние какой-то ветки в текущую ветку методом merge, либо методом rebase, в зависимости от настроек гита, либо параметров самой команды pull.
Попытался произнести заголовок статьи и не смог.
В гите, любой репозиторий, отличный от локального, может быть внешним (мне не нравится термин «удаленный», так как с ним порождаются странные языковые конструкции типа «удалить удаленный»)
Внешний или локальный это не свойство репозитория, а скорее отношения между разными экземплярами репо.
Так вот внешний репо может лежать и в соседнем каталоге того же компьютера, так и в сетевой шаре Windows. Мы с таким же успехом можем задать в remote полный путь к папке в сети вида \\комп\шара\каталог и спокойно синхронизироваться с коллегами в закрытой локальной сети. Никакие gitea или гитлабы тут не обязательны.
Bare-репозиторий создавать тоже нет особой нужды. Главное не пытаться делать push в активную ветку.
Авто с ДВС это точно дорогая игрушка. Когда я пересел на электрику в прошлом году, расходы на машину сократились в несколько раз. Теперь только жалею, что не сделал это ещё несколько лет назад.
Название статьи должно было звучать так:
Как в Git залить контент другой ветки в master, избежав всех конфликтов
Ваша одна команда меняет только newmaster, а master остаётся сломанным.
Забыли обновить сам master. Полное решение будет чуть длиннее:
git checkout newmaster— находясь в «хорошей» веткеgit merge --strategy=ours master— создать коммит слияния со сломанной веткой, полностью игнорируя содержимое сломанной веткиgit checkout master— перейти в сломанную веткуgit merge -ff newmaster— переместить указатель мастера на созданный коммит слиянияВы знали, что сам Git ничего не удаляет и вообще записывает за вас все хешики в свой журнал reflog?
Чем вам не понравился reset? Он делает то же самое, но на текущей ветке.
Порядок предков в гите абсолютно ни на что не влияет.
А всю вашу длинную инструкцию можно заменить одной командой.
Находясь в master сделать:
git merge --ff $(git commit-tree -p newmaster -m "Override master with newmaster" newmaster^{tree})Их мастер вы заменить не в стостоянии. Он же на их компьютерах.
Наверное проблема именно в неправильных формулировках. В том числе в том, как сформулирован заголовок вашей статьи. Я несколько раз его перечитал и не понял о чем речь. Лишь далее по тексту немного прояснилась хотелка.
Наверное надо было уточнить, что хочется не ветку заменить, а состояние проекта в этой ветке. Сама ветка остается там же и коллеги легко продолжат в ней работать обновившись через простой fetch/pull
Почему вы считаете, что push --force, упомянутый в заголовке, решает эту задачу? Коллеги не увидят вашего переименования и вам придется попросить их поудалять свои мастеры и распаковать заново вашу новую версию. Причем так потеряется история старого мастера.
Всю статью можно сократить до трех шагов:
Создать клон в соседнем каталоге
git clone --no-local . "../movement-example"Перейти туда
cd "../movement-example"Оставить только внутренности каталога
folder-to-movegit filter-repo --subdirectory-filter "folder-to-move/"А пакет filter-branch объявлен устаревшим и не рекомендуется к использованию.
Понять индексирование проще, чем объяснять, зачем надо заново добавлять в staging area после каждого изменения. Тут скорее add и cached выглядят нелогичными рудиментами.
Нестандартный порт помогает буквально на несколько минут.
А банить по IP тоже бесполезно, так как брутят через ботнеты и каждая попытка идёт с нового адреса.