а зачем два репозитория если можно вести две ветки в одном репозитории? это как бы более версионный подход к версиям чем та порнуха, которая у вас сейчас.
В консоли я уже попробовал. Не удобно то, что нужно лишний раз git add . прописывать и коммит делать перед пушем. В клиентах это делается автоматом. А мы не упрёмся на gitlab в какое-то ограничение потом? Я попробовал - ну не, из контекстного меню работать не удобно. Удобней же когда у тебя интерфейс какой-то есть с кнопочками. Вот тут например, даже отменить коммит можно в два щелчка. Вот надо тоже попробовать через шторм, чтобы не лезть в стороннюю тулзу каждый раз за коммитом или пушем. --- Добавлено --- На сколько я понимаю, главный репозиторий у нас один, он лежит в /home/example.com/git/ - мы всё пушим сюда. А от него идут "дочерние" или я хз как это правильно называется - /home/example.com/html/ и /home/example.com/dev/ - сюда мы пулим из главного репозитория. В dev из ветки dev, а потом dev мерджим в master и master пулим в html.
То ли ты вещи своими именами не называешь, то ли у вас реально хреново с версированием. Есть каталог репозитория, в нем есть ветки - фичи, дев, багфикс, блекджек, шлюхи, превью, продакшн и тому подобное. Простые смертные кодеры пушат коммиты в доступные им ветки. Насяльника разработки сливает в превью. Если тесты прошло - сливает в продакшн. Это всё ветки в репозитории. Куда из этих веток выливаются коммиты или дерево - другая история. Для каждой ветки и/или для каждого коммита можно создавать виртуальный хост и всё туда собирать и тестировать. Продакшн деплоится в папку боевого виртуального хоста. Как-то так. А еще есть непрерывная интеграция
У нас так и есть, /home/example.com/dev это dev.example.com. Ну а /home/example.com/html это соответственно ветка master и example.com. Не всё сразу, хотя бы GIT толком освоить сначала.
блин, ты реально тупой и защищаешь свою тупость. ты тупой и это уже не оскорбление на форуме. это факт. печально, чо.
Что не так? Код (Text): git pull origin dev https://NerdRage@gitlab.com/NerdRage/mywork.git fatal: Invalid refspec 'https://NerdRage@gitlab.com/NerdRage/mywork.git' На stackoverflow пишут следующее: https://stackoverflow.com/questions/19439501/git-pull-origin-master-returns-fatal-invalid-refspec Я попробовал сделать так - та же самая ошибка. Код (Text): git pull origin dev:refs/remotes/origin/dev https://NerdRage@gitlab.com/NerdRage/mywork.git fatal: Invalid refspec 'https://NerdRage@gitlab.com/NerdRage/mywork.git' Ветка dev у меня выглядит так:
Это что такое? Я просто закоммитил изменения у себя, запушил их на гитлаб, а потом на сервере пытался пулить. Это вся последовательность моих действий.
Может мне ещё все языки программирования изучить, прежде чем заходить на форумы? Форумы для этого и нужны, чтобы спрашивать, когда решения в гугле не помогли. З.Ы. Проблема была в том, что в pull не надо было добавлять ссылку на репозиторий: Код (Text): git pull origin dev Этого достаточно. Ссылка уже хранится где-то, то ли в репозитории сервера, то ли в настройках гита.
@igordata ты в жизни также общаешься? Сидишь на лавке и обзываешь всех шлюхами и наркоманами? У меня есть вопрос ПО ТЕМЕ. Есть ветка master, есть ветка dev. Столкнулись с такой фигнёй, что иногда нужно сделать какие-то небольшие изменения на master вперёд мега-изменений, которые ведутся на dev. Приходится вносить эти изменения два раза, сначала на ветку master, потом копипастить на dev, чтобы потом при слиянии не было никаких конфликтов. Нет способа проще? Я пробовал создать дочернюю ветку от master - hotfix, сделать изменения там, потом слить hotfix в master и потом hotfix в dev. Не прокатило, при этом ветка dev пытается откатиться до состояния master, что логично. В Git же можно ещё патчи делать вроде? Может как-то ими можно залить хотфикс на обе ветки?
@NerdRage погугли git workflow. Ты боишься того, что на самом деле удобно. Вы работаете над дев-ом, релизы сливаете в мастер. Заплатка сливается в мастер и тут же в дев - чтоб в дев-е был актуальный пофикшенный код. Если где-то возникает конфликт, то конфликт нужно резолвить. Не надо бояться конфликтов. Они вполне допустимы в жизненном цикле кода. И ответственный человек сможет принять решение и разрешить конфликт.
я понимаю, что твоя жизнь весьма печальна, но я не общаюсь со шлюхами и наркоманами. Как-то так. просто ты трусишь учиться. Видимо ты очень боишься слажать, и прячешь этот страх за дутыми понтами.
@igordata Поэтому у меня даже комментировать твои высеры никогда нет желания, ты пишешь на столько тупые вещи, что просто забей. Человеческий ресурс ограничен. Я только что освоил Git по мере своих возможностей и разобрался ещё не до конца. Можешь называть меня тупым или трусом из-за этого, но ты видимо слабо понимаешь что такое фулл-тайм работа, которая не оставляет времени и сил на изучение чего-то. Вряд ли ты вообще работаешь, учитывая что ты на этом форуме живёшь. --- Добавлено --- З.Ы. Нашёл такую штуку. https://internetdevels.ru/blog/git-flow-model Вроде это как раз то что я хотел, буду ставить и разбираться.
отмазался типа? ну-ну ты один в этом мире на фултайм работе. остальные учатся исключительно потому, что им высшие силы выделяют недели на изучение всякого нового дерьма
gitflow господа, gitflow. Всё уже придумано до нас и изобретено. @NerdRage , прочитай эти несчастные пару страниц мануала и всё
Сливаю первую свою большую фичу. Начал разбираться с тем как это делать и охренел как это не удобно. В итоге, как я это делаю. Сохраняю копию первой версии файла и копию второй версии файла, потом сравниваю их side-by-side в PHPStorm. А нет ли какой-нибудь удобной тулзы для разбора конфликтов? Я удивлён что в Source Tree не сделали никакого side-by-side.
Короче после того как я закоммитил файлы с конфликтами, в них остались маркеры: Код (Text): <<<<<<< HEAD $stts = $_P->get_buh_stats($_GET['id'], $row22['pay_date'], false, false, 1); ======= $stts = $_P->calc->get_buh_stats($_GET['id'], $row22['pay_date'], true, false, 1); >>>>>>> feature/calc_landing Их очень много. Есть какая-то тулза, которая может распилить такой файл на два файла, чтобы потом их можно было сравнить side-by-side? Не могу найти, хоть самому пиши парсер.
резолв конфликтс тыкаешь, там будет окошко где справа и слева разные версии, а в серединку ты скидываешь то или другое изменение или оба. --- Добавлено --- вообще доводить до конфликтов - крайне хуёвая идея.