А сможете объяснить “на пальцах” как через гит организовывается совместная работа?
Я пытаюсь что-то подобное сделать - но получаю ерунду )))
То есть я на одном компьютере что-то делаю (для простоты использую KiCad), потом отправляю на сервер. Приезжаю к другому компьютеру - жму получить, но ничего не получается - Ошибка слияния (если яверно понял), а всё потому, что KiCad что-то сделал и файлы изменились… То есть у меня получается на компьютере незакомментированные изменения и я нажимаю “Получить” - ну и ничего не получается (((
В общем - что-то я делаю не так. Научите меня кто-нибудь
Скорее всего дело в том, что служебные файлы Кикада на двух компах разные и из-за этого возникают конфликты. Надо все подобные файлы добавить в gitignore, чтобы они не синхронизировались между компами.
Не помню деталей про кикад, возможно этих файлов окажется слишком много, тогда проще пойти от обратного и добавить в гит только то, что вы непосредственно редактируете - файлы схемы и платы.
Я и так добавил подобные файлы в .gitignore
Штука так-то полезная (git) и хочется разобраться по больше. А то сейчас у меня удаленный репозиторий git только как хранилище используется. Если я чего-то дома потом (вдруг) изменил, то просто сношу всё подчистую, создаю новый пустой репозиторий и скачиваю с удаленного. Но это “не дело”, надо разобраться в работе git глубже.
Если судить по картинке, все ваши “мелкие коммиты” - это тестовые ветки. Когда вы будете сливать верхний с мастером, выбирайте режим без rewind (не помню точно) - и тогда у вас все промежуточные коммиты смержатся в один.
Хотя добавлю, что я всегда стараюсь поддерживать историю по максимуму - так проще потом искать источник проблем, если они вдруг возникнут.
Надо подробно читать сообщения об ошибках - там указано, в каких файлах конфликты. И разобраться, почему они возникают.
Ваши собственные файлы в проекте кикад не должен менять. А все служебные надо исключить из репо.
То есть если я сделал коммит и отправил его на сервер, то я больше ничего не могу делать ВООБЩЕ пока мне не пришлют правки со второй стороны?
А как же тогда сотни и тысячи человек одновременно над проектом работают? Или там суть в том, что они совсем другие (разные) файлы создают/правят? А если (вдруг) один общий? Всё, хана? ))
Я уже думал вот как поступить:
Создать отдельную ветку “work” (например), и все изменения вести в ней. А перед коммитом на сервер - сначала принять с сервера ветку master (он по идеи должен же принять?), а потом объединить ветку work с master и отправить обратно на сервер.
Или я не правильно мыслю тут?
Если два человека (или вы один, но в разных ветках или на разных компах) правите один и тот же кусок кода, то при слиянии неизбежно возникнет конфликт. Это вполне ожидаемо, разве нет? Ведь гит не знает, какая из этих двух правок более “правильная”.
То есть при совместном редактировании конфликты, вообще говоря, норма и пугаться их не надо. В гите существует специальный механизм разрешения конфликтов, когда вы анализируете двойные правки в коде и вручную выбираете, какую из двух применить.
Но вообще конфликтов можно избежать или, как минимум, уменьшить их число, если придерживаться двух простых правил: 1) перед началом редактирования файла ВСЕГДА синхронизировать его с удаленным репо и 2)после редактирования кода ВСЕГДА выгружать изменения на удаленный сервер.
Гит очень не любит тех кто пользуется им не через консоль. Вернее, гиту все равно, но люди пользующиеся через гуи изолированы от нативных команд гита, не совсем понимают производимые операции.
В вашем случае проблема не в слиянии мелких коммитов, а в merge conflict. Расхождение историй локальной и удаленной ветки. Выход - или не допускать расхождения историй, или учиться делать слияния с конфликтами.
В VS Code с гитом работать удобно - все в ГУИ, но в случае проблем он сам дает подсказку, какую команду в терминале ввести. Пока проблемы разруливались без проблем
Попробовал всегда перед началом работы “получать данные с удаленного сервера”, а после завершения работы - закрывать программу KiCad (ну это для примера) и отправлять изменения на сервер. Вроде бы работает хорошо
Спасибо за науку!
Клиент у меня SourceTree, у @MMM (если не ошибаюсь) подглядел его - удобный, для 99% задач его хватает. А если что - можно открыть консоль git. Но я в ней не разбираюсь.
Суть в том, что один финский парень не хотел работать с присылаемыми ему изменниями кода так, как привыкли все программисты. И он запили убогое поделие Git. Децентрализованное хранилище копий файлов целиком, с птичьим язком, с эзотерической документацией и постоянным гемороем с конфликтами.
Удобнее, конечно, испаользовать не Git а SVN.
Который и с бинарными файлами нормально работает и репозитории не раздувает, т.к. хранит только различия (diff). И к тому же централизованный. Закоммитил изменения (там svn commit - это на сервер послать. push нету). Локального репозитория - нет. Если ты делаешь ветку и работаешь с ней - она на сервере. А не на локальной машине (которая сгорела, и привет трем месяцам работый)
Но рекаомендовать в 2026 году SVN уже моветон. Хотя он и используется в больших компаниях.
Авторитетное мнение
ЗЫ С клодом пообщался:
-- Привет. Спорят два программиста. Старый топит за SVN и ругает Гит. Молодой ругает старого “диды с SVN, ретрограды”. Старый ругает гит за децентрализацию. Что думаешь?
Привет! Спор вечный, и правы в нём оба, только каждый про своё.
Что старый говорит по делу:
В SVN одна центральная истина: есть сервер, там лежит «правильная» версия. Это проще понять новичку и проще контролировать (права доступа на уровне папок, блокировки файлов).
Для больших бинарных файлов (арт, модели, ассеты) SVN часто удобнее: не нужно тащить всю историю, можно забрать только нужную подпапку.
Линейная история, номера ревизий вместо хэшей, меньше способов «прострелить себе ногу» (нет rebase, force push и прочего).
Децентрализация Git действительно порождает путаницу: «а где у нас главная ветка?», «у меня локально работает, а на сервере не то». На практике все всё равно договариваются о центральном origin, так что децентрализация часто фикция.
Что молодой говорит по делу:
Ветвление и слияние в Git дешёвые и быстрые, в SVN это долго было болью.
Работа офлайн: коммиты, история, diff без сети.
Экосистема: GitHub/GitLab, pull request’ы, CI/CD, code review. Это де-факто стандарт индустрии, и большинство инструментов заточено под Git.
Локальные коммиты позволяют делать мелкие шаги и потом причёсывать историю, а не бояться сломать общую ветку.
Где оба перегибают:
«Ретрограды» не аргумент: SVN до сих пор живёт в геймдеве, embedded, корпоративных системах, и это не глупость, а выбор под задачу.
«Git плох из-за децентрализации» тоже слабо: децентрализация это возможность, а не обязанность. Используй Git как центральный репозиторий, и получишь почти SVN-workflow плюс бонусы.
Итог: для большинства современных команд Git практичнее, главным образом из-за инструментов и экосистемы. Но у SVN есть реальные ниши, и старый не сумасшедший, а просто ценит простоту и предсказуемость.
На Линуксе я использую gitg - но исключительно для просмотра дерева веток в графическом виде. Всю работу с гитом делаю из меню VSCode с установленныи Github -плагином
А вот такой еще вопрос:
Допустим я что-то делал в ветке master и тут решил создать отдельную ветку для эксперимента - test1.
Создал, но на 15 шаге понял, что не туда пошел.
Тогда от шага 10 test1 создаю еще одну ветку - test2.
Вопросы:
Вообще так делать нормально? Или не стОит?
Я ведь не смогу удалить ветку test1 от которой пошла еще одна ветка (test2)? Она у меня так и останется “висеть в истории”? (лишнее не люблю).
Удалить смогу только сразу обе ветки после слияния с master?
Ну, тут проверить - дело трех минут. Просто создается тестовый репозиторий, в котором начинаешь городить любую чушь. Я просто печатал или стирал произвольные символы, сохранял и коммитил
Ветка main - стартовая, здесь она красненькая. От корня создал ветку test1, а от коммита test1_2 - ветку test2. Как видишь, общая часть для обоих тестовых веток - одним цветом, т.е. общая. Стало быть, удаляя test1, ты удаляешь только зеленое ответвление, общая часть становится частью ветки test2
)? Или так не получится?
