O>вопрос изначально как это все регулировать, интересно как это решают в других командах без потрясений и боли.
а пробовали самый дерзкий метод: сказать "петя, не делай больше так, пожалуйста" ?
иногда это помогает, ведь есть шанс, что товарищ просто не подумал что это кого-то может смущать.

Здравствуйте, okon, Вы писали:

O>Внимательно смотрел сообщение ? При создании нового файла данная информация пропадает

А не надо удалять/создавать — надо перемещать. Если в той же Тортиле потащить файлик правой кнопкой, то он чётко спросит "чего делаем". При git-перемещении вся история продолжается, вне зависимости от того в какой подпапке репозитория был файлик в тот или иной момент времени.

Здравствуйте, Faland, Вы писали:

F>Хм, давно не работал с Гитом, но это ж базовый тул любой VCS, неужто нет нормального GUI на базе git blame? А то у нас контора как раз массово переходит с P4 на Гит в след году.... P4 Timelapse за секунды позволяет найти кто написал тот или иной код, рефакторинг и прочие чистки легко проматываются и смотришь на предыдущие версии.

Гит штука хорошая. Но git blame покажет последнего разработчика. Чтобы посмотреть предыдущего придётся либо умахаться, либо очень хорошо знать гит, либо использовать сторонние тулы. Т.е. все варианты плохие и не подходят для массового использования.

Здравствуйте, okon, Вы писали:

O>2111 Petya removed file
O>2222 Petya Add file New Functionality and reformat

Если это один коммит, то оно криво, конечно, но в истории все равно все видно — прыгаем туда, где файл создан и оно показывает, какой файл был удален. Пете на код-ревью объясняем, чтоб пользовался git mv.

Если это два разных коммита, то ситуация более чем странная сама по себе. Если файл спокойно удалили и ничего не поломалось, то зачем этот файл там был нужен? Поэтому я таки предполагаю, что это все-таки один коммит и Пете просто нужно вежливо объяснить, как пользоваться git mv.

Здравствуйте, Anonymous123, Вы писали:

O>>Замечаю тенденцию последних лет, разработчики любят перекомичивать сделанное другими путем перемещения файлов или какого-нибудь форматирования.
O>>В итоге не всегда понятно кто сделал данный функционал, как вы боретесь с этим явлением, запрещаете перемещение, в комментариях пишете автора или иначе ？

A>У меня в команде некоторые разработчики метят код путем переименования переменных в в венгерскую нотацию и вводят много временных переменных типа sTmp. Видя такой код, я сразу знаю, кто это написал

Код ревью на них нет! Ужасно. Хуже всего, если они это делают, когда редактируют часть чужого кода. Тогда получится, что часть переменных в методе нормально названа, а часть на мадьярском.

Здравствуйте, alzt, Вы писали:


A>А целом действует принцип — "кто последний, тот и папа". Переименовал метод, теперь его поддерживаешь, все вопросы к тебе.
Программный код проекта — это зона ответственности всех членов команды. Иначе bus-factor очень маленький.

Здравствуйте, okon, Вы писали:

O>Замечаю тенденцию последних лет, разработчики любят перекомичивать сделанное другими путем перемещения файлов или какого-нибудь форматирования.
O>В итоге не всегда понятно кто сделал данный функционал, как вы боретесь с этим явлением, запрещаете перемещение, в комментариях пишете автора или иначе ？

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

Здравствуйте, okon, Вы писали:

PM>>TortoiseGit показывает изменения для каждой строки кода в файле: https://tortoisegit.org/docs/tortoisegit/tgit-dug-blame.html
O>Внимательно смотрел сообщение ? При создании нового файла данная информация пропадает
Это не так. Git использует эвристики для реконструкции перемещений фрагментов кода. Там нужно весь файл перекорёжить, чтобы они сломались.

Здравствуйте, CreatorCray, Вы писали:

O>>Возможно, но мне например порой хочется узнать кто же придумал эту чудесную логику, как в хорошем, так и в плохом смысле.
CC>В P4 был замечательный тул Timelapse, который мог очень просто а главное наглядно показать историю изменений, в новомодных говногитах его очень сильно не хватает.
"Show history for selection" в IDEA...

Здравствуйте, okon, Вы писали:

O>Замечаю тенденцию последних лет, разработчики любят перекомичивать сделанное другими путем перемещения файлов или какого-нибудь форматирования.
O>В итоге не всегда понятно кто сделал данный функционал, как вы боретесь с этим явлением, запрещаете перемещение, в комментариях пишете автора или иначе ？

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

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

И в общем и целом улучшает уровень владения кодом.

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

А точный автор обычно не так интересен. Интересно почему что-то было сделано именно так. И вот это далжно быть описано в коммите или соотв баге. Так что бы средневзятый последователь понял суть.

В общем внедряй. Тем более во всяких гитлабах, гитхабах это просто вопрос силы воли.

CAF>В общем внедряй. Тем более во всяких гитлабах, гитхабах это просто вопрос силы воли.

Да в целом выглядит как годное решение, забыл я это слово “код ревью”。

Здравствуйте, okon, Вы писали:

O>да вроде не дурак и думаю даже знает о этих функциях, поэтому я и написал “метить код”. подобные случаи возникают не однократно сложилось впечатление что это порой делают намеряно, мотив не совсем понятен кроме как иммитация бурной деятельности.

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