k0st1x

вот есть жирный файл с кодом. над ним трудились несколько человек, он разросся, его пора пились на классы.
делю на 2 файла, вычленяю рядом, коммичу, а у нового файла истории не будет, потому что он считается новым. а надо, чтобы там была история, чтобы blame показывал, кто и для чего менял. вот как быть в этой ситуации? как зашарить историю для нового файла?
может у гита есть issues трекер, чтобы туда закинуть feature request?

ub
Git

как использовать ветки в гите? я их использую просто как именование эпохи. пишу фичу А в ветке "фича А". потом когда дописал сливаю ее в мастер.

потом создаю веточку "фича Б" и когда допишу сливаю в мастер.

заем хочу пофиксить ветку А и создаю веточку "фиксим фичу А" и потом сливаю ее в мастер.

я все правильно делаю? или можно как-то реанимировать веточку "фича А" и дописывать туда код снова и снова

janPona

Из-за того, что я рефакторю больше всех (если считать по клоичсетву строк), то моё имя фигурирует во всех блеймах, куда бы кто ни ткнулся. И поэтому все думают, что именно я написал {shit_code_name}. И долгие годы ещё будут думать. И возможно, через много-много лет, когда я уже уволюсь, кто-то даже попытается найти меня и пристрелить. Будет ржачно, если я уже к тому времени сдохну. Интересно, выкопают и осквернят или просто анафеме предадут?

vt

В отсутствии божественного Fork, который только под макось, решительно некуда нажать кнопку, что она сделала git pull без лишних вопросов, что они от меня хотят — я вообще не понимаю, и приходится открывать консольку, чтоб оно мне ничего не похерило

gbdj

Познаю доселе незнакомые команды git: merge-file, diff-tree, merge-tree. Проблема в том что они понадобились, хотя я о них даже не знал. Нужно больше рефакторинга и чудовищных мерджей!

ermine
Git

У меня вот тут проект на rust+webasembly, оно имеет свой .git подкаталог, а еще оно имеет подкаталог-подпроект на яваскрипте, который также имеет свой .git и .gitignore. Как манипулировать этой кухней? В два захода или в один?

janPona

Попробовал gitkraken. Полная хуета, написанная на электроне и jQuery. Коммиты не подписывает моим GPG-ключом, при попытке запушить намертво зависает.

Консоль, консоль и ещё раз консоль. Ничего лучше просто не придумали.

vt

Meet a new Git client, from the makers of Sublime Text
По скриншотам сразу видно что это они: захламленным экраном изображают будто у них есть что показать, а по факту — простой блокнотик.

PoZitron

Пытаюсь автоматизировать "скрытие" устаревших веток в git.
Когда я весь в работе, то создаю много временных веток которые потом на всякий случай не удаляю, а переименовываю в old/имя_ветки. То, что она "old" не означает что через месяц или год мне не захочется посмотреть какую-нибудь светлую идею которая не попала в основную ветку. Поэтому ветки копятся и непонятно куда их девать.
О "скрытии" веток подсмотрел идею здесь: stackoverflow.com
Написал такой скрипт:
git branch | grep old/ | sed 's/^*//' | awk -v date=$(date +%y-%m-%d) '{print "create refs/archive/" date "/" $1, $1}' | git update-ref —stdin
который ищет ветки содержащие "old/" и создаёт ссылки на них в refs/archive/<дата>/имя_ветки.
Затем оригинальные ветки "old/" удаляю так:
git branch | grep old/ | sed 's/^*//' | xargs -n 1 git branch -D

"Дата" в первой команде — тупой способ обойти проблему с одинаковыми названиями веток.

После этого "архивные" ветки по-идее нигде не отображаются, но на них по-прежнему можно перейти с помощью
git checkout refs/archive/<дата>/имя_ветки

max630

Все вокруг говорят про gitflow, о том чем он лучше или хуже альтернатив, я собрался с духом и прочитал таки исходную статью ( nvie.com ). И что имею сказать.

Во-первых, автор перепутал ветки. Мастер у него там где у людей maintenance. А там где у людей мастер у него develop. Эта разница, хотя и только в наименованиях, напрочь застит всем глаза и они считают это как что-то существенное. Также, мне кажется, это порождает следующуй пункт.

Во-вторых, во многих местах можно спросить только "зачем". Зачем мержить новых релиз в мастер? Ведь в мастере нет ничего интересного, всё что там есть уже должно быть смержено в релиз, если бы он назывался "версия N-1" это было бы очевидно, а тут вот нет. Релиз просто надо собрать и выложить, с чего он будет уже не релиз а следующий maintenance. Зачем хотфикс отдельно мержится в master и develop? Почему бы просто не мержить master в develop как только там появляется что-то новое (в том числе хотфикс, независимо от того сделан он веточкой или прямо там). Оно всё равно там в итоге окажется, со следующим хотфиксом. Только будет непонятно почему этот merge commit приехал именно сейчас.

В общем, если это всё подчистить, получается то что именуют github flow + maintenace бранчи (o которых github flow скромно умалчивает). Никакой коренной разницы между ними нет.

Я понимаю почему он выглятит так: потому что это писалось в 2010 году когда гит использовался только красноглазыми ублюдками (ТМ) в виде git-svn, а компании только-только начинали обращать внимание что это за хуйня такая. Но сейчас-то уже можно закопать стюардессу.

killy

После #2884467 меня окончательно достал SourceTree, и я поставил GitKraken.
После недели использования:

Что понравилось:
* Сделано для людей.
* Не пугает диалогами с выхлопом консоли.
* Drag'n'drop — в т.ч. легко управлять ветками не переключаясь между ними.
* Squash называется squash.
* Показывает stash'и в дереве.
* Автоматически делает и применяет stash когда нужно.
* Встроенный юзабельный 3-way merge для разрешения конфликтов.
* Можно добавлять в staged изменения построчно. Чуть менее удобно, чем в GitHub Desktop, но всё же.
* Не пушит теги без спросу.
* Интеграция с GitHub и BitBucket.
* Активные блог разработчика и канал на ютубе.

К чему можно придраться:
* TreeView модифицированных файлов свёрнут по умолчанию, что нивелирует его удобство и приходится использовать обычный FullPath.
* Дерево более гнутое, чем могло бы быть — часто изгибает более значительную ветку, отдавая приоритет менее значительной или stash'у. (Похоже, это проявляется на старых ветках, а то, что сделано уже в самом GitKraken — отображается нормально. Странно.)
* Auto-Fetch это хорошо, но было бы неплохо ещё отображать как-то, что он выполняется успешно или же нужно взаимодействие с пользователем (ввести пароль от ssh ключа).
* Сворачивание меток бранчей в дереве коммитов. Если моя ветка и мастер совпадают, то я не могу найти мастер визуально. (Я знаю где он находится или могу выбрать его в левой колонке, просто мелкий раздражающий фактор.)
* Любимый всеми Electron — 300+ МБ оперативной памяти.

Отправил несколько фидбэков — есть удобная форма для этого в программе. Но без платной подписки они могут и в dev/null отправляться, кто знает. Можно было бы, конечно, попробовать Pro Trial активировать и повторить... Ну или в slack заглянуть.

Общее впечатление:
В целом сейчас это лучший из GUI клиентов git под Windows. Заменит мне и GitHub Desktop и SourceTree. Можно рекомендовать всем, в т.ч. хорошим людям™, если Electron и "Free for non-commercial use" не напрягают.

gbdj

А чем сейчас модно и молодежно работать с git под вендой, ну помимо плагинов к eclipse и idea? Сто лет назад народ помниться любил черепашку. Или лучше сразу ставить IDE? Сам просто ничего не понимаю про работу с git через GUI.