Git гениален не сложностью, а простотой: content-addressable storage и несколько типов объектов. Коммиты — это snapshot состояния дерева, а не diff. Дельты, pack-файлы и сжатие — лишь оптимизация хранения. Поэтому взять эту архитектурную идею и реализовать свой, не обязательно совместимый вариант Git, достаточно легко. Сложности начинаются позже, если пытаться развивать его дальше и учитывать нестандартные ситуации.
.gitignore здесь вообще не поможет. Он не управляет историей и публикацией, а лишь тем, что Git предлагает добавить в индекс. Если файл закоммичен, он поедет в любую ветку и в любой remote вместе с коммитом, независимо от gitignore.
Задача решается через промежуточный репозиторий для публикации: из приватного репо забираются коммиты, затем история очищается от приватных файлов (например, с помощью git filter-repo), и только после этого результат публикуется в GitHub. Это позволяет хранить всё для себя и иметь чистый публичный репозиторий без секретов.
Индекс (Stage Area) всегда один. Это не место для хранения файлов, а промежуточная область для подготовки коммита.
Вы не можете закоммитить файл без предварительного добавления его в индекс. В момент создания коммита Git берёт содержимое именно из индекса, после чего индекс очищается.
При push индекс никуда не передаётся. В удалённый репозиторий уходят только коммиты.
В ветку попадает исключительно то, что вы закоммитили. Не имеет значения, локальная это ветка или внешняя ветка на GitHub — история коммитов единая, а ветки лишь указывают на конкретные коммиты.
Состав будущего коммита всегда можно увидеть через git status — именно он показывает, что находится в индексе и будет зафиксировано.
Важно понимать разницу между веткой и рабочим каталогом. В рабочем каталоге вы видите не саму ветку, а файлы, извлечённые из неё в данный момент. Их количество и содержимое не обязаны полностью совпадать с состоянием ветки.
В рабочем каталоге могут находиться файлы, которых вообще нет в ветке. «Чистота» состояния проверяется через git status.
На GitHub рабочего каталога не существует, поэтому там вы всегда видите реальное состояние ветки — ровно то, что зафиксировано в коммитах.
в какой момент файл добавляется в индекс (становится отслеживаемым)
Странный вопрос. Вы сами его добавили в репозиторий в ветке dev
В данном случае в обход .gitignore
Ну нет же? Вы же сами написали что удалили из игнора. Хоть это было и не обязательно — любой файл можно закоммитить принудительно при желании.
при "заборе" из такой ветки в мастер (merge и т.п.).
этот «забор» называется слиянием, это когда содержимое двух веток складывается. Сложение, а не вычитание! Никакие файлы при этом исчезать НЕ ДОЛЖНЫ. Если файл был в dev, то он обязательно окажется в объединенной ветке dev+master.
gitignore вообще не управляет тем, что «можно» или «нельзя» закоммитить и тем более запушить. Он лишь влияет на поведение Git при добавлении неотслеживаемых файлов (git status, git add.).
Если файл уже отслеживается, наличие или отсутствие его в.gitignore не имеет никакого значения — он будет коммититься и попадёт в любые ветки, куда попадёт соответствующий коммит.
И наоборот, игнорируемый файл всегда можно закоммитить принудительно (git add ‑f), а неигнорируемый — не закоммитить просто потому, что вы его не добавили в индекс.
Поэтому для задачи «в одной ветке файл есть и коммитится, а в другой его как бы не существует».gitignore принципиально не подходит. Он не про историю, не про ветки и не про публикацию, а только про удобство работы с рабочей копией.
Посколько в dev этот "секретный" файл уже попал в индекс, он теперь и в master добавится, и в Гитхаб при пуше улетит, хотя на первом шаге при таком же .gitgnore не улетел?
Нет, сам по себе он никуда не «добавится». Файл появится в master и улетит на GitHub только если вы перенесёте в master коммиты из dev, например через git merge / rebase / cherry‑pick. Пока ветки не сливаются, то что стало tracked в dev на master никак не влияет, независимо от.gitignore.
Фиксация — это действие и процесс: зафиксировать изменения в репозитории.
«Коммит» нормально живёт как жаргонное имя сущности (результат фиксации), но как только пытаешься образовать процесс («коммичение»), становится очевидно, почему это именно жаргон, а не полноценный термин языка.
Поэтому на практике и возникает гибрид: коммит — сущность, фиксировать или коммитить — действие, фиксация — процесс. «Коммичение» звучит криво.
И с прилагательными та же логика: «закоммиченные изменения» — нормальный жаргон в Git-контексте, «изменения уже зафиксированы в репозитории» — нейтральная формулировка.
Вывод простой: не стоит воспринимать в штыки нормальные варианты перевода слов этого класса. Лепить «коммит» во все формы выглядит странно — язык сам показывает, где жаргон уместен, а где нет. Проблема не в слове «фиксация» как таковом, а в том, к чему его применили.
Тоже долго думал, нужно ли мне учиться пользоваться колесом. Пока просто ношу вещи на руках. В моём случае работает, но иногда хочется посмотреть, что там человечество за тысячу лет навертело.
Так и с именем ветки — это просто последовательность букв. Мне main нравится больше, так как я ленивый, а тут меньше букв вбивать.
Вот только master умирать не собирается. Если сейчас у нас есть возможность через конфиг поменять название по-умолчанию master на любое другое. То потом ничего принципиально не изменится — продолжим задавать своё любимое название как и раньше.
Забавно, но лучшей «заменой» Git для обычного пользователя давно стала не новая утилита, а IDE JetBrains. Они сумели спрятать Stage Area, не ломая модель Git, и сделали работу с изменениями через Shelfs удобной и интуитивной. При этом всё остаётся совместимым даже с hg и svn, у которых вообще не было индекса.
jj на этом фоне выглядит как подростковая попытка «починить Git, не понимая, зачем он так устроен». JetBrains же просто сделали UX, который снимает боль, не трогая нервную систему инструмента.
Старый iPhone месяцами в авиарежиме и нормально держит подключение к MTS RUS WIFI. Пытался перейти на гуглофон Pixel и в настройках так и не появилось пункта wifi calling, хотя поддержка должна быть.
При первом запросе вас попросят ввести логин и пароль от удалённого репозитория.
Это попросят только у тех, кто поленился установить git-credential-manager
У всех остальных выскакивает красивое окно, позволяющее буквально в один клик дать гиту доступ к вашему GitHub или другому хостингу.
Например, залогиниться через браузер
Но если вы не подключили менеджер, тогда:
При первом запросе вас попросят ввести логин и пароль от удалённого репозитория. Вместо пароля можно ввести Personal Access Token (PAT), который предоставляет доступ к вашему репозиторию без необходимости вводить пароль.
Не можно, а нужно —пароль в терминале у вас просто не примет. Так как GitHub прекратил поддержку аутентификации по паролю в августе 2021 года , Bitbucket Cloud (bitbucket.org) также прекратил поддержку аутентификации по паролю для API и базовой аутентификации по https в марте 2022 года.
Git гениален не сложностью, а простотой: content-addressable storage и несколько типов объектов. Коммиты — это snapshot состояния дерева, а не diff. Дельты, pack-файлы и сжатие — лишь оптимизация хранения. Поэтому взять эту архитектурную идею и реализовать свой, не обязательно совместимый вариант Git, достаточно легко. Сложности начинаются позже, если пытаться развивать его дальше и учитывать нестандартные ситуации.
.gitignore здесь вообще не поможет. Он не управляет историей и публикацией, а лишь тем, что Git предлагает добавить в индекс. Если файл закоммичен, он поедет в любую ветку и в любой remote вместе с коммитом, независимо от gitignore.
Задача решается через промежуточный репозиторий для публикации: из приватного репо забираются коммиты, затем история очищается от приватных файлов (например, с помощью git filter-repo), и только после этого результат публикуется в GitHub. Это позволяет хранить всё для себя и иметь чистый публичный репозиторий без секретов.
Индекс (Stage Area) всегда один. Это не место для хранения файлов, а промежуточная область для подготовки коммита.
Вы не можете закоммитить файл без предварительного добавления его в индекс. В момент создания коммита Git берёт содержимое именно из индекса, после чего индекс очищается.
При push индекс никуда не передаётся. В удалённый репозиторий уходят только коммиты.
В ветку попадает исключительно то, что вы закоммитили. Не имеет значения, локальная это ветка или внешняя ветка на GitHub — история коммитов единая, а ветки лишь указывают на конкретные коммиты.
Состав будущего коммита всегда можно увидеть через git status — именно он показывает, что находится в индексе и будет зафиксировано.
Важно понимать разницу между веткой и рабочим каталогом. В рабочем каталоге вы видите не саму ветку, а файлы, извлечённые из неё в данный момент. Их количество и содержимое не обязаны полностью совпадать с состоянием ветки.
В рабочем каталоге могут находиться файлы, которых вообще нет в ветке. «Чистота» состояния проверяется через git status.
На GitHub рабочего каталога не существует, поэтому там вы всегда видите реальное состояние ветки — ровно то, что зафиксировано в коммитах.
Что именно вы имеете в виду под словом «индекс»?
Странный вопрос. Вы сами его добавили в репозиторий в ветке dev
Ну нет же? Вы же сами написали что удалили из игнора. Хоть это было и не обязательно — любой файл можно закоммитить принудительно при желании.
этот «забор» называется слиянием, это когда содержимое двух веток складывается. Сложение, а не вычитание! Никакие файлы при этом исчезать НЕ ДОЛЖНЫ. Если файл был в dev, то он обязательно окажется в объединенной ветке dev+master.
gitignore вообще не управляет тем, что «можно» или «нельзя» закоммитить и тем более запушить. Он лишь влияет на поведение Git при добавлении неотслеживаемых файлов (git status, git add.).
Если файл уже отслеживается, наличие или отсутствие его в.gitignore не имеет никакого значения — он будет коммититься и попадёт в любые ветки, куда попадёт соответствующий коммит.
И наоборот, игнорируемый файл всегда можно закоммитить принудительно (git add ‑f), а неигнорируемый — не закоммитить просто потому, что вы его не добавили в индекс.
Поэтому для задачи «в одной ветке файл есть и коммитится, а в другой его как бы не существует».gitignore принципиально не подходит. Он не про историю, не про ветки и не про публикацию, а только про удобство работы с рабочей копией.
Нет, сам по себе он никуда не «добавится». Файл появится в master и улетит на GitHub только если вы перенесёте в master коммиты из dev, например через git merge / rebase / cherry‑pick. Пока ветки не сливаются, то что стало tracked в dev на master никак не влияет, независимо от.gitignore.
Игнор не заставит гит игнорировать файлы при пуше. Пушатся не файлы, а коммиты целиком. Что в локальном репо, то и получите во внешнем.
А гитигнор совсем другую функцию выполняет
Фиксация — это действие и процесс: зафиксировать изменения в репозитории.
«Коммит» нормально живёт как жаргонное имя сущности (результат фиксации),
но как только пытаешься образовать процесс («коммичение»), становится очевидно, почему это именно жаргон, а не полноценный термин языка.
Поэтому на практике и возникает гибрид:
коммит — сущность,
фиксировать или коммитить — действие,
фиксация — процесс. «Коммичение» звучит криво.
И с прилагательными та же логика: «закоммиченные изменения» — нормальный жаргон в Git-контексте, «изменения уже зафиксированы в репозитории» — нейтральная формулировка.
Вывод простой: не стоит воспринимать в штыки нормальные варианты перевода слов этого класса. Лепить «коммит» во все формы выглядит странно — язык сам показывает, где жаргон уместен, а где нет. Проблема не в слове «фиксация» как таковом, а в том, к чему его применили.
Тоже долго думал, нужно ли мне учиться пользоваться колесом. Пока просто ношу вещи на руках. В моём случае работает, но иногда хочется посмотреть, что там человечество за тысячу лет навертело.
Так и с именем ветки — это просто последовательность букв. Мне main нравится больше, так как я ленивый, а тут меньше букв вбивать.
Вот только master умирать не собирается. Если сейчас у нас есть возможность через конфиг поменять название по-умолчанию master на любое другое. То потом ничего принципиально не изменится — продолжим задавать своё любимое название как и раньше.
Правильнее было бы написать, что умер SHA-2, но ведь нужен максимально кликбейтный заголовок, да?
Забавно, но лучшей «заменой» Git для обычного пользователя давно стала не новая утилита, а IDE JetBrains. Они сумели спрятать Stage Area, не ломая модель Git, и сделали работу с изменениями через Shelfs удобной и интуитивной. При этом всё остаётся совместимым даже с hg и svn, у которых вообще не было индекса.
jj на этом фоне выглядит как подростковая попытка «починить Git, не понимая, зачем он так устроен». JetBrains же просто сделали UX, который снимает боль, не трогая нервную систему инструмента.
А собственно сам взлом через принтер?
Directory — корректнее переводить как каталог или папка. Термин «директория» считается устаревшим, им пользовались десятилетия назад.
Старый iPhone месяцами в авиарежиме и нормально держит подключение к MTS RUS WIFI. Пытался перейти на гуглофон Pixel и в настройках так и не появилось пункта wifi calling, хотя поддержка должна быть.
Причем никаких ограничений на данный момент нет. Ни по стране, ни по языку.
— это звучит как призыв к действию, но вы, наверное, хотели написать другое:
— просто констатация факта.
Паразитировать на нормальных IDE от JetBrains это определенно лучше, чем делать клон VSCode.
Зашел на сайт и не увидел у него никакой грязи в сторону русскоговорящих, не выдумывайте.
Это попросят только у тех, кто поленился установить
git-credential-managerУ всех остальных выскакивает красивое окно, позволяющее буквально в один клик дать гиту доступ к вашему GitHub или другому хостингу.
Но если вы не подключили менеджер, тогда:
Не можно, а нужно — пароль в терминале у вас просто не примет. Так как GitHub прекратил поддержку аутентификации по паролю в августе 2021 года , Bitbucket Cloud (bitbucket.org) также прекратил поддержку аутентификации по паролю для API и базовой аутентификации по https в марте 2022 года.