Ответы пользователя по тегу Git
  • Как объединть 2 последних коммита?

    @Stqs
    senior software developer
    git reset --soft HEAD~2
    git commit -a -m 'join'
    git push origin <branch>  --force

    примерно так
    Ответ написан
    Комментировать
  • Как деплоить небольшие проекты?

    @Stqs
    senior software developer
    вопросы у вас философские, на каждый можно отвести часы обсуждения
    Полноценный CI/CD поднимать не вижу смысла ввиду размеров

    вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
    какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
    единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
    с этой точки зрения мое видение примерно такое:

    1) git не есть инструмент для развертывания по, git лишь для версионирования кода
    и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
    сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
    Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
    Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
    Артефакты желательно хранить в каком-то артефактории,
    но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

    2) как только вы получили артефакт - его можно деплоить
    неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
    опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
    Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

    В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

    3) Env Variables
    когда приложение стартует - считывает все что ему нужно из переменных окружения
    деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

    Итого имеем
    - логика сборки проекта описана в Dockerfile и находится под гитом
    - логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
    - на сервере мы ничего не устанавливали совершенно кроме самого докера
    - мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
    - сервер не знает ничего о гитах
    - на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
    - имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)
    giphy.gif
    Ответ написан
    5 комментариев
  • Как настроить простой автодеплой с VCS?

    @Stqs
    senior software developer
    у битбакета есть же свое решение интеграрованное
    https://confluence.atlassian.com/bitbucket/bitbuck...
    Ответ написан
    Комментировать
  • Git не коммитит папку?

    @Stqs
    senior software developer
    furcifer ,

    снимайте штаны и показывайте git status
    Ответ написан
    2 комментария
  • Правильная настройка локального git репозитория?

    @Stqs
    senior software developer
    Роман,

    Мужик, я ни хера не понял, что ты сказал мне, но ты мне близок. Ты заговорил и достучался до сердца (с)

    если Вам нужно включить один гит репозитарий в другой то используйте https://git-scm.com/docs/git-submodule
    если же Вам нужно что бы один и тот же локальный ссылался на несколько удаленных - тогда добавьте дополнительный remote к существующему репозиторию

    хотя я таки не совсем понял что именно Вы хотите
    Ответ написан
    Комментировать
  • Как настроить автоматическое удаление ветви VS?

    @Stqs
    senior software developer
    1) это нормально
    компьютер всегда делает/показывает именно то что есть на самом деле, он никогда вас не обманывает
    то что это не совпадает с вашими ожиданиями - обычно результат ошибочных представлений о механике вещей

    2) и да и нет
    разницы не будет пока вы не разберетесь с тем что существует remote репозиторий и ваша склонированная local верия этого репозитория
    и если вы удаляете ветку из remote то с какой стати она должна пропасть из локальной версии автоматически? нужно как минимум сделать pull
    то же самое с удалением ветки локально
    вы можете это сделать но это не означает что что-то автоматически произойдет с remote репозитарием
    то есть нужно сделать 2 вещи
    - удалить локальную версию
    git branch -d branch_name
    - пропихнуть это изменение в remote
    git push <remote_name> --delete <branch_name>
    Ответ написан
  • Добавлять ли virtualenv в git?

    @Stqs
    senior software developer
    Частенько бывает что часть пакетов нужна при разработке и не нужна на продакшене. И наоборот. Поэтому желательно бы еще разделять requirements для разработки и для продакшена.
    Файлы с requirements могут включаться один в другой. Таким образом обычно зависимости можно разделить на 3 отдельных файла.
    Например:
    reqs/
    - common.txt
    - prod.txt
    - dev.txt

    common.txt будет содержать все обязательные общие зависимости. Пример с потолка:
    Django==1.8.5
    mysql-python==1.2.5


    dev.txt будет содержать пакеты специфичные только для разработки но включая common. Пример опять же с потолка:
    -r common.txt
    ipyhton
    ipdb
    django-debug-toolbar==1.4


    prod.txt тоже будет включать common но так же содержать вещи которые на продакшене обязательны а в Вашем локальном окружении не нужны вовсе:
    -r common.txt
    gunicorn==19.4.1
    whateverelse=1.0.0


    соответственно когда мы собираемся разрабатывать мы устанавливаем зависимости так
    pip install -r reqs/dev.txt
    в продакшене
    pip install -r reqs/prod.txt
    Ответ написан
    Комментировать