Сергей Кузнецов

SmartGit

https://www.syntevo.com/smartgit/

коллеги!

всем кто советовал разделять на модули: не вариант. я сразу написал об этом (правда назвал их подпроектами).
слишком уж много геморроя. На добавление файла с 20 строчками мне требуется создать 2 новых репы. но прелесть начинается потом - например ядро получается в 100500 копиях (свое в своем локальном проекте).

после внимательного изучения гита я нашел решение наиболее подходящее для моей задачи - это sparse checkout

p.s. а для дистрибуции я решил использовать множественные репозитории для 1 проекта (указывая --git-dir).
т.е. при необходимости провести деплой конкретного проекта (через git причем что бы на сервер заказчикак никак не попадал "левый" код), я из рабочего sparse checkout делаю репозиторий .git-"имя проекта"

Ну развлекайтесь

$ git update-ref 'refs/heads/-@have-fun!' @^{commit}
$ git switch -- '-@have-fun!'
Switched to branch '-@have-fun!'
$ git branch -v
* -@have-fun! 734a4af Docker
  master      734a4af Docker

три ветки в гите - дев, тест и мастер
CI/CD

вся локальная разработка базируется на ветке дев

как только фича закончена, мержим ее в тест
CI/CD настроен так, что по новому пушу в тест он выкладывает новую ветку на сервер
тестируем ее на тест-сервере

когда фича протестирована, мержим ее в мастер
CI/CD настроен так, что по новому пушу в мастер код выкладывается на прод

начинаем цикл по-новой

Как указали выше можно использовать Jenkins. В свое время немного использовали его, но в итоге пришли к встроенному Gitlab CI.

Устанавливать Gitlab CI отдельно не нужно, он идет в комплекте с самим Gitlab. Дополнительно нужно будет установить runner - один или несколько, в зависимости от поставленных целей (например, для простого деплоя может вполне хватить одного SSH-раннера).

В блоге у них есть статьи на эту тему, которые в общих чертах показывают суть процесса:
https://about.gitlab.com/2016/08/26/ci-deployment-...
https://about.gitlab.com/2016/08/05/continuous-int...

Я бы посоветовал завести себе какой-нибудь сервис для Continous Integration, например Jenkins.
Он позволит несколько усложнить задачу (кто бы мог подумать, что усложнить - это что-то хорошее!), например:
* Мониторит git / svn / hg / что угодно на предмет новой версии
* Забирает новую версию
* Прогоняет тесты
* В случае невыполнения тестов отправляет провинившемуся разработчику push / email
* В случае выполнения тестов выполняет деплой, и/или например отправляет артефакт в репозитарий, или образ докера в репозитарий.

Для маленького проекта на 5 файлов, конечно, Jenkins это из пушки по воробьям, и тут наверняка лучше будет rsync (если применимо). Но чем больше проект и чем больше тестов и вариантов сборки, тем полезнее может быть Jenkins.

У нас как только не используется: и собирает докер образы (в случае успешной сборки и тестов - в репозитарий), и собирает java-артефакты (аналогично, собрался - пошёл в maven). Собирает приложения на spring-boot, копирует их на целевой сервер, делает из них сервис и сам его перезапускает.

Да, многое можно возложить на хуки, но:
* хуки выполняются на компьютере разработчика (и зачем мне у себя выполнять 300 тестов при каждом коммите, если рядом специально обученный сервер стоит?). К тому же, бывали ситуации, когда что-то собирается на компьютере разработчика только потому, что у него есть какие-то локальные хаки. И потом приходит новый человек (или он меняет компьютер) и два дня только и делает, что настраивает себе всякое :). С отдельным сборщиком такого не бывает.
* деплой и редеплой может запускать специально обученный PM, а не разработчик. Или вообще кто угодно.
* Есть всякие красивые графики, что успешных тестов выполняется всё больше и больше, например. В любой момент PM может посмотреть, какие изменения были в каждой конкретной сборке.

Видел всякие разные конфигурации, даже такую, когда для сборки проекта покупалась виртуалка на amazon, делала сборку и уничтожалась :) Вопрос лишь в извращённости сознания администратора Jenkins. Ну и, конечно, максимально хорошо он интегрирован с Java. JetBrains TeamCity, Atlassian Bamboo - в общем-то тоже.

вот отличное решение
https://chrome.google.com/webstore/detail/gitzip-f...

Просто указать папку и нажать скачать https://downgit.github.io

Вы же все замечательно нарисовали: ответвляетесь от нужного коммита (HEAD) и делаете коммит =)
Я так понимаю, проблема в переносе указателя ветки на другой коммит.

Тогда вот наиболее простой вариант: Делаете чекаут ветки с перезаписью указателя, если она существует (опция -B) и коммитите в нее.

git checkout -B mybranch
git commit ...

Можно еще так (не знаю только зачем, если есть первый вариант):

git branch -D mybranch
git checkout -b mybranch
git commit ...

Еще можно использовать reset --hard для ветки, но это, в данном случае, извращение.

Если вы успели закоммитить свои изменения, то найдите этот коммит при помощи git reflog и переключитесь на него при помощи git checkout.

Проблема была связана с неправильной кодировкой файла .gitignore, а именно стояла UTF-16 LE из-за чего неправильно интерпретировались правила. При смене на UTF-8 заработало

Там же написано

Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.

юзать переменные окружения както-так

Изменилась первичная схема именования устройства. Приоритеты:
1. eno1 - сетевое устройство 1 на материнской плате. Используется, если из BIOS возможно получить информацию об интегрированных устройствах.
2. ens4 - сетевое устройство в PCI express hot-plug слоте 4. Используется, если из BIOS возможно получить информацию об устройствах на шине PCIe.
3. enp4s0 - сетевое устройство 0 в PCI-слоте 4. Используется, если возможно определить слот.
4. eth0 - сетевое устройство 0. Используется, если не подошли предыдущие схемы. Порядок устройств определяется порядком загрузки драйверов.
5. enx78e7d1ea46da - сетевое устройство с MAC-адресом 78:e7:d1:ea:46:da. Такой режим можно включить вручную.

Цель конечно благая.
Однако насчет успешного перехода - это всегда боль и слезы. Такие вещи проходят только при жесткой поддержке руководства (партия сказала 'надо!'), либо комп используется только например для экзамена в ГИБДД, как написал выше уважаемый коллега.
Из того что точно всплывет:

• Офисный пакет - полной совместимости между MS Office и Libre Office нет, а это значит негатив пользователей 'ты придумал поставить этот линекс, ты и исправляй документ'
  
• Если в организации Exchange - то аутлука под линукс нет, все остальное - костыли. Они вроде бы как то работают, но 'полной совместимости нет'
  
• 1С - даже если заработает в Линуксе (например веб-клиент), то вероятно поплывут формы, которые выгружаются в формате Word или Excel. А это значит что нужно чтобы те кто поддерживают 1С вам эти формы допилили, что может уже привести к прямым затратам.
  

Я бы посоветовал подождать - есть подозрение что импортозамещение скоро пойдет галопом, и тогда у вас будет активная поддержка руководства.

А что вы хотите от шелла в гитхабе? Выполнять команды на его серверах? Зачем?
SSH у гитхаба имеет простое назначение - аутентификация и туннель для доступа к репозиториям. Зачем там шелл?