Настройки доступны через иконку в углу вверху слева.
Поставь гуй. Соурстрии или что-то подобное.
1. Смени шинду, если ты не шарпит.
2. Установи git manager - Fork. Лучший менеждер.
3. Не рекомендую здесь вопросы задавать, тут 70% людей никогда не работали.
поставь Сурстри или любой другой GUI
> simple-memory-helper
В Android Studio и в IDEA есть такая кнопочка в меню сверху "VCS". Нажимаешь на неё, и никакой консольный Git тебе не нужен.
Windows terminal попробуй
ConEmu
/thread
gitkraken +gitcracken
Элементарные команды, это pull, push, merge, checkout
Это вполне реально выучить и самому просто распечатай 2 странички file:///C:/Users/vadim/Downloads/SWTM-2088_Atlassian-Git-Cheatsheet.pdf
А дальше уже начинаешь гуглить как сделать более сложные вещи когда понадобиться, запоминать совсем не обязательно. Я например где-то год гуглил как друпнуть ремоут бранч, пока не запомнил.
https://github.com/features/codespaces/
Накати tortoise git лучше ничего нет.
подниму еще раз:
Каким образом опытные программисты анализируют github на предмет поиска форков?
Допустим, я нашел проект хороший, общеизвестный, но у него есть некоторые проблемы. Кто-то из форкнувших возможно уже решил мои проблемы.
Как их быстро найти?
Как быстро понять в каком из форков значительные изменения, а в каком косметические?
SourceTree/VSCode/IntellijIdea
если на windows, то ставь TortoiseGit и вобще не лезь в баш
> но очень не нравится дизайн Git Bash
Обои скучные?))))
> Возможно ли накатить на нее какой-нибудь плагин чтобы покрасивее сделать?
Юзай встроенный в студии инструментарий, это ж иде она сама умеет в гит.
В операционной системе с названием Windows использовать консольные приложения - это идти против самой сути ОС.
Тред не читал, про окружения для Windows ничего не скажу, но
https://youtu.be/2sjqTHE0zok был для меня полезным видосом про Git. Удачи тебе.
А ещё sublime merge бесплатный
В качестве терминала юзаю wsltty ( https://github.com/mintty/wsltty ), но новенький Windows Terminal наверное тоже норм.
Какое же уебанское говно этот ваш Линукс. В первый раз я попробовал установить Убунту. Вставил в процессе установки usb Wifi приемник, так это хуйня после установке при первом заходе в консоль вылетела и начала орать на мое usb устройство.
Потом попробовал скачать ещё один дистр, вроде как на основе дебиана. Нашел драйвера на оф. сайте для моей hd6700, установил, и понял, что лучше бы дефолтные оставил (которые минимум на 30% были медленнее дров для винды). Прикол в том, что эти драйвера крашнули всю систему (да, они не удалялись почему-то, на форумах мне посоветовали пойти нахуй) и пришлось переустанавливать. Складывается впечатление, что на старых компьютерах и компах с экзотическим железом лучше использовать Винду.
>Винда шоб играть в игры, линукс шоб кодить
Сразу видно вкатывальщика, который, считая себя охуенным программистом, накатил себе арч и обклеил ноутбук наклейками, а реально умеет только писать хеллоуворлды.
Кодить по сути можно на чем угодно, поскольку IDE кросс-платформенные. Выбирают либо мак из-за его охуенного интерфейса, либо винду, поскольку с ней не надо пердолиться. В некоторых случаях язык привязан к платформе, но это опять же винда/мак. Линукс, кроме редких случаев вроде программирования под микроконтроллеры, не имеет никаких преимуществ перед этими двумя системами. Консоль вместе со всеми утилитами настраивается за пять минут что на маке, что на винде, а все необходимые для разработки программы имеются на каждой системе. Разница всего одна - винда/мак работают из коробки, и работают хорошо, а с линуксом нужно специально возиться. Как итог, почти весь энтерпрайз кодит на винде, конторы побогаче или смузи-стартапы - на маках, а на линуксе сидят полтора поехавших инвалида.
Есть ещё отдельная категория, это анальные попенсурщики, которые могут каждый месяц донатить своему любимому проектику на гитхабе по 500$, но будут пользоваться только бесплатным и свободным ПО по типу линуха, годота, блендера. Я сам не против свободного ПО, но у них это доходит до такого абсурда, что он даже пиратку винды не хочет использовать, ибо в этом случае злые майкрософты наварятся на его персональных данных и украдут его отборную коллекцию прона с лошадьми.
>Консоль вместе со всеми утилитами настраивается за пять минут что на маке, что на винде, а все необходимые для разработки программы имеются на каждой системе.
Какой то плач неосилятора. Каждое твое предложение не выдерживает никакой критики. Ты не работаешь программистом это факт. Ты не писал ничего серьезного. Ты ничего не юзал кроме C#/Java/Visual C++. Ты не шаришь в ОС вообще. MacOS это Unix, в ней все также как в Линуксе. Но Мак почему то работает из коробки, а Линукс нет. Ты не знаешь, что на Винде нельзя просто так взять и начать программировать на любом языке. Потому что даже Гит нормально не поставишь. Так как он написан на Си, а сишные либы не заводяться без пердолинга в Винде.
>Какой то плач неосилятора.
>Каждое твое предложение не выдерживает никакой критики.
>Ты не работаешь программистом это факт
>Ты не писал ничего серьезного
Ну раз ты сказал.
>Ты ничего не юзал кроме C#/Java/Visual C++
Мои основные языки это Python и С++.
>Но Мак почему то работает из коробки, а Линукс нет
Потому что мак создавался специально для десктопов, а линукс нет. На серверах линукс работает прекрасно. До инвалидов, пытающихся использовать его как десктопную систему, никому нет дела.
>Ты не знаешь, что на Винде нельзя просто так взять и начать программировать на любом языке. Потому что даже Гит нормально не поставишь.
Ты же натуральный вкатывальщик, у которого главная проблема это поставить гит. Я бы еще понял, если ты упомянул бы разницу в архитектуре и API винды и линукса, из-за которой, например, в винде процессы не умеют в fork, что влияет на огромное количество вещей. Но ты попросту обосрался при установке гита, и теперь кукарекаешь что на винде нет программирования. Гит, кстати, работает нормально. Пруф - пикрил.
>Так как он написан на Си, а сишные либы не заводяться без пердолинга в Винде.
Если либы написаны без использования API операционной системы, то достаточно просто перекомпилять, в противном случае придется адаптировать, заменяя некоторые функции, но и это как правило не проблема. Гит и другие пердоинструменты (ssh, grep) портированы на винду.
>>1740004
>Гит, баш, докер и многое другое нормально не ставится.
Гит и баш ставится. Для докера появился WSL-2 с полноценным ядром линукса.
Ну не знаю, звучит как фигня из историй моей бабушки. Я всегда был "на ты с кампухтерами", у меня в принципе всё с первого раза работает. Я как-то ставил арч просто походу читая вики через текстовый браузер.
Но это давно ещё, когда я по дистрибутивам лазил и выбирал
>Потому что мак создавался специально для десктопов, а линукс нет.
Что это блять вообще значит? Linux - это ядро ОС. Она создавалась для ОС. Ты с ядром не взаимодействуешь вообще никак. Люди на ведре работают с linux ядром и им норм.
А именно дистрибутивы они как раз для десктопов создавались. Для чего создавался Ubuntu, Fedora Workstation? Для десктопов же.
> До инвалидов, пытающихся использовать его как десктопную систему, никому нет дела.
Почему бы нет? На linux удобнее разрабатывать, плюс знания линукса нужны при деплое. Вот как раз не кодеров которые ставят убунту и играют в игры через вайн я не понимаю. А программисту как раз линукс - это самое то.
Я вообще не понимаю в чём суть этого спора. Ну удобно тебе на винде, сиди на винде. Это вопрос удобства же. Я под виндой тоже на одной из работ писал на крестах, ничего плохого сказать не могу. Кроме того что надо было с виндовским API и говнореестром работать.
>что даже Гит нормально не поставишь. Так как он написан на Си
все проще. гит это лютый набор костылей, которые были нужны конкретно одному человеку конкретно для разработки одной вещи. Причем этот человек имеет свое, весьма чокнутое, видение на то, как должны использоваться инструменты
А причем тут юниксвей? Сделать продукт с кривой архитектурой и крайне спорными и откровенно неудобными решениями - это жопоруковей.
>гит бы не распространился так сильно
Популярность чего либо не связана с качество продукта. Правило "миллионов мух"
Примеры?
Винда на десктопах преобладает. Значит винда норм ось, хуле вы жалуетесь.
JS вон какой популярный. Значит годный язык. Правда зачем то гугл сделал свой дарт на его замену, а мс тайпскрипт - ну они не понимают видимо всей мощи этого языка.
VHS против бетамакс туда же
в судьбе гита решающую роль сыграл авторитет автора и удобная соцсеть гитхаб. И таким образом инструмент для написания линуксов причем в стиле "линусвей" (без к) стал стандартом.
Такой хороший продукт, что написано аж миллион статей на тему как пользоваться этим хорошим продуктом, чтобы не стрелять себе в ногу )
>Популярность чего либо не связана с качество продукта.
Во-первых, часто связана. И винда нормальная ось для домохозяек, и жс для своего времени был хорошим скриптовым языком (если бы микрософт впилил в ие нормальный язык вместо вбскрипта, который он пытался продвигать, не было бы сейчас жс, но тогда из альтернатив были в основном перл и баш). И бета во многом всасывает у VHS, у technology connections есть серия видео на эту тему.
Во-вторых, популярность чего-то в сообществе профессионалов, работающих каждый день - это еще более сильный показатель, чем просто популярность. Потому что любитель может воспользоваться говном по каким-то причинам (дешево, низкий порог вхождения, агрессивная реклама), профессионал же играет вдолгую и для него любые недостатки его инструментов тут же выливаются в большие потери, а эти потери спускают профи вниз по лестнице конкуренции.
Тут тоже бывают исключения, типа, вход рубль выход два. Но система контроля версий - это не ось и не язык программирования, никакого лока на них нет, если у тебя не масштабы гугла конечно. Любая средняя компания может перейти с одной системы на другую хоть попроектно. Однако не переходят. Потому что гит очень хорош.
>Во-вторых, популярность чего-то в сообществе профессионалов, работающих каждый день - это еще более сильный показатель, чем просто популярность
именно что среди профессионалов. Которые
а) умеют ковыряться (оно же красноглазие воспетое в веках)
б) их совсем не парит этот процесс. они не считают это дикостью
в результате выбор был не из "таак а давай сравним недостатки и достоинства вариантов", а "линус написал софтину и призвал ее юзать. это ж линус, он вот юникс придумал"
и типичный выбор был "мы хотим перейти с свн, а тут вот известный человек свою dvcs написал, давайте попробуем. ооо круто (по сравнению с свн не спорю)"
если кто реально сравнивал, например, мозилла проводила диспут с придиркам на тему кто из dvcs чего умеет и выбрала не гит.
ну а дальше гитхаб и многие тулзы стали впиливать по дефолту гит и уже никто ничего не выбирал - "у нас на работе требуют гит. мы берем инструмент а там гит" и так далее.
так что не стоит про "это инструмент хороший потому и победил"
ну что это за система контроля версий в которой косяк на косяке
- непродуманной системой команд
- не умеет вести трекинг переименования файлов
- примитивный мерж
- вместо веток просто именованные головы
- считает комиты мусором, если на них не навешен указатель
- и такая особая радость как отсоединенные комиты
- не может запомнить какие комиты публичные и их уже трогать нельзя.
- для которого нужны сотни мануалов как делать нельзя чтобы все не запороть.
И это очевидные недостатки гита что я вспомнил по быстрому. А если сюда добавить удачные решения из других DVCS, которых НИКОГДА не будет в гит в силу ущербности архитектуры, то список будет больше.
Да, ставь TortoiseGit на винду
есть ветка мастер. там 2 файла 'a' и 'b'
делаем бранч 'test' где в 1 комите переименовываем 'a'->'c' (при этом делая его похожим (моделируем ситуацию) на содержимое 'b')
и удаляем также 'b'.
далее работаем с 'c' (который ранее был 'a')
в это время продолжается работа в мастере над 'a' и 'b'
и вот ребейс 'test' на мастер. вопросы сеньору девелоперу
1 что будет в результате в 'c'?
2 как потом починить?
3 как сделать правильно ребейс в таких условиях?
4 каким нецензурным словом обозвать сие поделие, которое смеет называть себя "лучшей системой контроля версий"?
Я сделал все твои шаги, после ребейза возник конфликт, который был разрешен через git mergetool автоматически (дважды выбрал modified). Теперь в репе 3 файла, a b и c, все с валидным содержимым (a, b чужая работа из мастера, c - новая работа).
Это самый веселый тип собседований, когда хуй перед тобой нахуевертил хуйни, а ты должен сидеть и угадывать, где именно он нахуевертил. Типичная ситуация, когда вчерашний джун быстро перешел в менеджмент, а скиллы как были джунские так и остались.
>3 как сделать правильно ребейс в таких условиях?
ребейз в таких условиях делать не правильно. Он переписывает историю, это вещь опасная, и хорошо работает лишь для небольших локальных правок истории с теми коммитами, каждый из которых делал лично ты. Если делать его в таком режиме (режиме педрильных сойбоев, которым НИКРАСИВА, по типу пикрелейтед), то история оттестированных человеком коммитов будет переписана маняисторией, не несущей никакого смысла. То есть буквально, до ребейза у тебя если есть коммит, его написал человек. Он точно работает. Мердж-конфликты находятся в мердж-коммитах, если там нарисовался баг, bisect его найдет. После ребейза - выглядит красивенько, патчик, патчик, патчик, но на деле это уже не история изменений. Если хочется чистой истории, есть merge --squash.
И гит тут не при чем. Не изобретен AI, который бы позволял превращать граф патчей в линейку, идеально разруливая конфликты. Где-то может быть чуть лучший механизм разруливания конфликтов, где-то худший, но принципиально подбная вещь (ребейзы на мастер) является большим злом.
>хорошо работает лишь для небольших локальных правок
ну вот я отпочковался от мастера и сижу себе в бранче навожу рефакторинг. утром проснулся забрал с мастера изменения, моя ветка устарела и мне ее нужно актуализировать. Или мерж или ребейс. Ребейс тут неплохо подходит
>Теперь в репе 3 файла, a b и c, все с валидным содержимым
не может остаться a и b у тебя в ветке, ведь ты их удалил
а насчет конфликтов - у меня он ругается что 'a' есть в мастере, а у меня удален и я принимаю вариант "удалить конечно". А далее он молча вливает b в с и получаем бред
>И гит тут не при чем
Еще как причем. Гит не трекает переименования, а занимается угадайкой, потому и такие результаты.
Гит вообще ничего не хранит - ни переименований, ни о том что комит публичный, ни имя ветки, ни откуда взялся комит. Все сам записывай в сообщение к коммиту
Линус имеет слабое представление, какой дожна быть нормальная система контроля версий - а именно помогать пользователю вести историю действий, а в резульате мы имеем этакий менеджер бэкапов, который фальсифицирует историю и нужно быть очень внимательным
>Ребейс тут неплохо подходит
Нет, он вообще не подходит. Ребейз переписывает историю, выкидывая настоящую насовсем. Одно дело поменять местами и сосквошить какие-то простые локальные коммиты перед пулл-реквестом. Другое - постоянно пользоваться им вместо git pull. Буквально постоянно переписывая историю и ругаясь на то, что гит переписывает историю. Это шизофрения.
Про файлы - это не корень проблемы, а незначительная подробность. Твой пример можно переписать на функции:
"делаем бранч 'test' где в 1 комите ВНУТРИ ФАЙЛА переименовываем 'function a(yoba)'->'function a(yoba)'" - и далее по тексту. Это полностью аналогичная ситуация. Она сводится к следующему:
1. Был создан мердж-конфликт.
2. Программист его неправильно отрезолвил (в твоем случае ты нажал use deleted file вместо use modified file)
3. Так как он сделал rebase вместо мерджа, результат ребейза можно выкидывать на помойку, даже если он после этого час разруливал другие конфликты. Хуже того, настоящую историю придется искать в мусоре.
Первые два пункта - они окей. Мердж дело сложное, все делают ошибки, и правильная тактика предотвращать конфликты. А вот третий пункт - это ССЗБ. Ты попросил гит переписать тебе историю твоих изменений, он ее переписал. Меркуриал поступит точно так же: 'Rebase will destroy original changesets unless you use "--keep".' (https://www.mercurial-scm.org/wiki/RebaseExtension) А далее оказалось, что переписанная история оказалась неправильно отрезолвенным конфликтом. От подобного стиля работы тебя никакая vcs с ребейзом не спасет. Единственный вариант выпилить эту удобную для своих задач функцию нахуй, ну либо заводить йоба undo, заводя контроль версий для контроля версий (yo dawg). Но это как раз вопрос юниксвея, в котором считается, что если юзер написал rm -rf .git, значит он хочет удалить репозиторий нахер, а не то что юзер дебил и не делает бэкапов.
В случае git pull у тебя никакая история бы не переписалась. Была бы четкая нода в графе, указывающая на две ноды. Если что-то поломалось и пропало, изменения затреканы. bisect работает. Каждый коммит - настоящий. Если после пуша в мастер что-то поломалось - сразу ясно, в какой точке графа. Твой колега делает diff и видит, что всю его работу ты удалил. Достает файл одной командой и дает пиздюлей. Все довольны. А просто не нужно было делать ребейз.
Я прекрасно понимаю чем ребейс отличается от мержа, но "запретить ребейс" это перебор. Он отличное средство для переписывания истории...когда нужно ее переписывать.
>2. Программист его неправильно отрезолвил (в твоем случае ты нажал use deleted file вместо use modified file)
да блин это ни на что не влияет. Если выбрать 'use modified file' то просто появится еще файл 'a' и это никак не влияет на 'c'
потому что гит отрабатывет 2 конфликта
1 'а' удален в одной из веток
2 'b' похож на 'c'
в первом случае он спрашивает, во втором разрулил молча и получил неправильный результат
Почему? да потому что у гит ущебная архитектура, которая не хранит то, что надо бы хранть с точки зрения здравого смысла, но линус это... линус.
это не ребейс плохой. это инструмент кривой. и такой и будет всегда
>Меркуриал поступит точно так же:
ну он то как раз правильно разрулит данную ситауцию. Меркуриал хранит переименования и точно знает что 'a' -> 'c' и ему плевать на степень похожести 'b' и 'c'.
>йоба undo
кстати в меркуриле он тоже есть. и позолит легко откатить такую ситуацию хоть на несколько ребейсов назад.
дело ведь не в ребейс. это просто пример показательный. дело именно в ущебности архитектуры гит, которая приводит к тому, что нужно запоминать, записывать, учитывать и так далее
то есть уживаться с особенностями ущербной системы, достоинство которой только в том что "ну оно стандарт"
и вообще бог с ним с ребейсом
от замены ребейса на мерж - результат будет тот же.
Ты гуляешь по минному полю, и приводишь пример, типа "я супер профи и знаю что делаю, ребейз норм, а вот тут бы меркуриал меня спас от мины, а из-за гита я без ноги". Тут спас, там не спас. Не гуляй по минам. Рано или поздно ты столкнешься с кривым автомержем в любой vcs. Если ты думаешь что меркуриал чаще мерджит лучше, это не так. В том числе и с точки зрения трекинга файлов по истории vs. content based. Собственно я твой случай так и не воспроизвел. Гит оставляет все файлы. Я уже дважды это перепроверил. Ситуации бывают разные, кривые мержи случаются, а чтобы с ними не было проблем, просто не ребейзь. Тогда если shit happens, у тебя все изменения будут в репозитории и проблема вообще выеденного яйца стоить не будет. А надеяться на undo - да хуй, заметишь ты результаты кривого мержа через неделю, и вспоминай, куда делись твои изменения.
>твой случай так и не воспроизвел. Гит оставляет все файлы
я без понятия что ты делаешь.
есть мастер. ты от нее отпочковался и в своей ветке удалил файл. в мастере он остался и изменился. когда ты затянул новый мастер и сел на голову мастера своей веткой (в которой файл должен быть удален), то у тебя файла быть не должно, ведь твоя ветка в которой файл удален выше головы мастера. Ну или влей мастер в свою ветку с тем же результатом.
да и неважно удален или нет - это на решение пользователя. совсем другое дело автоматическое вливание изменений из "источника", который на самом деле не источник - тут молча в файле 'c' появляются строки из 'b' потому что гит ОШИБОЧНО считает что 'b' прародитель 'c'.
Обнаружить можно сразу, а может и нет, но...обнаружил и что....что дает это обнаружение? можно отменить мерж и что дальше? выставить процент совпадения поменьше, чтобы он сам не вливал и мержить копипастом? Удобна )
>Ты гуляешь по минному полю, и приводишь пример, типа "я супер профи и знаю что делаю, ребейз норм, а вот тут бы меркуриал меня спас от мины, а из-за гита я без ноги"
Ты подменяешь понятия. Ребейс/и мерж (или только мерж) - части нормального рабочего процесса.
Но гит тут заботливо подкладывает мину. Исключительно потому, что это гит. Потому что так придумано дядькой линусом изначально, что "не нужно трекать файлы, будем угадывать", что и приводит к описанной ситуации.
Этим и отличаются продуманные системы от непродуманных. В мерке данной мины не будет.
А еще там есть evolve
А еще там не принято затаскивая изменения сразу их мержить, даже не видя что тащишь. Там не считается нормой "решил глянуть что нового, а уже решаешь конфликты"
> что меркуриал чаще мерджит лучше, это не так.
для тех кто юзает гит не должно волновать, что там делает мерк и другие. их должен волновать тот факт что гит занимается угадайкой и "вливает не то" или в раскопках "ведет не туда".
В гите много неудобств, к которым можно привыкнуть, но как можно привыкнуть к минам...
У меркуриала свои недостатки вытекающие из архитектуры, но их хотя бы можно понять.
Подход гита тоже можно понять - потому что линус так решил.
Вот понять почему народ считает это достоинствами и критикует всех, кто спрашивает "ну епрст, почему очевидные вещи или отстуствуют или перусложнены, где смысл делать именно так, WTF?" - уже сложно
>>1773144
угу. накладки из-за игры слов
>я без понятия что ты делаешь.
Пытаюсь воспроизвести твой баг по описанию, лол. Либо файлы разные, либо мерж-конфликт. Работает только с таким алгоритмом
1. checkout -b test
2. Переименовать b в c
3. отредактировать c
5. Не трогая b в мастере, смержить назад
Если в шаге 4 дополнительно модифицировать b в мастере, как ты писал изначально, возникает конфликт, который решается буквой m.
Если же b не трогать, то git действительно думает, что b переименовали и добавили туда пару строк, в случае такого факапа фиксится это просто
>выставить процент совпадения поменьше, чтобы он сам не вливал и мержить копипастом? Удобна )
git checkout master b, наркоман
>совсем другое дело автоматическое вливание изменений из "источника", который на самом деле не источник - тут молча в файле 'c' появляются строки из 'b' потому что гит ОШИБОЧНО считает что 'b' прародитель 'c'.
В большей части ситуаций ИРЛ гит автомерджит лучше, по мнению твоей же мозиллы https://wiki.mozilla.org/SCM/HGtoGit , у меня такое же впечатление. Соответственно занимаясь порочной практикой ребейзинга у тебя больше шансов соснуть именно с меркуриалом. Ты просто черри-пикнул один экзотический случай. В другом случае случае такой же степени экзотики соснет меркуриал со своим трекингом предка по своей внутренней истории вместо конктента. А в большинстве случаев соснут все. Не нужно создавать ситуаций, где автомердж не тривиален, это не приводит ни к чему, кроме багов.
>Ты подменяешь понятия. Ребейс/и мерж (или только мерж) - части нормального рабочего процесса.
Смотря какой. Типа >>1773194 - ок. Тот, который ты описал - нет. Это как раз твой любимый случай про "миллионы мух", то, что люди так делают не делает такой воркфлоу чем-то хорошим. У тебя же изначально было несколько вопросов, из них второй - "как пофиксить то что я нахуевертил в истории".
>Вот понять почему народ считает это достоинствами и критикует всех, кто спрашивает "ну епрст, почему очевидные вещи или отстуствуют или перусложнены, где смысл делать именно так, WTF?" - уже сложно
Не-а. Ты начал с "гит это лютый набор костылей", а закончилось все тем, что мне пришлось объяснять, почему ребейзить мастер конфликтами, а потом спрашивать "ой, а куда делись мои изменения" - это не про набор костылей, а про твое личное неосиляторство. Оно и при свитче на hg никуда не деется.
А у меня был другой мессадж - при правильном воркфлоу поебать какая у тебя система контроля версий, поэтому можно выбрать дефолтную. Тонкости типа в какой именно момент отвалится нетривиальный мерж не важны, фичи типа evolve вредны.
>для тех кто юзает гит не должно волновать, что там делает мерк и другие.
Почему? Сменить систему контроля версий совсем недолго, особенно при начале нового проекта. Если бы была штука, которая сделала бы меня хотя бы на 30% эффективнее, я бы поменял. А за 5-10 лет перекатились бы все, это же ебать сколько нервов экономится. Только вот не делает меркуриал на 30% эффективнее, большей частью это тот же гит с 2-3 говнопрактик для неосиляторов, и с пользователями этих говнопрактик мне еще придется работать. Ну нахуй.
я получаю ровно 1 конфликт - что 'a' удален. После его разруливания с любым вариантом больше никаких конфликтов
может у тебя похожие куски кода. я специально взял большие различные куски для теста и не лез в настройки "похожесть"
> git checkout master b, наркоман
И как это поможет делу? Нужные мне изменения лежат в 'a', мне нужно перетащить их в 'c'. Знай гит о том кто куда ренеймил, но он не знает.
>В большей части ситуаций ИРЛ гит автомерджит лучше
меньше конфликтов не значит лучше. У меня b влился в c без конфликтов, а лучше бы был конфликт.
>Соответственно занимаясь порочной практикой ребейзинга у тебя больше шансов соснуть именно с меркуриалом.
вот прицепился ты к ребейсу. Я уже 10 раз говорю что с мержем тот же результат. Забудь про ребейс.
>В другом случае случае такой же степени экзотики соснет меркуриал со своим трекингом предка по своей внутренней истории вместо конктента.
Нельзя отрицать, что идеальных систем не бывает. Но мерк со своим трекингом имеет куда меньшие шансы подложить такую свинью. Так то очевидно что практика "давай угадаем источник переименования" априори куда более подвержена "получили херню" чем то, что основано на трекинге, то есть на знании.
потому звучит как "а вот если бы у бабушки были..."
>соснет меркуриал со своим трекингом предка по своей внутренней истории вместо конктента.
А вот тут ты ребенка с водой выплеснул. У мерка и гита абсолютно одинаковая фича - перетащить данные по ренеймам при мерже. Разница лишь в том насколько достоверно определяется источник ренейма. Угадайка против трекинга.
все таки hg дает результат получше, тем что втаскивает что надо куда надо. гит втаскивает ТОЧНО ТАК ЖЕ. просто не всегда откуда надо
Ты поносишь трекинг, как будто угадайка лучше )))
>Ты подменяешь понятия. Ребейс/и мерж (или только мерж) - части нормального рабочего процесса.
>Смотря какой. Типа >>1773194 - ок. Тот, который ты описал - нет. Это как раз твой любимый случай про "миллионы мух", то, что люди так делают не делает такой воркфлоу чем-то хорошим. У тебя же изначально было несколько вопросов, из них второй - "как пофиксить то что я нахуевертил в истории".
не я нахуевертил, а гит. не нужно путать. и еще раз - то же самое он нахуевертит в мерже. Ну ребейс разве что откатывать неудобнее, но как мержить все равно не ясно.
остальное я вообще не понял о чем ты.
> при правильном воркфлоу поебать какая у тебя система контроля версий, поэтому можно выбрать дефолтную.
Можно и архивами кидаться, зачем вообще еще какая то система контроля версий. Да и вообще раньше народ с cvs жил. Жил же и никто не умер.
>Не-а. Ты начал с "гит это лютый набор костылей"
так это и есть. и я придерживаюсь этой точки зрения. да да я читал на хабре статьи про 2*3=5. но в моем примере ребейс не имеет значения (и это доказывается что в мерже та же фигня), а имеет значение именно фундаментальный костыль гита - "не трекаем, значит будем гадать"
Я указал на фундаментальный недостаток git. ты же перевоишь в плоскость "не так используешь". демонизировал ребейс, щас и до мержа дойдет
>hg никуда не деется
>фичи типа evolve вредны.
ну тут я уже просто не знаю что сказать. запасной парашют вреден по твоей логике. хотя еволве это не только undo, но как undo он шикарен
>Почему? Сменить систему контроля версий совсем недолго, особенно при начале нового проекта. Если бы была штука, которая сделала бы меня хотя бы на 30% эффективнее
Ну это уже истории из мира радуг и пони. Ну или ты решил пошутить. Ты же шутишь да?
>Пытаюсь воспроизвести твой баг по описанию, лол. Либо файлы разные, либо мерж-конфликт. Работает только с таким алгоритмом
git init
#создаем файлы
printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n11\n12\n13\n14\n15" > 1.txt
printf "a\nb\nc\nd\ne\nf\ng\nh\ni\nk\nl\nm\nn\no" > 2.txt
git add .
git commit -m 'init'
#уходим в ветку
git checkout -b renama
#переименование для обмана глупого гит
# на деле нет никакой пользы от git mv в данном контексте, аж никакой ну вообще
# но для вида пусть будет
git mv 1.txt from1.txt
git rm 2.txt
printf "a\nb\nc\nd\ne\nf\ng\nh\ni\n10\nl1\n12\n13\n14" > from1.txt
git add from1.txt
# уже тут видно что НЕ УГАДАЛ
git status
#On branch renama
#Changes to be committed:
# (use "git restore --staged <file>..." to unstage)
# deleted: 1.txt
# renamed: 2.txt -> from1.txt
# но идем дальше посмотрим чем это грозит в мерже
git commit -m 'renames'
# возвращемся в мастер и продолжаем работать с оригиналами внося изменения для мержа
git checkout master
printf "1\n2\n3\n4\n5\n6\n7(I am 1.txt)\n8\n9\n11\n12\n13\n14\n15" > 1.txt
git add 1.txt
git commit -m 'work 1'
printf "a\nb\nc\nd\ne\nf\ng\n(I am 2.txt)\ni\nk\nl\nm\nn\no" > 2.txt
git add 2.txt
git commit -m 'work 2'
# прыгаем в ветку и вливаем в нее мастер
git checkout renama
git merge master
cat from1.txt все покажет
и ничего гит не скажет на это
(информация про удаление файла 1.txt бесполезна)
Повторю ту же мысль, которую писал: ты после мерджа в любой VCS должен запустить дифф и посмотреть, все ли так, как ты хотел, не засрал ли ты чей-то код, не поломалось ли чего. И в любой VCS подход сначала смержить и запушить, а потом слушать маты коллег - так себе.
Ты ведь с таким слепым подходом поломаешь чей-то код, в котором было "include 1.txt", а теперь нужно (нужно ли?) писать "include from1.txt". И это блядь классика жанра.
Вся проблема в том, что имя файла в коде не значит нихуя.
>cat from1.txt все покажет
git diff master все покажет. Что файл 2.txt переименован в from1.txt, 1.txt удален. Далее надо обраться к коллеге и спрашивать, что он там понаделал в 1.txt и как не сломать ваш код.
Фиксится при этом все элементарно без редактирования текста - через git checkout master 2.txt, например.
Вот и подумай, с кем работать будет приятнее, с любителем гита, который удаляет файлы аккуратно, или с тобой, который работает как слон в посудной лавке, надеясь, что волшебная VCS ему все разрулит, и даже не делает git diff master перед коммитом.
> ...
Уже претензий к ребейсу нет. Теперь имя файла ) Имя файла я взял просто для теста.
Я вынужден в очередной раз напомнить свое утверждение - в гит кривая архитектура и неудачные решения, которые подкладывает мины.
А в ответ я слышу только образное "ну так стань хорошим сапером и у тебя не будет проблем".
Способность разгребать последствия кривости инструмента не делает этот инструмент хорошим.
Более того, даже если это описано в доке (еще один аргумент от защитников), тоже не делает костыль нормальным решением
>git diff master все покажет. Что файл 2.txt переименован в from1.txt, 1.txt удален. Далее надо обраться к коллеге и спрашивать, что он там понаделал в 1.txt и как не сломать ваш код.
Замечательно. Просто замечательно.
- Нужно постоянно помнить что куда переименовалось. Самому. Вместо гита
- Найдя подобную мину разгребать последствия вручную
- дергать коллегу и справшивать чо он сделал. хотя коллега может быть кто угодно в мире, да и история для этого и ведется как "кто чо сделал"
Какой чудесный инструмент). Зато лучший )))
>Фиксится при этом все элементарно без редактирования текста - через git checkout master 2.txt, например.
В упор не пойму каким образом это что то исправляет. Ну положит он вам 2.txt рядом. Зачем он вообще?
И даже если вытащить 1.txt который и нужен, то все равно изменения дальше ручками переносить
>вот и подумай, с кем работать будет приятнее, с любителем гита, который удаляет файлы аккуратно, или с тобой, который работает как слон в посудной лавке, надеясь, что волшебная VCS ему все разрулит, и даже не делает git diff master перед коммитом.
Мне будет приятнее работать с cvs, которая записывает за мной и не занимается угадыванием, не раскладывает мне граблей и не усложняет процесс разработки
И люди тут не причем. Ничего не сделал абстрактный коллега в данном случае. Более того, удаление "аккуратно или нет" сделано в моей ветке.
И если dvcs все сделает правильно и у меня просто не окажется мины, что мне придется выискивать через diff и потом героически разгребать- вот тут мне работать приятнее
Как мне это знакомо. Я такое еще у пхпшников и жсников вижу
Все аргументы сводятся к типичному
1 А мне норм
2 Не делай так/Оно не нужно. Читай доку
3 Ниасилил
А еще и 4й аргумент. Что я называю "миллионы мух"
4 Ну он же популярный
Логика просто рыдает.
"Изучи все грабли, научись их обходить, научись жить с тем чего нет, подстройся под инструмент" и так далее...
Я могу понять когда гитолюб говорит "да, есть такие грабли, но я нашел для себя воркфлоу, при котором я не сталкиваюсь с подобными проблемами или меня не парит эта деталь"
Но когда гитолюб называет того, кто указывает наэти недостатки гита ниосилятором...
Критика гита вполне обоснована (есть за что) и сколько не называй оппонента ниосилятором убогость архитектуры гита никуда не исчезает
И то что конкретно вы привыкли работать с ограниченным инструментов и для вас это стало нормой - не значит, что это вообще нормально.
Когда приходится пояснять даже очевидное, что продуманная система команд лучше чем абы какая просто с точки зрения здравого смысла - уже за гранью просто
А уж "можно же было сделать лучше и удобнее" и слышать в ответ "это нинужна"...
Линус сделал тул для себя для написания линуксов в его стиле - и это факт.
Поэтому в гит
- команды налеплены не подумавши.
- вместо веток именованные головы
- не поддерживает трекинг ренеймов
- не хранит никаких метаданных, и потому не может запомнить нам в помощь нихрена - в частности статус комита
- существуют отсоединенные комиты
- нет защиты от выстрела в ногу. "если что пошло не так дропни репу и склонь заново" не я придумал
- bare сервера
- staging area не опционален
- считает комиты мусором если на них нет указателя
- раз нет метаданных, что рулит только grep
- и я устал вспоминать...
Кому то его подход может понравиться, кому то не мешать, но это не значит что гит - нормальная DVCS для людей. Это DVCS для линуса
Гит никогда не был "а давайте подумаем и сделаем хорошую cvs чтобы побольше достоинств и поменьше недостатков, чтобы поменьше мешало программисту и побольше защищало его".
И популярность гита никак не связана с его качествами
Потому и кривая обучения крутая. Большинству людей приходится вникать в инструмент (читать доку и миллионы статей "как работать в этом удобном гит") и подстраиваться под его особенности (читай недостатки). Выучить можно? можно конечно. Ну и клингонский выучить можно. Но разве он для людей )
Для людей делался меркуриал. Там много того, что помогает не только обмениваться историей, а еще вовсю использовать как локальные сейвпоинты без оверхеда и риска того, что комит куда то денется.
И много другого. А наличие метаданых делает revset более полезным, чем аналогичное в гит
Конечно у меркуриала свои недостатки (как следствие плюшек ибо на 2х стульях не усидеть), но там инструмент там не делался "для себя и я дартаньян" и если что то не так, то не потому что "а мне это не нужно" (с) линус
>Я такое еще у пхпшников и жсников вижу
>жсников
А хули ты ещё можешь услышать?
Да, жс хтоническое говно.
Нет, ты нихуя с этим не сделаешь. Он во всех браузерах.
Можно написать 20 причин почему он отстой, но выбирать не приходится вообще, и эти причиины годятся только для троллинга.
>- не хранит никаких метаданных, и потому не может запомнить нам в помощь нихрена - в частности статус комита
>- раз нет метаданных, что рулит только grep
Не понял, что за метаданные?
>Для людей делался меркуриал.
ВедроБитов начинал с него и недавно полностью дропнул его поддержку ушлепки.
>Нет, ты нихуя с этим не сделаешь. Он во всех браузерах.
Однако это не мешает защитникам вместо вот таких аргументов яро использовать аргументы "норм язык, просто нужно изучить все грабли". Их невозможно убедить, что как бы сама необходимость изучать многочисленные грабли говорит о том, что не так что-то с объектом изучения.
>>1779669
>Не понял, что за метаданные?
Меркуриал сразу придумал что нужно хранить данные комита, название, ну и метаданные. То есть изначально создавал расширяемую систему, а не "программу одного человека"
Ну и стали в них позже хранить имена веток, публичный ли комит, evolve маркеры, топики.
И, как следствие, есть revset, в котором можно указывать в фильтре эти метаданные
В гит же ничего подобного нет. И потому расширяемости никакой. Если нужно сохранить доп инфу - вписывают в сообщение комита. И приходится расчехлять греп...это если вписали нужное )
И все эти хуки на автописание имени бранча (тем кто вписывает) это смех. Остальные же просто занимают позицию "это нинужна".
>ВедроБитов начинал с него
Ничего не поделать. Бизнес работает для миллионов мух (которые ничего и не выбирали, но как жопу рвут за свой "выбор").
Что не так с жс, долбоеб?
Ты можешь писать на нем все что угодно на данный момент.
Только в нем нет многопоточки, это не очень.
Типы - ты можешь подключить тайпскрипт. Возможностей типизировать у него столько, что ты на своей жабе просто хуйца сосешь, сидя и занимаясь пердолингом устаревшего говна, которое нихуя не развивается.
Ложись в гроб, оопшный паскале-жаба-сиплюс петух. Пора.
>Что не так с жс, долбоеб?
А вот как раз и пример "логики"
>ты можешь подключить тайпскрипт
жс такой нормальный язык, что гугл и мс (и не только они) решили создать свои языки транлируемые в жс. Странные ребята - писать свой язык транслируемый в жс....когда есть сам жс
Собственно так и родился тайпскрипт. А один из создателей дарт так вообще прямо сказал, что жс суть говно
Но жаваскриптер записал тайпскрипт в хорошие качества жс, лол
git log --name-only --pretty=format: | sort | uniq -c | sort -nr | grep <имя файла> | awk '$1=$1' | cut -f 1 -d ' '
Но может можно как-то по человечески это сделать?
Ты на винде что ли? Тогда проблема если что, не в гите, а во встратой консоли на винде. Но писатб код из под винды это вообще дело такое, никто кроме шарпистов таким извращением не станет заниматься, да и те от безысходности только. У них даже есть специальные блоатед редакторы кода, которые включают в себя и консоль, и все тулы для разработки и дебага, и компиляторы, и даже свой инстаграмм. Так что, или вливайся в коллектив превозмогаторов, или купи мак, или переходи на линукс.
>Ну это же пиздос
Конечно пиздос, ставь повершелл или cygwin с zsh и терминал с шрифтами получше
>Но писатб код из под винды это вообще дело такое, никто кроме шарпистов таким извращением не станет заниматься, да и те от безысходности только
Сколько раз уже слышу подобные вскукареки, но никто их так и не аргументировал. Настроить красивую консоль вместе с утилитами занимает от силы пять минут, а во всем остальном разницы нет - большинство языков и инструментов кросс-платформенные.
>git log --name-only --pretty=format: | sort | uniq -c | sort -nr | grep <имя файла> | awk '$1=$1' | cut -f 1 -d ' '
Гланды через жопу, и работает только с текущим бранчом ключ --all пропущен
git log --oneline --all -- README.md | wc -l
Файл надо указывать с отностильным путем.
> гиткракен
Нолог заплати, попенсорщик
>это где надо регистрироваться и получать анальный зонд
Это да, но поскольку ничего лучше все равно нет, то приходится терпеть.
>вебпараша зумерская
Дед, ты? В 2020 писать интерфейс для десктопа нужно исключительно на электроне, который обеспечивает отличное сглаживание шрифтов, масштабирование для 4К и плавный скролинг для 144Гц мониторов.
>>1712056 (OP)
Если гит твоя первая VCS, то будет тяжко. Я в гит въехал на продвинутом уровне окончательно только после того, как года два или три проработал в конторе со SVыNей и то ещё в гитовые исходники подглядывал по ходу дела - после использования двух альтернативы инструментов оформилось понимание того, какой из них чем лучше/хуже другого.
Вопрос: что такое "Git Flow"? Это типа смотрят, как именно разработчик коммитит, сколько веток на проект и всё такое? И что они хотят увидеть?
И второй вопрос: а как вообще нужно вести проект в гите? В смысле, сколько веток, как их разветвлять и сливать? Допустим, у меня пет-проект. Делаю в одну харю. Пишу что-то новое, делаю коммит. Пишу новое, делаю коммит. Одна ветка. Мне больше нахрен не надо. Но жопой чую, что Настоящие Программисты такой подход засмеют и подумают, что я и гитом-то пользоваться не умею. И после просмотра гитхаба скажут "мы вам перезвоним". Так как надо вести гит правильно?
Git flow это паттерн создания веток и их слияния, не путай с github flow и gitlab flow.
В реальных проектах обычно создаются feature ветки для каждого тикета, которые потом мерджатся/черрипикуются в мастер после ревью. А так же ветки под каждый релиз. Но детали зависит от конторы и продукта.
Значит, мне создавать как бы тикеты, каждый в отдельную ветку и мержить. Вот же геморрой. Ладно
И ещё вопрос, если я буду локально делать коммиты, а потом одним пушем залью на гитхаб, то гитхаб засчитает это за один коммит, или вся история комитов перенесётся и будет видна?
Ессно, например у тебя есть бранч в котором ты работаешь, и ты периодически ребейзишь его на мастер чтобы подтянуть свежие изменения.
Или например ты работаешь над фичей1, заканчиваешь, отправляешь пулл реквест, и начинаешь работать над фичей2 которая зависит от фичи1. Бранчишься от ветки фичи1, начинаешь работать, когда та ветка мержится в мастер, ребейзишь на мастер.
merge - это операция слияния веток, она может быть произведена разными способами, rebase - это один из способов, когда все коммиты из одной ветки накладываются на другую и в результате у тебя остаётся чистая линейная история. Недостаток один - эти коммиты меняются в истории и соответственно если ты кому-то давал на них ссылку, то эта ссылка теряется.
Гит говно, зачем вы с ним заморачиваетесь?
https://youtu.be/5mKm1vplLwU
>Но система контроля версий
Только один маленький ньюанс. GIT - это не система контроля версий. SVN - да. HG - да. А вот git - нет. Он конечно умело маскируется, но по своей сути это именно SCM, а не VCS.
И когда тебе понадобится именно полноценный функционал контроля версий, а не огрызок менеджмента сорцев, ты поймешь насколько у git-а хуевая концепция.
сам я продолжаю сидеть на HG
и даже если приходится иметь дело с гитом, то опять же делаю это через HG
ибо те гуи, что даются к гиту (они все говно, если видел TortoiseHg) - просто адище (даже если не видел TortoiseHg).
сама концепция версионирования в гит с учетом reflog конечно хуже чем evolve, но все же жить можно.
но саму концепцию херит херовая реализация. Концепция не запрещает добавлять к комиту имя ветки, фазу, что было во что переименовано ( да да я знаю что гит трекает снапшоты. И ЧТО????). И не сделано это лишь потому что автору было срать на всех (и он это не скрывает)- автору норм, автор так видит)
и в итоге вся метаинфа пишется в сообщение и привет grep, а трекинг рейнема файлов играет в угадайку. Про фазы - их вообще нет. И расширяемости никакой нет и не будет.
Салют бродяги. 2 года одуванчиком сидел и пушил свои высеры в местный гитлаб в свой "бранч". Типа только я отвечал за "участочек" свой и срал в соответствующий "бранч" только я сам. Для этого в гуевину в которой работал установил vcs плагин и тупо ебаш пуши и комиты, никогда не синкался никогда не пулил.
Поменял проект и пришло впемя всё это выучить, т.к. сидит выводок джунов и их потуги в пайтоне\Р нужно оформить в красивый проект на гитлабе. Посоветуйте пойти нахуй,сделать бочку видосов, где смогу понять как не обосраться с ребейсом и прочее.
Ананасы, а есть какой-нибудь способ в этом вашем ебучем гит'e вытянуть весь реп сразу со всем, что в нем есть? а не тянуть его как долбоеб по каждой веточке.
> приходится pull делать, чтобы ее подтянуть
Ну так pull делает еще один fetch который и качает дополнительную хуйню (если она есть). Тебе нужно сделать git fetch (которая скачает все). У тебя появятся remote ветки с именами типа <remote>/<branch>. Если они тебе нужны локально то делаешь мердж (например git merge origin/master). Ну или можно хард ресет сделать если ты по хардкору угораешь.
> Возможно ли накатить на нее какой-нибудь плагин чтобы покрасивее сделать? Если да, то как?
Cmder
mingw это просто порт компиляторов под шинду.
git bash это скорее просто "ядро" (приложение) с соответствующим функционалом, обернутое в графическую оболочку (консоль/терминал) с дизайном из msys-пакета.
который в свою очередь использует api шинды, включая соответственно и дизайн самой консольки.
так что да, это все косвенно связано друг с другом, кроме разве что самого mingw
мимо
Сноси гит баш, накатывай настоящий линупс на WSL2 и запускай в Windows Terminal.
Альсо, можешь накатить мухой гит из Chocolatey и юзать его из павершнлла 7 из шиндоус терминала.
Юзаю Tortoise git. Зависимость лютейшая. Есть вроде вполне функциональный GUI в IDE (Idea), но все равно продолжаю пинать черепашку. Есть тут еще такие, как я?
>Есть тут еще такие, как я?
Есть. Но я git-овую черепаху исплоьзую, но только для оверлеев, ну и для более удобного копания в некоторых настройках. Во всем остальном она проигрывает даже SVN-кой черепахе.
Пизже всего меркуриаловский HG-Tortoise. По удобствую с его HG-Workbench, не сравниться ничто. Особенно учитывая, что через нее можно и с git репами работать.
А так вообще через консоль все делаю. Даже граф дерева смотрю.
Линукс.