Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 39
У Git к сожалению вечно будут проблемы с бинарными файлами, их наверное в распределённой системе никогда не сделать нормально, если не назначать один из клонов "главной репой". Git-LFS помогает от ненужной траты места и сети, но с вопросами организации редактирования он вообще никак не помогает.
В 1С тоже есть своя самобытная vcs - называется Хранилище. Хотя сейчас и в 1С стала доступна альтернатива в виде git, с появлением edt...
Я использовал в Германии https://en.wikipedia.org/wiki/Rational_Synergy
Спасибо! Не знал о такой
Это часть IBM's Rational Software?
Приходилось пользоваться их RTC и RQM (их сейчас переименовали). Если одним словом, то это катастрофа.
Начнём с того что стоит эта платформа 21€ с пользователя в месяц (корпоративный тариф).
Всё сложное и запутанное: на мой вопрос в чём разница между Snapshot и Baseline тренер ответил, что это одно и тоже, но оказалось нет - один на уровне компоненты, а другой на уровне стрима.
Регулярно меняют названия. В коде я узнал что baseline так и называется, а Snapshot называется BaselineSet ;-). Сам RTC теперь называется EWM, но все продолжают его называть RTC 😅
Так же с изменениями даже минорных версий часто значительно меняется код. И поскольку мне приходилось в CI пайплайне проводить валидацию Snapshot'a (то есть расширять функционал) то переход от одной версии к другой - большая боль. Молчу уже о том что рабочий метод из stafkoverflow у тебя с 90% вероятностью не заработает :-)
Документация и FAQ доступны только после регистрации на сайте IBM (может показаться, что ничего страшного, но из-за этого Гугл ничего не находит. C ИИ не проверял, но если IBM продолжает прятать свои доки, то откуда ИИ учиться?
Окей. Хорошая интеграция в Eclipse, но для VSCode ничего нет. 3 года назад как минимум не было. Надеюсь IBM всё же собрались с силами и интегрировали в VSCode.
😰
Да, это часть Rational Software. Вместе с Doors и так далее.
20-25 лет назад была де-факто стандартом для автопроизводителей.
Мы с ней конечно тоже намучились и никто из коллег не хочет больше использовать.
Большая проблема была: высокие цены на всё и продажники от IBM или как говорил тех.супорт IBM : наш продажник пообещает всё, что Вы пожелаете. Но это может быть так не работает.
Нужно сказать что RTC это несколько больше чем Git. Скорее это аналоги Git+Jira сразу.
Но вот ещё один прикол RTC вспомнил: "скачанный" репозиторий синхронизируется только в одном локальном месте. Если под тем же юзером клонируешь тот же репозиторий в другую папку или на другом компьютере, то привязка к первому тут же теряется и код лежит мертвым грузом. Можно в первом запустить синхронизацию, да окей, он тогда оживёт, но тогда второй потеряется.
Да и аналог git branching сделан просто ужасно.
Synergy + DOORs + Change = Tool-Chain для всего цикла.
При этом с очень жестокими правилами по которым приходилось работать инженеру/программисту.
По ходу, этот Rational Software был скорее создан для менеджмента, для контроля состояния проекта и для полной документации.
Например для автомобилестроения и авиации это очень важно. И честно сказать, я не знаю что сейчас актуально в автомобилестроении, но 25 лет назад IBM Rational был абсолютным стандартом. Поэтому и цены такие дурные.
поддержка на Bitbucket
Bitbucket как бы с 2020 не поддерживает mercurial
Fossil.
p4 submit (с обязательным указанием changelist).
Неверно. Без указания changelist эта команда отправит default changelist
Можно вопрос? Вдруг именно использование "второй" системы поможет его решить.
Задача: Пилю код. В т.ч. с помощью всяких AI. Соответственно куча AGENTS.md, openspec/, собственные промпты, какие-то заметки.
В "публичный репозиторий" я это все скидывать не хочу. Оданко хочу хранить в своей истории.
Меня бы устроило держать "dev" со всем этим барахлом в своей Gitea, и только "очищенный master" выкладывать на условный GitHub. Но я же не могу сделать разные .gitignore для веток. да и .git/info/exclude тут не сильно помогает.
Конечно, можно скриптами завести "дистиллированный репозиторий" для публикации. Но, может со второй системой элегантнее получится?
Скажем, традиционно .gitgnore для необходимого минимума на GitHub, а "для себя и всего барахла" какой-нибудь SVN...
похоже что проблему можно решить добавив .gitignore в нужную ветку.
Не могу сообразить как.
Допустим, .gitignore добавили в .gitignore одной из веток. Разве при переключениях между ветками он будет "восстанавливать" свое предыдущее значение именно в этой ветке?
Я понимаю идею - в разных ветках разные .gitignore. Но не понимаю, как достигнуть разного содержимого файла в разных ветках.
Создай ветку, отредактируй .gitignore в ветке, вторым коммитом добавь .gitignore в .gitignore. Повторить в каждой ветке.
В dev у меня один .gitignore, и больше он не будет пушиться.
В master у меня другой .gitignore (больше размером), и больше он тоже не будет пушиться.
Меня терзают смутные сомнения, что при переключении с dev на master будет восстанавливаться его состояние из master (появятся дполнительные строчки с исключениями) и обратно.
Больше похоже на подмену .gitignore скриптом при переключении между ветками
Классный вопрос!
Думаю использовать разные VCS одновременно не лучшая идея т к не будет единой истории изменений -> синхронизация будет доставлять много проблем.
Наверно можно попробовать публичный код — основной репозиторий, приватные файлы — в субмодуле.
НАПРИМЕР:
- Создаем публичный репозиторий на GitHub со всем кодом
- Добавляем субмодуль, но путь к нему указываем на внутренний URL
- В публичном репозитории .gitmodules будет содержать приватный URL
- При клонировании публичными пользователями они увидят пустую папку субмодуля
- На своей машине добавите альтернативный URL для субмодуля
Если я вообще правильно понял проблему)
Игнор не заставит гит игнорировать файлы при пуше. Пушатся не файлы, а коммиты целиком. Что в локальном репо, то и получите во внешнем.
А гитигнор совсем другую функцию выполняет
Насколько я понимаю, .gitgnore вообще никак не влияет (что указан там файл, что нет), если файл раньше уже отслеживался. Если надо реально прекратить его отслеживание, надо git rm --cached ему сделать.
Ежели файлы/папки не отслеживались (не попали в индекс), тогда .gitignore поможет, чтобы часть файлов с локального диска не попала в коммит и не улетела в условный GitHub.
А вот такая ситуация мне не понятна:
- у меня в .gitgnore в master файл указан
- я делаю коммит и пуш master
- в GitHub улетает без этого файла
- перехожу в dev
- удаляю этот файл из .gitgnore
- делаю коммит и пуш dev в личную Gitea (уже с этим файлом; или даже вовсе без push)
- возвращаюсь в master и опять добавляю этот файл в .gitignore (неважно как)
- что-то еще меняю, делаю коммит и пуш
Посколько в dev этот "секретный" файл уже попал в индекс, он теперь и в master добавится, и в Гитхаб при пуше улетит, хотя на первом шаге при таком же .gitgnore не улетел?
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 add нужен. Но рано или поздно это случится, так что да, .gitnore тут не помощник. И, насколько я понял, .git/info/exclude тоже.
Файл появится в master и улетит на GitHub только если вы перенесёте в master коммиты из dev,
А вот это интересно и важно. У меня как раз непонимание, в какой момент файл добавляется в индекс (становится отслеживаемым). В данном случае в обход .gitignore. И, похоже, не в момент добавления файла/коммита в другой ветке, а при "заборе" из такой ветки в мастер (merge и т.п.).
Но это уже для общего образования. То, что .gitignore мою задачу не решит, я понял.
в какой момент файл добавляется в индекс (становится отслеживаемым)
Странный вопрос. Вы сами его добавили в репозиторий в ветке dev
В данном случае в обход .gitignore
Ну нет же? Вы же сами написали что удалили из игнора. Хоть это было и не обязательно — любой файл можно закоммитить принудительно при желании.
при "заборе" из такой ветки в мастер (merge и т.п.).
этот «забор» называется слиянием, это когда содержимое двух веток складывается. Сложение, а не вычитание! Никакие файлы при этом исчезать НЕ ДОЛЖНЫ. Если файл был в dev, то он обязательно окажется в объединенной ветке dev+master.
> в какой момент файл добавляется в индекс (становится отслеживаемым)
Странный вопрос. Вы сами его добавили в репозиторий в ветке dev
Файл на диске есть. Но когда я коммитил в master (условно после git add .), он был в .gitignore и в коммит, на Гихаб не попал.
В dev я его убрал из .gitignore и закоммитил.
Раньше вы писали: "Файл появится в master и улетит на GitHub только если вы перенесёте в master коммиты из dev". Если я еще не перенес коммиты из dev в мастер (не сделал merge), файл уже в индексе или еще нет?
Если я сейчас, без merge что-то поменяю теперь в master и коммит отправлю в Гитхаб (как и раньше, сначала выполнив git add . при том, что это файл опять в .gitignore), там этот ранее исключенный файл появится?
Если он попал в индекс в момент коммита в dev - да.
Если только после merge из dev в master - нет.
Что именно вы имеете в виду под словом «индекс»?
Какая-то промежуточная область. В нем может быть не совсем то, что на диске и не совсем то, что в репозитории/коммите.
git status покажет.
Коммит в dev. Без push в Гитхаб. Может пуш в Gitea, неважно. В индекс файл при этом "слегка конфиденциальный" файл попал.
Переключаюсь на master. Редактирую какой-то другой файл (безо всяких merge). Даже внимательно проверяю, что git add сделал только для измененного файла, не того, который хотел скрыть.
Коммичу master, пушу в гитхаб. В Гитхаб уходит как раз индекс, а не напрямую с диска.
В гитхабе теперь можно увидеть мой секретный файл или нет? (вдруг у dev свой индекс, у master свой).
Чисто "академический" интерес для собственного понимания. Конечно, в жизни я не буду так извращаться.
Индекс (Stage Area) всегда один. Это не место для хранения файлов, а промежуточная область для подготовки коммита.
Вы не можете закоммитить файл без предварительного добавления его в индекс. В момент создания коммита Git берёт содержимое именно из индекса, после чего индекс очищается.
При push индекс никуда не передаётся. В удалённый репозиторий уходят только коммиты.
В ветку попадает исключительно то, что вы закоммитили. Не имеет значения, локальная это ветка или внешняя ветка на GitHub — история коммитов единая, а ветки лишь указывают на конкретные коммиты.
Состав будущего коммита всегда можно увидеть через git status — именно он показывает, что находится в индексе и будет зафиксировано.
Важно понимать разницу между веткой и рабочим каталогом. В рабочем каталоге вы видите не саму ветку, а файлы, извлечённые из неё в данный момент. Их количество и содержимое не обязаны полностью совпадать с состоянием ветки.
В рабочем каталоге могут находиться файлы, которых вообще нет в ветке. «Чистота» состояния проверяется через git status.
На GitHub рабочего каталога не существует, поэтому там вы всегда видите реальное состояние ветки — ровно то, что зафиксировано в коммитах.
.gitignore здесь вообще не поможет. Он не управляет историей и публикацией, а лишь тем, что Git предлагает добавить в индекс. Если файл закоммичен, он поедет в любую ветку и в любой remote вместе с коммитом, независимо от gitignore.
Задача решается через промежуточный репозиторий для публикации: из приватного репо забираются коммиты, затем история очищается от приватных файлов (например, с помощью git filter-repo), и только после этого результат публикуется в GitHub. Это позволяет хранить всё для себя и иметь чистый публичный репозиторий без секретов.
Rational clear case - до сих пор считаю лучшей системой контроля версий.
Использовали и intel, и motorola
👍
О, тоже часть IBM's Rational Software
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не Git-ом единым: гид по системам контроля версий для особых случаев