Git: как вставить файл задним числом?

Наверка же это помои вида {«фикс», «фикс», «ой б, забыл положить файл», «ой б, сборку сломал», «ещё один фикс вот к тому первому», ...}

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

они не понимают цели и смысла и такие косяки творят

если не понимают - зачем разработкой занимаются вообще?

Тебе шашечки или ехать?

Но вы же занимаетесь бездумными мерджами и одновременно разрабатываете.

у нас в конторе очень сильно выносят мозг за подобную грязь

Дык, и правильно. Воркфлоу, руководство по стилю, словарь предметной области — основополагающие документы.

Мой же личный опыт партизанского программирования показывает что коммитить и пушить нужно как можно чаще. Даже не факт что в отдельный бранч... Т.к. велика вероятность, что в следующий раз я вернусь к вопросу через месяц или даже через полгода. И лучше у меня в отдельном месте будет помойка, чем я матерясь буду разыскивать куда же я удевал локальную копию.

Про commit --amend скромно молчу.

В это-то и прелесть гита: не привязан он к конкретному воркфлоу.

Просто иногда «разряжаюсь» множеством коммитов вида «Test commit #1», «Test commit #2» с изменениями в паре-другой строчек. После каждого коммита смотрю как начинает работать та или инная функция приложения и те изменения, которые удовлетворяют моим потребностям, сжимаю в один тематический коммит с нормальным сообщением. Который уже можно переносить в master/develop и др. основные ветки.

Всё эти тестовые коммиты делаются в отдельной персональной ветке, конечно, дабы не захламлять мусором ветки; rebase в основном master'е никто не делает.

Я поверил, решив для себя, что там, где нужна более надёжная история я по-прежнему буду использовать Mercurial.

эта твоя история — это просто файл (или набор файлов) на диске. ее «надежность» и неизменность зависит только от того, какими тулзами ты ее будешь ковырять.

rebase в основном master'е никто не делает.

делает. если например нужно выпилить кусок репозитория в отдельный submodule (ну, не rebase, а filter-branch, но не суть). есть и другие поводы. и даже в hg это делают, хотя многие местные фанатики не верят :)

Не, я про то, что q11q11 видимо считает, что я все эти коммиты в master пушу, а потом к ним там rebase -i применяю. А я только в своих тематических ветках орудую.

Так-то rebase в master'е конечно делают. К примеру, помню случай, когда мы только переходили на Git и кто-то случайно закоммитил огромный файл под сотню метров, а потом удалил его последующим коммитом. И эта бесполезная шняга болаталась в во внутренней базе и клонировалась при каждом git clone.

Тогда было решено выпилить этот файлик и коммиты, связанные с ним полностью и безвозвратно. Естественно, без переписывания истории и изменения хешей не обошлось. Но тогда всех разработчиков оповестили, чтобы они обновились и всё прошло гладко.

почему ты решил что бездумными?
новички холодным пОтом обливаются когда мержат в develop, я уже не говорю про мастер
а опытные по 5 раз перепроверят своё код перед пушем

И эта бесполезная шняга болаталась в во внутренней базе и клонировалась при каждом git clone.

у меня такое случилось в 1ю неделю использования hg на текущей работе (я тогда еще не знал, что это нельзя исправить). но удалось уговорить админа почистить коммиты на сервере.

почему ты решил что бездумными?

Потому что я знаю как выглядят проекты в которых PR не заставляют сквошить.

новички холодным пОтом обливаются когда мержат в develop

То есть PR у вас нет, а значит вероятнее всего и code review? Соответственно история у вас похожа на лобок азиатки.

что коммитить и пушить нужно как можно чаще

ну да, задачу нужно разбивать на достаточно малые осмысленные части
запилил запрос, описал в сообщении коммита - залил, запилил рендер данных в шаблоне, описал в сообщении коммита - залил
лично для меня очень хорошим примером красивой правильной репы является репа gnu screen

А у меня другой обосрамс однажды случился: я по невнимательности кучу скрытых .desktop файлов Dolphin'а забросил в реп.

Благо они хоть мелкие, по паре байтиков. Вычистил следующим коммитом и добавил правило в .gitignore;

А в Dolphin отключил эту «фишку». Не понимаю, нафига она по умолчанию врублена. Или почему не хранить настройки каталога в отдельной базе, как это делает Nautilus. В любом случае, срать в каталоги скрытыми файлами — моветон.

если этот коммит - последний, то нет ничего проще, чем git commit --amend

Только стоит иметь в виду (что обычно опускают все, кто рассказывает про amend), что это действие можно делать только если последний коммит еще не был никуда запушен.

Соответственно история у вас похожа на ...

ты этими аналогиями пытаешься показать что ты самый Д`Артаньян, а все вокруг все ... ?
CR есть, но у нас MRы, и новички тоже учатся их делать

Только стоит иметь в виду (что обычно опускают все, кто рассказывает про amend), что это действие можно делать только если последний коммит еще не был никуда запушен.

на локальной репе вроде пофиг, нет?

Ну на локальной репе ты и git rebase -i --root можешь делать сколько твоей душе угодно и git push -f.

что ты самый Д`Артаньян, а все вокруг все ... ?

Пойнт был в том что форсирование практик на новичках смысла не имеет, а ты встрял про разработку и как то близко принимаешь к сердцу обыденные вещи.

P.S. Да мне нравится линейная история, где один коммит ­— одна фича или фикс, по ней очень легко искать откуда торчат уши и есть корреляция между аккуратной историей и аккуратным кодом. И как правило, с опытом многие склоняются к этой же позиции.

вообще нихрена не понял

таки прав ТС, логика git-а какая-то инопланетная

Ты имеешь ввиду сколинированную с публичного репа локальную копию? Или просто свой локальный репозиторий, в котором возишься лишь ты один?

Если первое, то ты можешь делать на последнем коммите ammend до тех пор, пока этот коммит обратно не запишешь в публичный реп.

Если второе — можешь делать вообще что хочешь, пока не опубликуешь коммиты/не поделишься репозиторием с другим человеком.

не суди по своему опыту

На этот счёт можно не беспокоиться, сужу исключительно по опыту «братьев меньших».

у нас в конторе очень сильно выносят мозг за подобную грязь

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

на локальной репе вроде пофиг, нет?

Да

логика git-а какая-то инопланетная

Нет там никакой логики. Это простой граф, бранчи это тупо метки на листья, которые автоматом передвигаются, теги — метки на произвольные ноды. git checkout переводит указатель на нужную ноду. git reset делает текущий указатель листом в этой ветке, то есть отсекает все последующие. git rebase перестраивает ветку от указанного base. Почему это так сложно? Почему куча нытиков не могут понять эту простую вещь? Git это элементарный граф с парой команд для навигации.

Спс за объяснение, но...
можно, пожалуйста, ссылочку на то, что такое граф, а то какая-то нечитабельная хрень в поисковике находится

форсирование практик на новичках смысла не имеет

тогда они никогда не научатся и будут лепить чушь создавая проблемы для всей команды
и у меня есть такой пример, но девелопера держат потому что она фронтэнд / дизайн / принцесса на горошине ...
за 4 года человек еле-еле научился делать «одна задача - один брэнч»

по ней очень легко искать откуда торчат уши и есть корреляция между аккуратной историей и аккуратным кодом

по-мне так если грамотно аккуратно вести историю (т.е. следовать workflow) то и несколько коммитов на фичу не будут проблемой

можно, пожалуйста, ссылочку на то, что такое граф, а то какая-то нечитабельная хрень в поисковике находится

https://ru.wikipedia.org/wiki/Теория_графов

Если вы не пользуетесь ребейзом каждый день, то возможно только одно из двух ...

ну тоесть у тебя в конторе rebase делают постоянно?
это как раз говорит о грязи в репе и что у вас всё делают в спешке наот**бись
однако рано или поздно приходится всё это подчищать, вы предпочитаете подчищать пораньше

ничего не делаете, или делаете с крайне низкой производительностью

диванный ты наш аналитичег, что ещё расскажешь о том чего не знаешь?

я видел эту статью. Это какая-то суровая жесть.

есть что-то для тугих?

я видел эту статью. Это какая-то суровая жесть.

Разработчик который не решал задачи на обход графа? Не нужен тебе git, инфа соточка.

тогда они никогда не научатся

Когда освоятся — научатся, у них и так стресса полно без vcs.

Разработчик который не решал задачи на

да-да, вот из-за таких как ты у нас нет нормальных узконаправленных спецов, зато СПВ - хоть жопой жри! только куда их?

есть что-то для тугих?

Тут аналогию с деревом, которое растёт за окном твоей квартиры можно привести, лол.

Листы на этом дереве — это коммиты. Если ты возьмёшь свой указательный палец и укажешь на один из листиков, то получишь ветку — последовательность листов начиная с того, на который ты указываешь и до самого корня (первого листика на стволе дерева от земли). Вторым указательным пальцем (при условии, что у тебя две руки), ты можешь указать ещё на один листик, можно даже на тот, на который ты уже указываешь. Этим ты создашь ещё одну ветку.

Ну а дальше с помощью различных команд можешь манипулировать этими листиками и указателями.

К примеру, git commit создаёт новый листик на выбранной тобой ветке и передвигает один из твоих указательных пальцев на него. git checkout позволяет выбрать произвольный листик, git reset позволяет перенести твой палец на необходимый листик и, например, отсечь новые листики на ветке. git rebase берёт листики с одной ветки и последовательно переносит их на другую. И так далее.

git commit --amend вместо создания нового листика изменяет старый. Если дерево одно, ты можешь изменять листики сколько душе твоей угодно. Но если имеется публичная копия дерева, с которой работает помимо тебя ещё кто-то, то ты не должен изменять те листики, которые ты уже отправил в это дерево и переписывать историю. Поскольку их уже забрали другие и начали с ними работать. Если ты так сделаешь, они обидятся, ведь им придётся снова получать листики, в которых работа будет продублированна и соединять их со своими.

:))))))))

назови плз первую букву названия своей конторы, вдруг мир тесен

у нас с этим сложно, типа несколько контор и кто-то кого-то арендует, но если тебя зовут Игорь - мы в разных странах :)

нет нормальных узконаправленных спецов

Алгоритмы на графах — фундамент без которого просто никуда. В любой специализации они есть, даже самой узкой. Это даже близко не http://sharpc.livejournal.com/67583.html

интересно, как ты порхеришь что-нибудь на этот раз

Всё, что я боюсь похерить, я держу в Mercurial :)

Почему это так сложно? Почему куча нытиков не могут понять эту простую вещь? Git это элементарный граф с парой команд для навигации.

В нормальный граф можно вставить произвольные узлы без переписывания всего графа :) Поэтому и возникают непонятки...

У тебя какие-то паталогические проблемы с логикой...

ну тоесть у тебя в конторе rebase делают постоянно?

Какими же принципами нужно было руководствоваться чтобы перейти от вопроса правильного использования VCS к практикумемым схемам в «моей конторе»? rebase постоянно делает любой опытный пользователь git, в любой конторе. Ибо...

это как раз говорит о грязи в репе и что у вас всё делают в спешке наот**бись

Это говорит о том, что разработчик заранее приводит свою работу в порядок и грязи в проекте взяться неоткуда. Без rebase приготовить чистый результат можно только в самом тупом случае - когда вся работа умещается в один комит, крайне редкий случай в разработке.

однако рано или поздно приходится всё это подчищать, вы предпочитаете подчищать пораньше

История в (D)VCS либо уже попадает в условный публичный доступ чистой, либо остаётся как есть на всё время. Поздние чистки никогда не бывают регулярными.

Я, конечно, понимаю что у тебя начался сочный бх и под состоянием аффекта несёшь лютую галиматью. В таких случаях лучше молчать и не позориться.

В нормальный граф можно вставить произвольные узлы без переписывания всего графа

Точно, есть одно маленькое уточнение, это немутабельный граф. Видимо это многое меняет.

Какими же принципами нужно было руководствоваться чтобы перейти от вопроса правильного использования VCS к практикумемым схемам в «моей конторе»?
rebase постоянно делает любой опытный пользователь git, в любой конторе.

так если в любой конторе и любой опытный, и ты делаешь rebase постоянно - значит на примере твоей правильной опытной конторы можешь рассказать для чего ты часто делаешь rebase, по шагам жизненный цикл ветки, от мастер-ветки
а то по твоим словам получается что «кто не делает rebase, тот тупой и неопытный»
или тебя замкнуло на одном единствнном workflow и всё остальное для тебя ересь?

не суди по своему опыту <...> у нас в конторе ... сильно выносят мозг <...> новички холодным пОтом обливаются <...> или страдает <...> в любой конторе <...> ну тоесть у тебя в конторе <...> наот**бись <...> значит на примере твоей ... конторы <...> кто не делает ... тот тупой

Это же какой-то пц, честное слово. Даже трудно представить какая у вас там содомия творится что из тебя льётся столько ненависти и выпирает глубокая психологическая привязанность к конторе. Я уже на протяжении двух постов пытаюсь оторвать обсуждение от конторы, но всё тщетно - вырисовывается настоящий Мандерлей...

<...> несмотря на то, что рабство отменили уже более 60 лет назад, чёрные до сих пор живут здесь в жесточайших условиях и по-прежнему подвергаются гнёту со стороны белых «хозяев». Грейс решает изменить порядки, сложившиеся в Конторе <...> Но готовы ли сами сотрудники Конторы принять эту свободу?

А ты готов? Ну да ладно, пора заканчивать с лирическим отступлением...

на примере <...> можешь рассказать для чего ты часто делаешь rebase, по шагам жизненный цикл ветки, от мастер-ветки

Даже в этом треде обильно затронули механизм этого процесса, всё просто и ничего нового:

1. делаем новую ветку от мастера

$ git checkout -b feature_branch

2. Далее следует некоторое время работы над новой фичей результатом чего становится вот такая история и некое кол-во кода. Причём код до настоящего времени набирался текстуально и быть может даже не является всюду валидным.

$ git log <много параметров в виде алиаса ...>
6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
05cd4d5 написали базовую версию нового функционала в виде либы
8370569 расширили интерфейсы чтобы можно было впилить новую либу
f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
...

Да не быть может, а точно не является - невозможно набрать несколько сотен или тыс. SLOC одним спринтом без ошибок. Потому история с этого монетнта начинает расти мусорными коммитами-фиксами, например

у29375a fix: доработки либы
414a8b1 fix: накосячи при рефакторинге
cec718d fix: как-то криво прикрутили либу

3. Теперь настало самое время для первого ребейза дабы избавиться от мусора...

$ git rebase -i master

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
pick 05cd4d5 написали базовую версию нового функционала в виде либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
pick у29375a fix: доработки либы
pick 414a8b1 fix: накосячи при рефакторинге
pick cec718d fix: как-то криво прикрутили либу
...

Историю нужно изменить каким-то таким образом после чего она снова станет похожей на первоначальную.

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
f 414a8b1 fix: накосячи при рефакторинге
pick 05cd4d5 написали базовую версию нового функционала в виде либы
f у29375a fix: доработки либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
f cec718d fix: как-то криво прикрутили либу

Реальный цикл разработки состоит из значительно бОльшего числа шагов. В частности, после изменений могли поломаться тесты или наоборот, понадобится написать новые и потом гонять их на истории дабы найти из-за чего всё пошло не так. Или даже может понадобиться ещё что-то порефакторить и расширить функционал других частей проекта. Итоговый код может занимать десятки логических коммитов и работа может занимать от дней до недель или даже месяцы.

F. Потому в конце всего желательно актуализировать свои наработки на текущий хед мастера и ещё раз проверять что всё ок. В этом нам поможет опять таки ребейз...

$ git checkout master
$ git pull
$ git checkout feature_branch
$ git rebase master

Проверяем что всё нормально, тут может понадобиться позаниматься мерж конфликтами. И в конце концов...

$ git checkout master
$ git pull
$ git merge feature_branch
$ git push

За кадром остался вопрос где всё это время находится feature_branch, как её именовать и всё такое. Т.к. работа может длится долго, то ветка должна где-то надёжно храниться, это может быть либо тот же самый реп, но в условно приватном бранче пользователя, либо некий отдельный мясной реп для разработки. Пока в ветке идут ребейзы ветка должна оставаться «приватной».

Альтернативы ребейзу здесь никакой нет. Казалось бы, можно в конце концов всё превратить в один коммит. Но один большой мегакоммит ничем не лучше кучи мусорных - пользы от него ровно столько же и чуть меньше проблем.

а то по твоим словам получается что «кто не делает rebase, тот тупой и неопытный»

Это уже какие-то твои фантазии из Мандерлея, мои слова относятся только к опыту и к эффективному использованию DVCS в жизни проекта.

А ты готов?

при чём тут эта философия? есть требования к работе и качеству, тебе работу работать или пальцы гнуть?

ладно, пора заканчивать с лирическим отступлением...

согласен, а то тебя уже далеко занесло, ну или замкнуло на одном workflow, и почему-то считаешь что единственно верный - тот котороый используешь ты, но есть же разные пути, и не надо бросаться яркими образами типа «в мировой общепринятой практике» и «во ВСЕХ нормальных конторах», «к опыту и к эффективному использованию», практика практике рознь равно как и опыт, ещё и от проекта зависит, и от клиента, и от методологии, лучше погугли «merge vs rebase»

а за эпос - спасибо что не поленился
у нас же кроме мастера есть stage, репа приватная, ну и сама схема:
- git checkout -b feature_branch (со stage-ветки)
- работа ведётся в feature_branch БЕЗ «накосячи при рефакторинге» и «криво прикрутили либу», ничего не мешает делать сразу правильно
- по мере необходимости примерживается stage в feature_branch, чтоб иметь у себя последние изменения
- по завершении таски поднимается CI с feature_branch, чтоб дать потестить ветку в чистом проекте в его текущем состоянии
- в конце спринта все feature_branch мержаться в stage и поднимается CI потетсить результаты спринта
- после аппрува делается мерж stage в master и деплоится prod
- завершённые ветки удаляются

прекрасно обходимся без rebase, работаем так несколько лет, все довольны, проблем с грязью нет и тратить время на чистку не приходится

при чём тут эта философия?

В основном это психология и отношение имеет самое прямое ибо уже пошёл 3ий пост про rebase, а тема конторы мало того что никуда не ушла...

не надо бросаться яркими образами типа «в мировой общепринятой практике» и «во ВСЕХ нормальных конторах»

Так и я вдруг становлюсь чёрным на вашей плантации, в твоём восприятии. Эти слова твоего авторства, у меня нет ничего подобного, даже хоть чуточку похожего по смыслу.

работа ведётся в feature_branch БЕЗ «накосячи при рефакторинге» и «криво прикрутили либу», ничего не мешает делать сразу правильно

Это чистый максимализм не имеющий ничего общего с реальностью. Человеку мешает сразу всё делать правильно сам человек, нет у него физической способности одновременно думать о многом. Потому с увеличением сложности работы существенно увеличиваются возвраты назад. Собственно с чего всё началось...

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

все довольны, проблем с грязью нет и тратить время на чистку не приходится

«Доволен» это явление относительное. Пользователи svn, например, гадят прямо в trunk беспощадно и бесмыссленно - тоже довльны и не считают что у них есть какая-то там грязь. Трудно найти инженера который бы не был доволен тем как он работает.

чистый максимализм не имеющий ничего общего с реальностью

и опять ты каким-то образом лучше меня знаешь как мы работаем и что делаем

«Доволен» это явление относительное

ну я так и сказал, практика практике рознь, опыт опыту рознь
очень много параметров чтоб всех причёсывать однаково

и опять ты каким-то образом лучше меня знаешь как мы работаем и что делаем

Если хорошо известно, что дровосек недюжинной силы, орудая топором и надрываясь что есть сил, максимум может за сутки выработать N кубометров древесины в лесу обыкновенном, то вполне очевидно, что любой другой дровосек не сможет дать 1.5N или 2N кубометров где бы это не было в аналогичной лесополосе имея схожий по функциональности топор. Для понимания этого простого факта не нужно знать как вы там что делаете.

ну я так и сказал, практика практике рознь, опыт опыту рознь очень много параметров...

Грязь то в репозитории конкретное понятие, примерно как и гогнокод - их можно формализовать и придумать как оценивать численно. Соответственно и рекомендации как избегать гогнокода относительно универсальны. А всё что ты тут описываешь под практикой и вашим «workflow» является чистой административной вертикалью власти в вашей конторе и слабо связано с качеством результата.

В нормальный граф можно вставить произвольные узлы без переписывания всего графа :) Поэтому и возникают непонятки...

Что именно возможно в твоём «нормальном графе в вакууме» это одно... Но не стоит забывать что git в своей истории хранит разницу. И для минимизации объёма истории... Да и мы ж не инопланетяне какие а вполне вменяемые люди 21го века и время у нас течёт вполне себе линейно а следовательно у любого процесса вообще и у процесса разработки ПО в частности есть начало есть некие этапы и есть конец. Вот и git-у в таких условиях нет никакой необходимости хранить любую разницу между произвольными узлами твоего «нормального графа» потому что он создан вовсе не для инопланетян с их нелинейным течением времени а для вполне реальных людей с обычными задачами. Именно поэтому граф в git не совсем «нормальный» а вот именно такой какой есть.

Нет, семантически git в своей истории хранит полные копии блобов. Дельта-сжатие — это дополнительная оптимизация.

И принципиальный вопрос не в способе хранения, а в том, что в Git все объекты идентифицируются по своим хэшам, и нельзя изменить объект без того, чтобы переписать все ссылки на него в других объектах (что, разумеется, повлёчёт за собой цепное переписывание всего подграфа истории, из которого достижим указанный объект). И это не баг, а фича.

Нет, семантически git в своей истории хранит полные копии блобов. Дельта-сжатие — это дополнительная оптимизация.

Это самое «дельта-сжатие» по умолчанию зачастую скорее есть чем его нет. Именно потому что ссылки (т.е. твой абзац №2) и закономерно что в таком случае хранится только разница между двумя закоммиченными точками «соседними во времени» а не между любыми точками во всём графе.

И это всё опять же потому что инструменты делаются под конкретные задачи а их условия диктует реальный мир.

Оно появляется только при упаковке блобов в pack. Когда ты коммитишь, до первого repack'а новые блобы сохраняются «просто так». В любом случае, по смыслу Git хранит полные блобы, которые ссылаются друг на друга по хэшам, и юзкейс ТС вступает в конфликт именно с этим фактом, а не с дельта-сжатием.