Это легко сделать в IntelliJ IDEA с командой Recently Edited Files (Последние отредактированные файлы), назначенной на Ctrl + Shift + E (Cmd + Shift + E для OS X):
В новых версиях (вроде с 2019.1), это уже так не работает. Теперь, чтобы перейти на список последних отредактированных файлов, надо нажать Cmd + E (откроется список недавних файлов) и еще раз Cmd + E (чтобы показать только измененные файлы).
Cmd + Shift + E же, теперь, открывает новый и довольно полезный диалог Recent Locations, который тоже может быть отфильтрован, чтобы показывать только изменения (если нажать еще раз Cmd + Shift + E), и показывает не только название каждого файла, но еще и кусочек кода.
Да, тут мы друг друга недопоняли. Я изначально отвечал на этот вот комментарий:
Есть экономическая целесообразность такого переезда? За сколько лет можно социализироваться (машина, квартира) при зарплате 50к, например? Сколько в Берлине стоят продукты? Пассат? Квартира, коммуналка?
Почему немцы сдают жилье на месяцы своего отъезда? Жмотятся или плохо живут?
Отсюда и взялась зарплата в 50к и разговор исключительно об экономической составляющей. И да, я бы на 50к с женой и двумя детьми не поехал.
«Денег у нас стало меньше, а уровень жизни стал выше»
Согласны с этим тезисом?
С вами удивительно трудно вести беседу — вы постоянно передергиваете. Я не говорил, что где-то нашел 230к чистыми да еще и для мидла, не надо придумывать. Я даже и не искал. Я сказал лишь что 230 для Питера не выглядит как фантастическая зарплата. Да, это явно не зарплата мидла, но для сеньора вполне реальная, особенно фрилансера. А главное, что в Питере все (или почти все) значительно дешевле (в т.ч. жилье и машины — в 2 раза).
1. Я свожу к экономической составляющей, потому что вопрос на который я изначально отвечал был исключительно про нее. В своем первом комментарии я уточнил, что экономическая составляющая для большинства моих знакомых (и меня) не являлась основной мотивацией для переезда.
2. Я не говорил что 150 на интернет. Я сказал что 150 это интернет, телефоны и электричество. Интернет 40 + 2 мобильника по ~15 + электричество ~50, выходит 120 или чуть больше (если у обоих безлимит с LTE). По минимуму если брать ну будет 100 за все, никак не 25-50.
3. На еду я написал включая хозтовары (мыло там всякое, шампуни, бытовая химия), назвав это все «продукты». У меня лично меньше 700 на это ну никак не получается, но, конечно всегда есть возможность сэкономить.
4. С жильем и 2-мя детьми не все так просто. Двушку снять тяжело, большинство отказывают. Нормальные трешки не очень далеко от центра от 900 начинаются, насколько я видел когда последний раз смотрел
Кстати, мы с вами начали работать в Берлине в один день =)
Ну мы же говорим не о гипотетической «европейской» зарплате, а о вполне конкретной — 50к в год. Что после вычета налогов будет примерно 2.8к в месяц (при неработающей жене). В пересчете на рубли выходит где-то 230к рублей в месяц, что не выглядит фантастически для Питера.
А по расходам в Берлине будет около 1000 на жилье, 200 на дет. садик (для двоих), где-то 700-800 на продукты, 150 на интернет, телефоны и электричество, 162 — общественный транспорт на двоих (если покупать помесячно), еще хочется чтобы дети занимались спортом и музыкой — у меня на это выходит где-то еще 300, плюс обеды на работе где-то 150. Уже из зп ничего не остается. А еще надо одежду покупать и иногда ходить развлекаться, спортом заниматься, путешествовать и что-то откладывать.
Правда еще 380 евро будет государство за 2-х детей доплачивать, так что прожить, наверное, все таки можно. Но все равно, я бы не сказал что это выглядит экономически привлекательно.
Как человек, переехавший 1.5 года назад в Берлин из Питера, могу сказать, что в данный момент, экономической целесообразности в переезде в Берлин нет вообще. Несмотря на то, что Берлин по европейским меркам очень дешевый город, по современным курсам тут все совсем не дешево. Продукты так же либо дороже, жилье гораздо дороже, коммуналка дорогая, немецкие машины в Германии стоят примерно в 2 раза дороже чем в России, общественный транспорт тоже очень дрогой. Я бы сказал что на 50к прожить с неработающей женой и 2 детьми было бы очень тяжело, если вообще реально.
Из всех моих знакомых, никто не приехал в Берлин из экономических соображений. В основном люди едут ради опыта, спокойствия, социальной защищенности, безопасности и т.д.
Ну вот, по-моему, основная ценность как раз в том, что теперь есть официальный способ делать это без костылей. Раньше кто-то использовал Figaro, кто-то RailsConfig, кто-то свои yaml-ы, инициалайзеры и другие костыли. Нравится вам Figaro — используйте, никто не заставляет переходить. Но для тех кто начинает новый проект на рельсах, теперь на одну проблему меньше. На мой взляд, это хорошее нововведение, а никак не костыль.
Это официальный способ хранения конфируации теперь (в том числе секретных ключей, но не только). Вы смотрели на secrets.yml, который создается генератором нового приложения? Там по-умолчанию пробиты значения для test и development окружения, а для production берется из окружения (через ERB). Соответсвенно, когда разработчик берет код из репозитория, у него локально все сразу работает. При деплое тоже не надо создавать/линковать никаких файлов, достаточно выставить переменные окружения. Ну и при этом доступ к конфигурации из приложения через Rails.application.secrets. Вроде все удобно (если, конечно, в gitignore не добавлять).
А зачем добавлять secrets.yml в gitignore? Как раз удобно иметь его в репозитории, чтобы избежать трюкачества при деплое. И генератор нового приложения в Rails 4.1, кстати, его в gitignore не добавляет.
Да, именно так. Фича которая не вмещается в день работы разбивается на подфичи, которые интегрируются в мастер каждый день. Зачем? Ну плюсы такие же как у continous integration подхода в чего чистом виде — избежать больших и сложных мержей, которые часто приводят к ошибкам.
Например, представьте ситуацию, что у вас в команде 10 разработчиков, каждый из которых месяц работает в своем бранче. А через месяц они начинают все это дело мержить в мастер. Вероятность того, что такой глобальный мерж 10-ти веток (каждая из которых эволюционировала целый месяц) пройдет гладко — крайне мала. Будет долго, сложно, и высока вероятность добавления ошибок.
Отлично, если это работает для вас. Я считаю, что идеального workflow не существует. Для нас работает наш, для вас — ваш. Это прекрасно. Кстати, вы таки используете merge или rebase?
Именно поэтому мы и не любим долгие бранчи. Если бы Вася работал у нас, было бы 30 коммитов, но каждый в своем бранче. И subfeature-s попадали бы в мастер по мере готовности, а не когда готовы все 30.
Вася не правильно пользуется rebase-ом, значит нету продуманного workflow работы с git-ом (понятного разработчикам), значит виноват Антон.
Мое мнение состоит в том, что нельзя просто взять и заменить merge на rebase, в надежде, что все будет как раньше, только с линейной историей. Rebase — это сложный инструмент, который переписывает историю. Поэтому для его безболезненного использования нужна какая-то стратегия, основанная на разумных ограничениях. У нас, например, это 3 простых правила:
1. Squash коммитов перед мержем ребейзнутого бранча в мастер
2. Фича бранчи мержатся в мастер не реже чем раз в день (гибрид постоянной интеграции и бранчевания)
3. Никаких rebase-ов для запушенных данных
При этом, правило номер 2 выполняется не всегда. Скажем, если мы берем контрактника на определенную задачу, то для него вполне нормально будет сидеть в своем фича бранче месяц, а потом выдать в мастер один коммит (в результате rebase+squash). Если что-то пойдет не так после попадания его работы в мастер, то и откатить его задачу целиком будет очень просто (поскольку это один коммит).
Если бы Вася пользовался этими правилами (или даже только 1-м), то проблема, описанная в статье, не возникла бы.
Что значит «как раз»? Этот пример и был изначально. «Патч» устарел, именно поэтому и делается rebase. После этого (если тесты проходят), о какой еще доработке идет речь? Да, возможно, будет ревью, но такая ошибка легко может быть не замечена при ревью и попадет в мастер.
На мой взгляд, вы торопитесь с выводами, говоря что тут rebase притянут за уши, и что мы им не правильно пользуемся. Описанный мной сценарий довольно популярен, и является рекомендованным, например, при разработке Ruby on Rails.
Если представить, что оба разработчика из моего примера не являются core members и не могут пушить в мастер, а только шлют пулл реквесты и при этом соблюдают рельсовый contribution guide, то именно так в жизни это и будет выглядеть. Шаги 4 и 7 будут выполнены через пулл реквесты.
Посмотрите, пожалуйста, внимательнее. Тут совсем не «Все что вы делаете это переносите патч в другую ветку». Тут классическая история, когда во время разработки feature2, мастер (естественно) ушел вперед. Поэтому чтобы влить feature2 назад в master, мы делаем сначала rebase, тем самым записывая изменения произведенные в feature2 поверх уже нового мастера. После этого шлем pull request (ну или мержим feature2 в мастер сами).
Прочитал выше — не понимаю, что конкретно не корректно. Я специально проверил прежде чем писать комментарий. Все получилось как у автора, конфликта при rebase не было, а ошибка в итоге появилась. Пробовал именно такой сценарий, который используеся у нас (и не только, он довольно стандартен). Опишу подробнее по шагам, чтобы прояснить:
1. Есть master в котором есть файл с таким содержимым:
сумма
2
и
2
равна
4
2. Есть 2 разработчика, каждый создает свой бранч (feature1, feature2)
3. В feature1 вносится изменение: слово «сумма» меняется на «произведение». Коммитит.
4. feature1 мержится в мастер (не важно через pull request или нет)
5. В feature2, другой разработчик меняет «2» и «4» на «3» и «5» соответсвенно. (У него по-прежнему «сумма», а не «произведение», потому код верный). Коммитит.
6. В feature2 делается git rebase master. Тут rebase проходит автоматически, конфликта НЕ возникает, в коде появляется ошибка, как описал автор.
7. feature2 мержится в мастер. В результате ошибка оказывается в мастере.
Еще раз хочу отметить, что при merge ошибка точно также возникнет. Но как справедливо заметил автор, по истории git-а в случае merge будет легче разобраться как и почему так получилось. Вроде об этом и статья.
Спасибо автору за хороший пример. Хочу еще раз отметить, что ошибка возникает и в том и другом случае, просто в случае с rebase сложнее понять историю и контекст ее внесения.
Нужно просто помнить, что любое решение в IT это всегда компромисс. Серебряной пули не существует и приходится постоянно делать осознанный выбор, чем-то жертвуя и что-то получая взамен.
Git очень гибок, предоставляет кучу возможностей и допускает разные сценарии работы с ним, но требует хорошего понимания что происходит и что может случиться.
У нас в проекте сейчас используется стратегия rebase (+squash), что позволяет держать историю коммитов красивой, компактной и почти линейной. Проект не очень большой, и ошибки такого рода у нас возникают очень редко (если вообще возникают), благодаря изолированности изменений (как правило разные разработчики редко правят одни и те же файлы) и тестам. Ну а если вдруг возникают — то у нас это не повод кого-то увольнять, а повод покрыть этот код тестом и исправить ошибку. Причина появления ошибки вторична.
Выбор, конечно, должен быть осознанным. Но ведь как чертовски хорошо, что Git нам дает право на этот выбор!
В новых версиях (вроде с 2019.1), это уже так не работает. Теперь, чтобы перейти на список последних отредактированных файлов, надо нажать Cmd + E (откроется список недавних файлов) и еще раз Cmd + E (чтобы показать только измененные файлы).
Cmd + Shift + E же, теперь, открывает новый и довольно полезный диалог Recent Locations, который тоже может быть отфильтрован, чтобы показывать только изменения (если нажать еще раз Cmd + Shift + E), и показывает не только название каждого файла, но еще и кусочек кода.
В Питере можно работать удаленно на каких-нибудь американцев со скромным рейтом 30$/h и это выйдет около 300к рублей.
Отсюда и взялась зарплата в 50к и разговор исключительно об экономической составляющей. И да, я бы на 50к с женой и двумя детьми не поехал.
Абсолютно. У меня то же самое.
1. Я свожу к экономической составляющей, потому что вопрос на который я изначально отвечал был исключительно про нее. В своем первом комментарии я уточнил, что экономическая составляющая для большинства моих знакомых (и меня) не являлась основной мотивацией для переезда.
2. Я не говорил что 150 на интернет. Я сказал что 150 это интернет, телефоны и электричество. Интернет 40 + 2 мобильника по ~15 + электричество ~50, выходит 120 или чуть больше (если у обоих безлимит с LTE). По минимуму если брать ну будет 100 за все, никак не 25-50.
3. На еду я написал включая хозтовары (мыло там всякое, шампуни, бытовая химия), назвав это все «продукты». У меня лично меньше 700 на это ну никак не получается, но, конечно всегда есть возможность сэкономить.
4. С жильем и 2-мя детьми не все так просто. Двушку снять тяжело, большинство отказывают. Нормальные трешки не очень далеко от центра от 900 начинаются, насколько я видел когда последний раз смотрел
Кстати, мы с вами начали работать в Берлине в один день =)
А по расходам в Берлине будет около 1000 на жилье, 200 на дет. садик (для двоих), где-то 700-800 на продукты, 150 на интернет, телефоны и электричество, 162 — общественный транспорт на двоих (если покупать помесячно), еще хочется чтобы дети занимались спортом и музыкой — у меня на это выходит где-то еще 300, плюс обеды на работе где-то 150. Уже из зп ничего не остается. А еще надо одежду покупать и иногда ходить развлекаться, спортом заниматься, путешествовать и что-то откладывать.
Правда еще 380 евро будет государство за 2-х детей доплачивать, так что прожить, наверное, все таки можно. Но все равно, я бы не сказал что это выглядит экономически привлекательно.
Из всех моих знакомых, никто не приехал в Берлин из экономических соображений. В основном люди едут ради опыта, спокойствия, социальной защищенности, безопасности и т.д.
Например, представьте ситуацию, что у вас в команде 10 разработчиков, каждый из которых месяц работает в своем бранче. А через месяц они начинают все это дело мержить в мастер. Вероятность того, что такой глобальный мерж 10-ти веток (каждая из которых эволюционировала целый месяц) пройдет гладко — крайне мала. Будет долго, сложно, и высока вероятность добавления ошибок.
Отлично, если это работает для вас. Я считаю, что идеального workflow не существует. Для нас работает наш, для вас — ваш. Это прекрасно. Кстати, вы таки используете merge или rebase?
Мое мнение состоит в том, что нельзя просто взять и заменить merge на rebase, в надежде, что все будет как раньше, только с линейной историей. Rebase — это сложный инструмент, который переписывает историю. Поэтому для его безболезненного использования нужна какая-то стратегия, основанная на разумных ограничениях. У нас, например, это 3 простых правила:
1. Squash коммитов перед мержем ребейзнутого бранча в мастер
2. Фича бранчи мержатся в мастер не реже чем раз в день (гибрид постоянной интеграции и бранчевания)
3. Никаких rebase-ов для запушенных данных
При этом, правило номер 2 выполняется не всегда. Скажем, если мы берем контрактника на определенную задачу, то для него вполне нормально будет сидеть в своем фича бранче месяц, а потом выдать в мастер один коммит (в результате rebase+squash). Если что-то пойдет не так после попадания его работы в мастер, то и откатить его задачу целиком будет очень просто (поскольку это один коммит).
Если бы Вася пользовался этими правилами (или даже только 1-м), то проблема, описанная в статье, не возникла бы.
Если представить, что оба разработчика из моего примера не являются core members и не могут пушить в мастер, а только шлют пулл реквесты и при этом соблюдают рельсовый contribution guide, то именно так в жизни это и будет выглядеть. Шаги 4 и 7 будут выполнены через пулл реквесты.
Посмотрите, пожалуйста, внимательнее. Тут совсем не «Все что вы делаете это переносите патч в другую ветку». Тут классическая история, когда во время разработки feature2, мастер (естественно) ушел вперед. Поэтому чтобы влить feature2 назад в master, мы делаем сначала rebase, тем самым записывая изменения произведенные в feature2 поверх уже нового мастера. После этого шлем pull request (ну или мержим feature2 в мастер сами).
1. Есть master в котором есть файл с таким содержимым:
сумма
2
и
2
равна
4
2. Есть 2 разработчика, каждый создает свой бранч (feature1, feature2)
3. В feature1 вносится изменение: слово «сумма» меняется на «произведение». Коммитит.
4. feature1 мержится в мастер (не важно через pull request или нет)
5. В feature2, другой разработчик меняет «2» и «4» на «3» и «5» соответсвенно. (У него по-прежнему «сумма», а не «произведение», потому код верный). Коммитит.
6. В feature2 делается
git rebase master. Тут rebase проходит автоматически, конфликта НЕ возникает, в коде появляется ошибка, как описал автор.7. feature2 мержится в мастер. В результате ошибка оказывается в мастере.
Еще раз хочу отметить, что при merge ошибка точно также возникнет. Но как справедливо заметил автор, по истории git-а в случае merge будет легче разобраться как и почему так получилось. Вроде об этом и статья.
Нужно просто помнить, что любое решение в IT это всегда компромисс. Серебряной пули не существует и приходится постоянно делать осознанный выбор, чем-то жертвуя и что-то получая взамен.
Git очень гибок, предоставляет кучу возможностей и допускает разные сценарии работы с ним, но требует хорошего понимания что происходит и что может случиться.
У нас в проекте сейчас используется стратегия rebase (+squash), что позволяет держать историю коммитов красивой, компактной и почти линейной. Проект не очень большой, и ошибки такого рода у нас возникают очень редко (если вообще возникают), благодаря изолированности изменений (как правило разные разработчики редко правят одни и те же файлы) и тестам. Ну а если вдруг возникают — то у нас это не повод кого-то увольнять, а повод покрыть этот код тестом и исправить ошибку. Причина появления ошибки вторична.
Выбор, конечно, должен быть осознанным. Но ведь как чертовски хорошо, что Git нам дает право на этот выбор!
Ваш КО.