Vi/Vim выполняют свою работу, а IDE свою. Подправить один файлик или следить за маленьким проектом — это одно. Другое дело, когда в проекте тысячи классов со сложными зависимостями. Да и вдобавок ты не знаешь весь проект наизусть. IDE придумали далеко не глупые люди. Хотя использование мыши и вызывает дискомфорт, моментальный переход по классам/методам и автокомплит экономят намного больше времени. Снипеты и макросы — тоже неплохое подспорье. Это конечно не мощные команды vim, но они расширяют спектр возможностей.
Вывод из этого один. Я не понимаю людей, которые используют vim для написания кода. В статье уверенно доказывается, что vim намного лучше всего остального, как текстовый редактор. Но это и есть текстовый редактор. Многие сейчас использует IDE. Но IDE — это не текстовый редактор. У него совсем другие функции.
Вывод в статье совсем неадекватный. Интересная статья, а посыл в ней грязный. Считая себя самым умнын, автор убеждает всех в обратном.
Спасибо за перевод. Несмотря на посыл статьи, материал очень познавательный.
Не делает баги тот, кто не пишет код. Код без багов — это такой же идеал, как и ТЗ, к которому не придерешься. А если за такое наказывать, то наказывать вскоре будет некого.
Поэтому мы стараемся задачи делить на максимально мелкие. Такие атомарные бранчи после успешного билда могут сразу мержиться в дев без qa (если это чисто техническая работа). А насчет конфликтов, так любой бранч потенциально может быть конфликтным. Волков бояться, в лес не ходить. Если уж так много проблем доставляет разработка в отдельной ветке, то зачем тогда использовать такой подход? А насчет побыстрее избавиться от ветки, то тут уже не только проблема разработчика. Ветка может застояться и при мерже выдать кучу конфликтов, хотя она и была линейным продолжением. Тут слишком размытые грани, чтобы брать что-то как правило. ИМХО Каждая команда поступает так, как ей удобнее.
По скоупам понял. Могу вам только посочувствовать =( Тут уже никакой workflow не подходит. Вероятно в данном случае ваш подход наиболее продуктивный. Спасибо за пример. Однако, если говорить о хоть каком-то workflow, то в этом я не вижу особой необходимости.
Ну назвать пару коммитов одного файла деревом трудно, но думаю можно и так сказать. Тогда могу сказать, что грязная история лично мне не мешала. Но на вкус и цвет =) А проект по сухому описанию похож на ваш.
Напоследок могу пожелать вам поменьше конфликтов. Спасибо, было приятно и полезно пообщаться.
Непонятный момент как раз заключается в том, что мне на практике не приходилось смотреть в историю (графическое представление). Интересно было бы послушать кейс, когда это необходимо.
1) У нас тесты запускаются по факту пуша в ветку и собирают самую актуальную версию ветки (на момент начала сборки). Просто не вижу, как это может быть связано с грязной историей.
3) Не встречал проблем с активной работой с бранчами. Как раз наоборот. Чем их больше, тем проще работать командой. А насчет изменения скоупа. Его разве не проще просматривать в трекере задач?
Насчет команды git log. Пользовался из консоли обычно для того, чтобы откатить свои последние коммиты (git reset). Для того, чтобы найти последние изменения мне хватает ide. Аннотаций или истории файла вполне хватает. Если по истории, то это обычно 1-5 коммитов (включая мерж коммиты). На дерево не смотрел ни разу, если не считать случаев из любопытства. Для того, чтобы понять, как работает функционал, я обычно смотрю в тесты, а не в историю. Единственное, что я могу сейчас предположить, это то, что возможно у вас слишком перенасыщенные классы. Я такие классы советую дробить на более мелкие. Если класс выполняет строго отведенную ему задачу, то его код редко меняется. А разгрузив таким образом основной класс, вы разгрузите и историю изменений этого класса. Возможно проблема кроется в другом.
Не особо понимаю практический смысл такой чистой истории. Если вам не сложно, не могли бы вы пояснить его?
По поводу потребностей:
1) Какое событие инициирует тесты? (вы ведь про ci?)
2) Используйте номер таска в названии коммита.
3) Не до конца понял эту потребность. Какую информацию предоставляет «частое изменение скоупа, полученное из истории гита»?
Я просто не встречал ситуацию на практике, когда мне нужно было использовать графическое представление истории.
Вывод из этого один. Я не понимаю людей, которые используют vim для написания кода. В статье уверенно доказывается, что vim намного лучше всего остального, как текстовый редактор. Но это и есть текстовый редактор. Многие сейчас использует IDE. Но IDE — это не текстовый редактор. У него совсем другие функции.
Вывод в статье совсем неадекватный. Интересная статья, а посыл в ней грязный. Считая себя самым умнын, автор убеждает всех в обратном.
Спасибо за перевод. Несмотря на посыл статьи, материал очень познавательный.
По скоупам понял. Могу вам только посочувствовать =( Тут уже никакой workflow не подходит. Вероятно в данном случае ваш подход наиболее продуктивный. Спасибо за пример. Однако, если говорить о хоть каком-то workflow, то в этом я не вижу особой необходимости.
Ну назвать пару коммитов одного файла деревом трудно, но думаю можно и так сказать. Тогда могу сказать, что грязная история лично мне не мешала. Но на вкус и цвет =) А проект по сухому описанию похож на ваш.
Напоследок могу пожелать вам поменьше конфликтов. Спасибо, было приятно и полезно пообщаться.
1) У нас тесты запускаются по факту пуша в ветку и собирают самую актуальную версию ветки (на момент начала сборки). Просто не вижу, как это может быть связано с грязной историей.
3) Не встречал проблем с активной работой с бранчами. Как раз наоборот. Чем их больше, тем проще работать командой. А насчет изменения скоупа. Его разве не проще просматривать в трекере задач?
Насчет команды git log. Пользовался из консоли обычно для того, чтобы откатить свои последние коммиты (git reset). Для того, чтобы найти последние изменения мне хватает ide. Аннотаций или истории файла вполне хватает. Если по истории, то это обычно 1-5 коммитов (включая мерж коммиты). На дерево не смотрел ни разу, если не считать случаев из любопытства. Для того, чтобы понять, как работает функционал, я обычно смотрю в тесты, а не в историю. Единственное, что я могу сейчас предположить, это то, что возможно у вас слишком перенасыщенные классы. Я такие классы советую дробить на более мелкие. Если класс выполняет строго отведенную ему задачу, то его код редко меняется. А разгрузив таким образом основной класс, вы разгрузите и историю изменений этого класса. Возможно проблема кроется в другом.
По поводу потребностей:
1) Какое событие инициирует тесты? (вы ведь про ci?)
2) Используйте номер таска в названии коммита.
3) Не до конца понял эту потребность. Какую информацию предоставляет «частое изменение скоупа, полученное из истории гита»?
Я просто не встречал ситуацию на практике, когда мне нужно было использовать графическое представление истории.