Когда секреты утекли в 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 тоже бесполезно, так как брутят через ботнеты и каждая попытка идёт с нового адреса.
Хэш коммитов не только однозначно идентифицирует содержимое файлов, но также дополнительно идентифицирует время сохранения и автора работы. Коммит это снимок проекта на определённый момент с добавленными метаданными. Изменить коммит в гите невозможно, и хеш коммита не меняется в зависимости от того, где лежит репозиторий. Неважно, на гитхабе он, или вы его клонировали себе. Хеш останется неизменным, как и файлы которые этот хеш идентифицирует.
Ключевая ошибка статьи в том, что рабочий каталог репозитория почему-то обозвали репозиторием. Это категорически не так.
Каждому студенту нужно знать чем отличается репозиторий от рабочего каталога. Рабочих каталогов может быть несколько и внутри одного из них может лежать репозиторий.
А бывают репозитории без рабочего каталога вовсе.
Гит на самом деле довольно прост, но к сожалению не интуитивен. Чтобы понять как работает гит, нужно обязательно выучить основные понятия, тогда не будет проблем. А если пытать только запомнить некоторые команды, то у вас ничего не получится. Вы будете как обезьяна вбивать заклинания в командную строку и не понимать что они делают на самом деле.
Когда секреты утекли в 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 тоже бесполезно, так как брутят через ботнеты и каждая попытка идёт с нового адреса.
Поправьте очепятку: поде́лится → подели́ться
Хэш коммитов не только однозначно идентифицирует содержимое файлов, но также дополнительно идентифицирует время сохранения и автора работы. Коммит это снимок проекта на определённый момент с добавленными метаданными. Изменить коммит в гите невозможно, и хеш коммита не меняется в зависимости от того, где лежит репозиторий. Неважно, на гитхабе он, или вы его клонировали себе. Хеш останется неизменным, как и файлы которые этот хеш идентифицирует.
Ну не склоняются английские слова, но вы аж в заголовок умудрились своё (ов) воткнуть.
Ключевая ошибка статьи в том, что рабочий каталог репозитория почему-то обозвали репозиторием. Это категорически не так.
Каждому студенту нужно знать чем отличается репозиторий от рабочего каталога. Рабочих каталогов может быть несколько и внутри одного из них может лежать репозиторий.
А бывают репозитории без рабочего каталога вовсе.
Гит на самом деле довольно прост, но к сожалению не интуитивен. Чтобы понять как работает гит, нужно обязательно выучить основные понятия, тогда не будет проблем. А если пытать только запомнить некоторые команды, то у вас ничего не получится. Вы будете как обезьяна вбивать заклинания в командную строку и не понимать что они делают на самом деле.
Уже лет 20 не принято называть каталоги директориями. Используйте устоявшийся перевод, а не эту кальку с английского написания.
Папка — тоже нормальное слово. Его придумали когда появились графические интерфейсы и каталоги реально изображали в виде папок.