Ответы пользователя по тегу Git
  • Что лучше использовать для мультимодульного проекта: subtree или submodule?

    Лучше воспользоваться системой управления зависимостями. Например Apache Ivy или аналогичной. Считается, что subtree и тем более submodule являются упрощенными и ограниченными по функциональности заменами нормальных систем управления зависимостями. Вот неплохое описание проблем связанных с использовани....
    Использование Ivy подразумевает наличие системы сборки проекта. Но возможности по управлению зависимостями открываются неограниченные. Особенно приятно когда у вас команда из больше чем 2-3 человек, 2-3 десятка библиотек и нужно поддерживать и развивать несколько версий приложения одновременно.
    Хотя Ivy написана на Java и очень тесно интегрирована в мир Java, она является универсальным менеджером зависимостей и мы использовали ее для управления зависимостями в проекте на C#.
    Возможно, для C++ есто что-то свое, но я далек от этого мира.
    Ответ написан
  • Gitflow мёртв? Какие есть альтернативы?

    Наверное он умер. Как слишком сложная концепция для такой простой вещи как Git.
    А, вот, почитайте еще про Trunk Based Developmentтут), чтобы еще больше усомниться в полезности GitFlow.
    Ответ написан
  • RTC jazz vs git. Стоит ли переходить с RTC на git?

    Ого! Jazz еще жив!
    В нем конечно хорошая интеграция всего со всем, но если вы этим не пользуетесь, да еще и его тяжеловесность является препятствием к использованию SCM, то лучше от него отказаться.

    Работа должна быть в радость. Git поощряет разработчиков делать частые коммиты. Это просто и быстро. Так же с Git проще экспериментировать с кодом.
    А еще Git - это mainstream. Разработчик с ним не пропадет.

    Но у многих пользователей централизованных SCM наблюдается проблема с осознанием распределенной структуры Git.
    Ответ написан
  • GIT: Зачем нужны указатели на ветки?

    Указатель позволяет обратиться к конкретному коммиту по осмысленному имени.
    Ни какой особой разницы между HEAD и именованными коммитами на ветки или тегами нет.
    Просто, если их не будет, вам же самому будет трудно отыскать нужную ветку или тег.

    Как можно по вашему использовать один HEAD для того чтобы показывать на текущий коммит и на коммиты веток? Он один должен будет показывать на все? И быть словарем, чтобы можно было в нем одном сохранить несколько разных указателей под разными именами? А теперь подумайте о распределенной природе Git и подумайте как бы вы синхронизировали такой HEAD между репозиториями. Как бы вы понимали какие ветки или тэги локальные, а какие нужно сливать в удаленный репозиторий.
    Ответ написан
  • GITLAB & Subtree - возможно ли?

    Придется пользоваться консольным клиентом. Я проверил работу git-subtree на версии Git 1.8.1.msysgit.1 под Windows.

    Я нашел в группе tortoisegit-dev запрос на добавление поддержки git-subtree датированный 27 февраля 2014 года. Думаю реализован он будет не очень скоро.

    На Windows очень удобно пользоваться Git из PowerShell с помощью posh-git.
    Ответ написан
  • Как организовать процесс разработки продукта на C++, используя GIT?

    Почитайте про набирающую популярность модель ветвления Trunk Based Development.
    При использовании этой модели вам потребуется ветка master (trunk) и ветки для релизных версий. В master вы ведете разработку (в вашей терминологии это development) для каждой версии выходящей к пользователям вы создаете отдельную ветку, например 1.0.x.
    Самое главное: все изменения вносятся разработчиками только в ветку master. Только ответственные люди могут создавать релизные ветки и переносить изменения из master в них, в том числе и при внесении изменений в выпущенные версии. Релизы
    собираются только с релизных веток.

    В этой модели разработчики не ограниченны в создании локальных веток, но их никто не хочет видеть на общем сервере. У разработчиков нет прав на создание веток на общем сервере.

    Процесс выглядит так:
    1. Разработчик делает pull master.
    2. Если нужно создает локальную ветку и работает в ней.
    3. Прогонят тесты на ветке и мержит ее с master.
    4. Делает push.
    5. CI видит новый коммит, получает его и выполняет на нем модульные, интеграционные и приемочные тесты.

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

    В том, что на CI не пройдут тесты нет ничего страшного. Он вообщем-то для этого и нужен. Откатывать коммит не нужно, нужно быстрее делать новый, в котором ошибка исправлена.
    Ответ написан
  • Как git добавил неизвестные коммиты?

    Это называется merge bubbles. Git создает merge-коммит во время каждой операции pull. Во время слияния 2-х веток Git может сделать или merge с созданием merge-коммита или rebase без создания новых коммитов. Кто-то настроил его так, что он всегда создает merge-коммиты.

    За данное поведение Git отвечает настройка branch.autosetuprebase.
    Данная настройка может иметь 4 значения:
    * never - Git никогда не выполняет rebase
    * local - Git выполняет rebase только для локальных веток
    * remote - Git выполняет rebase только для удаленных веток
    * always - Git всегда выполняет rebase.

    Для удобства выставите ее в always глобально.

    git config --global branch.autosetuprebase always
    Ответ написан
  • Как получить изменения git pull с автоматическим слиянием без конфликтов? Более последнее изменение - главное?

    Для Git нет понятия "более поздний коммит", для него все коммиты, сделанные от одного предка являются параллельными.
    В вашей универсальной команде вы создаете коммит, а потом во время pull просите разрешать конфликты автоматически используя изменения из удаленной ветки, то есть разрешаете конфликты в пользу ранее сделанных вами изменений. Что, как мне кажется, немного противоречит желанию использовать самые последние сделанные изменения.

    Возможно вам больше подойдет стратегия ours.

    git pull -s ours

    В этом случае ни какого слияния не производится, указатель просто перебрасывается на последний локальный коммит. Вся удаленная история изменений игнорируется.
    Ответ написан
  • Git did not exit cleanly (exit code 128)

    Авторизация на bitbucket осуществляется по ключу, поэтому логин и пароль нигде вводить не нужно.
    Вероятно проблема в ключе. Проверьте его регистрацию на bitbucket и доступ TortoiseGit к файлу закрытого ключа.

    Еще можно попробовать настроить консольный Git на использование вашего ключа.
    Для этого в директории пользователя C:\Users\[Логин]\ создайте папку .ssh и положите в нее файл закрытого ключа в текстовом формате OpenSSH дав ему имя id_rsa. Конвертировать ключ из формата Putty в формат OpenSSH можно с помощью утилиты из состава Putty.
    После этого попробуйте клонировать репозиторий командой
    git clone -vvv [URL репозитория]
    Ключ -vvv выдаст подробную диагностику процесса.
    Ответ написан
  • Как можно держать репозитарий на виртуалке, а редактировать файлы на винде, чтобы не менялись права файлов?

    Git распределенная система контороля версий, не нужно пользоваться ею как SVN. Клонируйте репозитории по необходимости, это же просто и можно делать локально.

    Создайте в разделяемой папке bare репозиторий Git:

    mkdir repo
    cd repo
    git init --bare


    В Ubuntu добавьте в репозиторий ссылку на только что созданный разделяемый репозиторий и выполните в него push имеющихся коммитов.

    git remote add origin [путь к папке разделяемого репозитория]
    git push origin master #отправляем ветку master в удаленный репозиторий по ссылке origin


    Теперь клонируем разделяемый репозиторий в Windows.

    git clone [путь к разделяемому репозиторию]

    и работаем в копии. Изменения отправляем и получаем командами push и pull.
    Ответ написан
  • MS Visual Studio 2013 + gitolite. Как подружить?

    Это проблема библиотеки libgit2. Судя по исходникам поддержка ssh была добавлена 12.12.2013, совсем недавно.
    У вас возможно используется одна из предыдущих релизных версий. Какая-то поддержка ssh появилась начиная с версии 0.20.0.
    Ответ написан
  • Git: merge branch. Как игнорировать определенные файлы при слиянии?

    Ветки пока не нужны, достаточно master.
    Если ваша активная разработка связана с внесением новых функций, необходимых заказчику, делайте все в ветке master. Я предлагаю вам сделать тег на той версии, которая работает у заказчика на боевом сервере. После этого продолжайте разработку в master и таким образом получите development версию продукта. Которую вы будете ставить на development сервер.

    Если у вас возникнет необходимость что-то поправить в боевой версии, делайте ветку с тега и вносите изменения в ней. При необходимости сливайте изменения на master.

    И помните Git - это не deployment tool. То как вы описываете свою проблему, наводит на мысль, что вы просто делаете pull одной из веток на серверах. Хорошо если я ошибаюсь, так как делать этого не нужно, плохо с точки зрения безопасности.
    Ответ написан
  • Как организовать синхронизацию сайта с bare-репозиторием на сервере?

    Универсальным решением будет использование сервера непрерывной интегации (Continuous Integration), например Jenkins.
    Сделайте на нем 2 задания, одно для ветки master, второе для вертки test. В этих заданиях в ответ на появление коммитов в ветке сделайте публикацию на сайт по SSH, FTP или простым копированием.
    Преимуществом подхода является то, что вся информация о deployment сосредоточена в одном месте - заданиях Jenkins, для разных проектов можно по разному организовать выкладку файлов на сервер, но принципиально задания будут одинаковыми.
    Если пойти дальше, то в этих же заданиям можно запускать автоматическое тестирование.
    Ответ написан
  • Как настроить Qt Creator + Git на GitHub в Fedora 18?

    Независимо от среды разработки можно действовать следующим образом.

    1. Создаете пустой репозиторий на GitHub или любом другом серверном Git. Это будет удаленная копия вашего репозитория.

    2. Создаете в своей любимой среде разработки новый проект.

    3. С помощью консольного или графического клиента Git создаете в папке нового проекта репозиторий Git.
    cd [Папка проекта]
    git init


    4. Делаете первый коммит, например с файлом .gitignore.

    5. Настраиваете ссылку на удаленный репозиторий в локальном репозитории, созданном в 3
    git remote add origin [URL удаленного репозитория]
    origin - имя ссылки на удаленный репозиторий

    5. Отправляете изменения во внешний репозиторий
    git push origin master
    здесь мы говорим отправить на удаленный репозиторий с именем origin ветку master из локального репозитория.

    6. Далее пользуетесь любым клиентом для работы с локальным репозиторием, включая встроенный в IDE.
    Ответ написан
  • Что лучше использовать для git: консольный клиент или графический?

    Git, по сравнению с SVN, поощряет делать частые коммиты. Поэтому проверьте как у вас быстрее получается сделать коммит: через командную строку или графическую утилиту.

    Если вы работаете на Windows, то возможно TortoiseGit будет для вас привычней после TortoiseSVN. Тем более что по умолчанию в Windows не работает автодополнение команд Git в командной строке.

    Если вы хотите приблизиться в Windows к удобству использования Git в *nix системах, попробуйте posh-git. Это расширение для PowerShell.

    Мне удобнее и быстрее делать коммиты, ветки и слияния, push&pull и теги из командной строки, а работать с историей и различиями в файлах проще из графических утилит.
    Ответ написан
  • Git для бэкапа бинарных файлов?

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

    mkdir 2014
    cd 2014
    git init
    …
    git add .
    git commit
    

    При этом ничто не мешает вам работать в репозиториях для прошлых годов и делать там коммиты.

    Если нужно сделать копию на другую машину. То клонируем на ней ваши репозитории. Или просто переносим их простым копированием.

    Но, если честно, вы придумали очень странное применение Git. Проблема даже не в том, что вы работаете с бинарными файлами, а в том что вы хотите делать коммит раз в год. Это очень очень очень редко.

    Ответ написан