TL;DR При изменении коммита не откатывайте изменения в файле полностью, если этот коммит уже мержился в другую ветку.

Иначе, если вы полностью отмените сделанные в файле изменения, то он пропадет из дифа этого коммита, и при повторном мерже с ним ничего не произойдет. Все будет так, как и было в целевой ветке до мержа. git merge будет говорить Already up-to-date, но содержимое файлов будет разным в этих ветках.

Простой пример из практики. Вы написали console.log в своей ветке, замержили в стейджинг, задеплоили, потестили, вспомнили, что был лишний код, пошли откатили этот console.log, замержили в стейджинг снова, все замержилось без конфликтов, но console.log в стейджинге остался, а у вас в ветке – нет.

Притом это работает в любую сторону на уровне файла. Удалили строку в файле –> замержили куда-то –> вернули ту же строку в файл поменяв коммит –> замержили снова. Там где меняли строка есть, там куда мержили нет. Получается классическая ситуация: “А у меня на ноутбуке все работает, сами ищите что не так!”.

Погнали разбираться ну как так-то

Создадим репозиторий и в нем два файла:

Большинство скорее всего знакомы с “магическим” аргументом - для комнады cd в консоли. Это переход в предыдущую выбранную дирректорию.

Работает так:

1
2
3

8xx8@mac ~/git-minus[master] $ cd /
8xx8@mac / $ cd -
8xx8@mac ~/git-minus[master] $

Некоторые знают о том, что git поддерживает похожее поведение при смене ветки:

1
2
3
4
5
6
7

8xx8@mac ~/git-minus[master] $ git co feature
Switched to branch 'feature'
8xx8@mac ~/git-minus[feature] $ git co -
Switched to branch 'master'
8xx8@mac ~/git-minus[master] $ git co -
Switched to branch 'feature'
8xx8@mac ~/git-minus[feature] $

Здесь я использовал алиас co для checkout. Вообще про алиасы у меня была отдельная статья.

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

Я давно пользуюсь The Silver Searcher как заменой стандартному grep. О достоинствах такого выбора можно посмотреть на странице проекта.

Для своего любимого редактора я долгое время использовал плагин Ack. Он обладает рядом багов, но в целом пользоваться можно.

Недавно я наткнулся на его форк Ag. Зацепило в нем две вещи:

• строка поиска сохраняется в регистр поиска;
• наличие комманды AgFromSearch, которая позволяет искать то, чтобыло в регистре поиска.

Эти факторы позитивно влияют на продуктивность.

В найденом файле все вхождения будут подсвечены (ну если включен hlsearch), и по нему сразу можно будет перемещаться с помощью n или N.

Если нужно поискать слово из текущего файла, нажимаем на этом слове * и выполнив :AgFromSearch без параметров сразу получаем результат.

Так же интересной показалась команда :AgFile, для поиска файла по имени.

Ну и как бонус, две буквы набирать проще трех.

Несколько дней назад во время обеда у меня произошел такой диалог с коллегой:

— Ты дочитал книгу про Vim?
— Нет.
— А идеальный питч?
— Нет. Только половину.
— Эх, ну ты и читатель!

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

Такое положение дел меня не устраивает.

1
2

cat ~/.zsh_history | wc -c
431403

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

Не знаю как вам, а я думаю, это много. Даже если учесть, что половину из этого занимают пути к файлам и части, дополненные автокомплитом, это все равно много. Статистика взята примерно за 4 месяца, и если выкинуть выходные и прикинуть, получается около 6000 знаков в день. Пара страниц формата А4. Большая часть этого труда – это рутинные команды или последовательности типичных действий.

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

Часто ли вы задумывались над тем, какие ветки будут отправлены в удалённый репозиторий при выполнении команды push?

А поможет ли вам задуматься над этим такая картина?

Наверное, поможет, особенно если увидеть это в ночь перед релизом. А началось-то все с того, что хотели фичу красиво слить через rebase.

Так давайте разберёмся, что пошло не так.

В компании, в которой я работаю в настоящее время, мы используем при разработке довольно распространённую модель ветвления, а в качестве инструмента для стандартизации работы по этой схеме git-flow. Так же мы дополнили эту схему ещё одной веткой — staging. Это временная ветка, в которую сливаются feature branches, и на основе неё делаются промежуточные релизы на тестовый сервер. Естественно, всё, что происходит в этой ветке, нужно для предварительного просмотра и тестирования выполненных задач и никак не должно попадать ни в основную ветку разработки, ни в master, то есть в итоговый релиз. В принципе, схема работы достаточно удачная. Она упрощает взаимодействие и работу большой команды с разным навыком работы с git, и нештатные ситуации случаются достаточно редко, но зато, если случаются, то это запоминается надолго.

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

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

Мечта? Нет. Реальность.

Сейчас стало модным делать стартапы. У каждого второго разработчика есть свой. А в Rails сообществе ­— у каждого первого, наверное. И чтобы оставаться в тренде я тоже решил принять участие в разработке одного интересного сервиса.

Небольшая история о том, как я докатился до такой жизни.

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

Я написал плагин для этого. https://github.com/Andrew8xx8/jekyll-link