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

    @Vitsliputsli
    Стандартно, gitflow. К примеру так: разработка ведется в отдельных ветках feature, для интеграции сливаются в dev, на основе dev создается release и после тестирования заливается в master, который и выкладвается в прод.
    Разные токены это относится к окружению, в коде этого быть не должно. Окружение собирается сборщиком деплоя, например в Jenkins.
    Ответ написан
    Комментировать
  • Есть ли смысл использовать Git?

    @Vitsliputsli
    Можно. Но, например, когда проект начнет работать вам понадобится добавить новую фичу, а следовательно у вас появится 2 версии и нужно будет их как-то легко разделять. Пока вы будете делать эту новую фичу, нужно будет сделать еще одну побыстрее, уже 3 версии. Можно наделать отдельные директории и переключаться между ними, использовать внешние утилиты сравнения, а можно использовать git.
    Когда через год понадобится разобраться, а зачем так было сделано, можно найти коммит, в рамках которого было внесено изменение и понять зачем. Еще лучше, если коммиты связаны с тасками в системе управления проектом.
    Когда наскучит вручную таскать код на сервер. Когда устанешь копировать файлики между версиями для переноса функционала. Когда все сломал, и понимаешь, что легко бы нашел причину, если бы фиксировал предыдущее стабильное состояние. И это только то, что первое приходит в голову.
    Ответ написан
    Комментировать
  • Как правильно решить конфликты в dev ветке для двух веток в разработке?

    @Vitsliputsli
    был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку.

    Не создает, конфликтующие ветки сами по себе, а конфликт решайте в ветке dev. При создании веток релизов из dev, этого было бы достаточно. Но, в вашем случае: сливаете первую ветку в master - тут все ок, а вот вторая будет опять конфликтовать, но уже с master, это решается мержем обновленного master в эту ветку. И да, вполне возможны расхождения dev и master, если 2 мержа были выполнены по-разному, поэтому мержите master в dev после таких манипуляций.
    Ответ написан
    Комментировать
  • Как удалить скрытые коммиты с GitHub?

    @Vitsliputsli
    Вы хотите странного, если коммиты делались, почему это не отображать?
    Но если очень хочется, при подобных действиях коммиты не удаляются, в дереве они не отображаются, т.к. ни к чему не привязаны. Чтобы удалить коммиты используйте git reflog expire или git reflog delete.
    Ответ написан
    Комментировать
  • Как слить 2 локальные ветки?

    @Vitsliputsli
    Можно, но не нужно. При переключении коммитьте изменения или используйте stash.
    Ответ написан
  • При вводе команды "composer update" выясняется, что нету доступа к репозиторию, почему?

    @Vitsliputsli
    В чем может быть проблема?

    Написано же: Host key verification failed.
    Ответ написан
    Комментировать
  • Правильное разрешение конфиктов при мердже PR?

    @Vitsliputsli
    Как можно поправить конфликты PR, чтобы лишние коммиты не попадали в develop?

    Не коммитить лишнее в develop. Удалите лишний коммит.

    Прод и тест не должны отличаться кодом. Если все же очень хочется что-то такое засунуть под контроль версий, то держите там оба конфига, а уже на конкретном сервере переключайтесь между ними.
    Ответ написан
  • Почему по гитфлоу принято начинать новые ветки от develop?

    @Vitsliputsli
    У gitflow есть разные варианты реализации, но чаще всего да, подразумевается создание из dev. Причина проста: dev - это ветка разработки, там уже могут быть реализованные фичи, которых еще нет в master, лучше сразу начать разработку с более новой версии, чем потом решать конфликты при мердже.
    Ответ написан
    Комментировать
  • Как организовать совместную разработку нескольких проектов в git?

    @Vitsliputsli
    Исходники проекта, ядра и модулей - это одно. Бизнес-проекты, для которых собираем билды из первых - это иное. Git - это система контроля версий исходного кода, она не занимается решением вопросов бизнеса. Поэтому не стоит через git решать вопросы кому какие модули были проданы.
    Если смотреть шире, то пусть разработчики пишут код (в одном репе, в нескольких репах: ядро и модули, как вам удобнее). А в каком виде собирать билд очередному заказчику пусть решают и делают другие люди (а если даже и те же, то все равно в рамках совсем иного процесса).
    Ответ написан
  • Каким образом можно изменить автора в коммитах GitLab?

    @Vitsliputsli
    При нормальной настройке, пользователи ходят в gitlab с разными учетками по паролю или ключу, поэтому такая ситуация невозможна.
    Ответ написан
  • Как сделать два гит репозитория в одном?

    @Vitsliputsli
    git submodule
    Ответ написан
    Комментировать
  • Какая правильная философия работы с ветками в git?

    @Vitsliputsli
    master - только для стабильного кода, который уже работает на проде.
    Новую разработку ведите в другой ветке (например, dev). Как стабилизируете и проверите код в dev, мержите его в master.
    На следующем этапе разработку в dev разбивайте на отдельные feature, там уже можно посмотреть что-нибудь вроде git-flow.
    Ответ написан
    1 комментарий
  • Как организовать модель ветвления GIT и отливку на стейжинг?

    @Vitsliputsli
    1)
    мне хочется, чтобы после исправления бага, новый коммит проходил проверку QA, но как организовать стейжинг пространство в этом случае? Слить код в нестабильный девелоп и выкатиться на стейжинг мы не можем, поскольку изменения девелопа могут нестабильно сказаться на релизе№1. Как быть?

    А в чем проблема? Отдайте hotfix в QA пусть проверяют. Как в случае feature QA тестирует ветку release-..., так и в случае hotfix, QA тестирует ветку hotfix/... .

    2)
    откуда разраб должен отпачковываться в данном случае, от девелопа или от ветки с фичой №1?

    Если фича №1 зависит от фичи №2, а в dev фича №1 отсутствует, то очевидно, что от ветки фича №1, других вариантов я не вижу.

    3)
    Согласно agile вторая команда, работающая над фичой№2 не может отправлять свой код в девелоп, иначе это замедлит поставку нового релиза

    Наверное agile здесь не при чем. Если работаете по scrum, то каждый спринт это подготовка нового релиза и вы не можете работать над фичей не из этого релиза. git-flow ориентирован именно на такую работу.
    Если релизы плавающие, я так понял у вас так, значит не сливайте фичи не из текущего релиза в ветку из которой готовите релиз. Если не выходить за рамки git-flow, то не сливайте в dev ветки не из текущего релиза, QA пусть тестирует либо feature, либо по тегам, если работаете с pull-request, то апрувьте их, но не делайте merge.

    Из всего выше описанного, мне кажется у вас 1 единственная сложность, это вопрос как должны работать QA.
    Ответ написан
    3 комментария
  • Как сделать так, чтобы изменение содержимого директории, которая была заменена такой же по названию, было замечено гитом?

    @Vitsliputsli
    Либо добавляемая директория идентична предыдущей, либо она в игноре.
    Директории отличаются? Что в .gitignore? Что пишет git status?
    Ответ написан
    Комментировать
  • Как перейти на разработку в команде?

    @Vitsliputsli
    Лучше, конечно, сразу на будущее поставить gitlab. Но в принципе, можете обойтись git и хорошим клиентом к нему (в первую очередь для diff). PHPStorm вполне достаточно. Для code review не так уж и нужны доп.инструменты. Даже не заморачивайтесь pull request, отдельных веток и мержа их в dev вашими силами вполне достаточно.
    Ответ написан
    Комментировать
  • Как закоммитить в другую ветку?

    @Vitsliputsli
    Если имеете ввиду, что у вас есть коммит в одной ветке, а вы хотите такой же в другой ветке, то cherry pick. Если коммита нет, то stash.
    Ответ написан
    Комментировать
  • Как организовать работу в команде через git?

    @Vitsliputsli
    Как уже советовали git-flow (например от Винсента Дрейзена). У разработчиков есть право мержить в dev свои ветки, поэтому request не нужны (они хороши при запросах от удаленных разработчиков), из dev собираете и прогоняете тесты ежедневно (CI), затем из dev собираете релиз и кидаете его в master, это уже делает отдельный человек. На сервере (если речь про прод) git быть не должно, должен быть нормальный CD. И да, никаких доступов к боевым у разработчиков. В остальном верно описали.
    Ответ написан
    Комментировать
  • Как правильно коммитить?

    @Vitsliputsli
    Делаете коммит с описание что сделали, что недоделали, начинаете коммит строкой "WIP: " (это стандартное сокращение означает "work in progress", многие системы игнорируют коммиты с таким началом описания).
    После того как продолжите работу и сделаете логически завершенный коммит, то сделайте rebase и уберите этот коммит из истории (разумеется, если ветка это позволяет).
    Ответ написан
    Комментировать
  • Существует ли GIT-клиент с ограниченной глубиной хранения?

    @Vitsliputsli
    Не там ищите, git - это контроль версий, а вам нужно резервное копирование.
    Ответ написан
    Комментировать
  • Важно ли сообщение "LF will be replaced by CRLF in" или можно не обращать внимания?

    @Vitsliputsli
    Нет правильного, все зависит от того, что вы хотите. Какие разделители строк вы хотите видеть в репозитории? Есть несколько вариантов, lf,crlf,cr, либо не преобразовывать, а записывать как есть. Сейчас вы выбрали преобразовывать в crlf, соответственно если git обнаружит другие переводы строк, то автоматом их преобразует, о чем и пишет в сообщении.
    Ответ написан
    3 комментария