Здравствуйте, willie, Вы писали:
M>>>На днях натыкался — есть такая проблема. W>·>Да нет такой проблемы, открой для себя "git log -M" W>И что ? Покажет что смержились две ветки. Как посмотреть какие именно коммиты вошли в мою ветку из чужой?
git log myBranch^..alienBranch
Только причём тут переименование файлов?
.>>или ещё круче — "git blame -C" W>с консольки файлы листать?
Если консоль чем-то не нравится, в IDEA есть history for selection — выделяешь блок строк и смотришь историю для него.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
w> Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды
А вообще в нормальном процессе между нерадивым(а зачем такие вообще в команде нужны?) джуниором/мидлом/сениором будет что-то что не даст фигне просочиться в репо вообще.
Здравствуйте, willie, Вы писали:
W>У тебя просто юскейсы специфичные. Мне вот interactive-add ни разу не нужен был Даже без понятия был что это такое пока твое сообщение не прочитал.
Это же чуть ли на самая часто используемуя фича. Вы видимо не работали над большими фичами, либо нет нормального код ревью.
Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура.
Сорри, что не в тему, если ты под Windows, то не помешает обновиться — домен в подписи уж несколько лет как не существует, а с тех пор в openssl багов много.
P.S. С другой стороны, работает — не трогай.
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, ·, Вы писали:
W>>·>Да нет такой проблемы, открой для себя "git log -M" W>>И что ? Покажет что смержились две ветки. Как посмотреть какие именно коммиты вошли в мою ветку из чужой? ·>git log myBranch^..alienBranch
Не сработает. Ведь бранчи-то удаляются. Это тебе не меркуриал с его мегафичей вечных веток.
Здравствуйте, Dziman, Вы писали:
D>А вообще в нормальном процессе между нерадивым(а зачем такие вообще в команде нужны?) джуниором/мидлом/сениором будет что-то что не даст фигне просочиться в репо вообще.
Речь про гит, а не процессы )
Другие тулзы вполне позволяют отловить все коммиты.
Вместо юниора можно придумать кучу других примеров где удобно смотреть именно ветки N летней давности.
V>Это же чуть ли на самая часто используемуя фича.
Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>Вы видимо не работали над большими фичами, либо нет нормального код ревью.
Как раз таки нормальное код ревью и подразумевает нормальные вдумчивые исправления кода. С подсветкой синтаксиса и рефакторингом на лету.
V>Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура.
Нет, на ура справляется только IDE которая сможет подсказать не привели ли твои интерактивные изменения к ошибкам. Опечатался в названии или забыл обновить где-то имя переменной.
Может я конечно не совсем понял что имелось в виду под самой используемой фичей и как именно ее использует автор. Но посмотрев бегло скринкасты на трубе могу сказать что это ужас пользоваться в середине 2010-х такими инструментами как консольный git interactive[add,rebase,whatever] это мазохизм
Здравствуйте, Dziman, Вы писали:
D>А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX?
Ровно это и дает. Ты знаешь какой коммит зачем в рамках чего создавался.
Но мне интересно именно отслеживать как кто-то пилил что-то. А не копошиться в ворохе логов и коммитов гита влитых 10-ю людьми в development ветку два года назад в попытках разобраться как они что делали и в каком порятке на каких временных интервалах это происходило.
Здравствуйте, Dziman, Вы писали:
w>> как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита D>Хм, а зачем тогда такие аттрибуты коммита как Author и Committer(не знаю есть ли такое в mercurial)?
Не знаю. Я про них вообще не спрашивал. Это линуксоидам наверное надо, которым патчи по имейлам до сих пор шлют. Мне это не надо У нас нормальный процесс разработки, без извращений.
W>>Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды ·>Найти точку нерадивого мержа, заревертить её. Не вижу проблемы.
Я вижу как минимум проблему найти удобно коммиты которые ревертить.
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Это же чуть ли на самая часто используемуя фича. W>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
Что значит на лету? Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде?
V>>Вы видимо не работали над большими фичами, либо нет нормального код ревью. W>Как раз таки нормальное код ревью и подразумевает нормальные вдумчивые исправления кода. С подсветкой синтаксиса и рефакторингом на лету.
Нормальное код ревью подразумевает нормальную историю и комиты в которых нет лишнего. А для этого надо уметь нарезать и потом перенарезать комиты.
И снова причем тут ваш рефакторинг? Гит позволяет вам всего лишь управлять историей и состоянием кода. Ни кто не запрещает фиксить конфликты или делать изменения в иде.
V>>Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура. W>Нет, на ура справляется только IDE которая сможет подсказать не привели ли твои интерактивные изменения к ошибкам. Опечатался в названии или забыл обновить где-то имя переменной.
Пример, у тебя большая фича и что бы ее сделать надо выполнить несколько рефакторингов, будешь все в один комит пихать?
А если комиты уже есть и надо их подправить, например, опечатку сделал? Или измельчить пиар что бы твоим товарищам проще ревьювить?
W>Может я конечно не совсем понял что имелось в виду под самой используемой фичей и как именно ее использует автор. Но посмотрев бегло скринкасты на трубе могу сказать что это ужас пользоваться в середине 2010-х такими инструментами как консольный git interactive[add,rebase,whatever] это мазохизм
Я считаю что и не надо делать этого из консоли, используй что удобнее.
Здравствуйте, ·, Вы писали:
·>Можно, для небольшого проекта с центральным репозиторием, как CVCS hg ещё ок, в качестве альтернативы svn. Хотя в случае централизованной разработки лучше взять gerrit.
Не понимаю этого упора на централизованность-децентрализованность.
В большинстве продуктовых компаний по факту вся разработка централизована. Нету там никаких "распределенных систем равноправных репозиториев". Нету равноправия между офисами Есть центральный, куда все остальные сливаются по спринтам и откуда они забирают код других команд. Даже аутсорсеры зачастую либо получают репу и отдают ее на сливание заказчику, либо тупо по vpn сидят подключившись к серверу заказчика. Все эти мульки гита с распределенностью просто не нужны.
Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах.
Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз
Здравствуйте, willie, Вы писали:
W>Здравствуйте, Dziman, Вы писали:
D>>А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX? W>Ровно это и дает. Ты знаешь какой коммит зачем в рамках чего создавался.
Использовать номер тикета в комите?
W>Но мне интересно именно отслеживать как кто-то пилил что-то.
Код ревью с пул реквестами не достаточно?
W>А не копошиться в ворохе логов и коммитов гита влитых 10-ю людьми в development ветку два года назад в попытках разобраться как они что делали и в каком порятке на каких временных интервалах это происходило.
W>>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>Что значит на лету?
Если что я имел в виду это сообщение http://rsdn.ru/forum/flame.comp/6339216.1
Где описаны edit-add, interactive-add и прочее.
V>Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде?
Про ребейз я не говорил, причем тут иде и interactive-add не понял.
Здравствуйте, willie, Вы писали:
W>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз
Интересно как прошедшие код ревью, тесты и автоматически смерженный пулл реквест доставляет вам проблемы?
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
W>>>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>>Что значит на лету? W>Если что я имел в виду это сообщение http://rsdn.ru/forum/flame.comp/6339216.1
Именно этот воркфлоу я имел ввиду.
V>>Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде? W>Про ребейз я не говорил, причем тут иде и interactive-add не понял.
Например:
1. нарезал комит, добавляя файлы, строчки, куски, что угодно
2. спрятал все остальное
3. прогнал тесты, убедился что все работает
4. вытащил свой wip и продолжил дальше пилить
Надо поменять что то в старом комите, сделал ребэйз или просто фиксап комит, что бы не тратить время сейчас,
оно потом само автоматически вольется куда надо при ребэйзе.
V>Нормальное код ревью подразумевает нормальную историю и комиты в которых нет лишнего. А для этого надо уметь нарезать и потом перенарезать комиты.
Нарезать и перенарезать это лишнее. Уши этого "мастерства" торчат из неудобств гита, где при наличии коммитов с месседжами "quickly fix " или "save state" ты хрен разберешься что имелось в виду. Если у тебя есть бранч как в меркуриале то тебе в общем-то пофиг что там внутри, ты оперируешь макро изменениями, а не микро. Разработчикам удобно работать, можно хоть 100 раз коммитить полуготовые файлы перемежая с полноценными коммитами. И изменения не теряются, и всякой фигней вроде git stash пользоваться не надо, и историю "вдумчиво переписывать" не надо сидеть. Ты просто работаешь как тебе удобно, а vcs тебе в этом помогает.
V>Пример, у тебя большая фича и что бы ее сделать надо выполнить несколько рефакторингов, будешь все в один комит пихать?
Нет, сделаю несколько коммитов с рефакторингами, потом фичу. В чем проблема-то.
V>А если комиты уже есть и надо их подправить, например, опечатку сделал?
Опять таки в чем проблема? Вот в гите да, проблема. Пушнул в ремот хрена с два поправишь без --force. Со всеми вытекающими.
V>Я считаю что и не надо делать этого из консоли, используй что удобнее.
В случае с гитом под винду я пока не видел удобных инструментов. Почти все поддерживают только какие-то базовые вещи, а за извратами надо в консоль лезть. А извратов в гите многО
Даже без понятия был что это такое пока твое сообщение не прочитал.
