Вы уже используете управление исходным кодом для управления своим кодом, верно? Возможно, вы даже используете SCM в качестве центрального элемента вашего рабочего процесса , как мы это делаем в New Relic .
В этой статье мы не собираемся рассматривать основы управления исходным кодом независимо от того, какой из них вы используете. Давайте просто предположим, что вы уже знаете, как обойти. Мы рассмотрим, как профессионалы используют git. Мы рассмотрим некоторые из расширенных функций и рабочих процессов, с которыми вы, возможно, еще не знакомы. Надеюсь, вы уйдете с удивительным ртом, увидев огромные возможности, которые предоставляет git!
Если вы похожи на меня, вы любите исследовать, как работают другие разработчики.
Для непосвященных или тех, кто приходит из другого SCM, Git является распределенной системой контроля версий . Он бесплатный и с открытым исходным кодом, имеет крошечную площадь и может вписаться в рабочий процесс, который подходит вам лучше всего. Как правило, это не заставляет вас работать определенным образом, а это означает, что существует множество различных методологий использования его функций, таких как промежуточные области, ветвления и пометки релизов. Если вы похожи на меня, вы любите исследовать, как работают другие разработчики. Так что будьте готовы начать модифицировать ваш .gitconfig , потому что вас .gitconfig угощение. Посмотрим, как профессионалы используют git.
Поставь свои изменения в гунны
Вы, вероятно, знакомы с случайным изменением одного файла по двум различным причинам без фиксации между ними.
Вы наверняка знакомы с добавлением файлов в промежуточную область с помощью соответствующей команды add . И вы, вероятно, знакомы с случайным изменением одного файла по двум различным причинам без фиксации между ними. Так что у вас наверняка будет git log заполненный сообщениями типа «Редактировать X и изменить несвязанный Y». Если это похоже на ваш рабочий процесс, то интерактивное добавление — ваш новый лучший друг.
Интерактивное добавление или добавление патча проведет вас по всем изменениям по одному. Когда вы добавляете файл с помощью команды -p , вам будет предложено при каждом логическом изменении (т. Е. Последовательно отредактированные строки будут сгруппированы вместе). Есть несколько вариантов, которые вы можете сделать на каждом блоке, от разделения текущего фрагмента на более мелкие, пропуска блока или даже его ручного редактирования. Используйте ? возможность увидеть полный список команд.
Начать с постановки блоков так же просто, как:
|
1
|
git add -p <FILE>
|
Оформить заказ
Как хороший программист, когда вы сталкиваетесь с чем-то, что требует быстрого исправления или очистки, вы, вероятно, должны уделить время, чтобы изменить это. Но если вы используете тяжелый рабочий процесс ветви функций, то вам не нужно это несвязанное исправление в вашей ветви функций. Это означает, что вам нужно stash текущие изменения, перейти в основную ветку, а затем внести исправления в нее. Перепрыгивание между ветками может быть утомительным, но, к счастью, есть быстрый способ перехода к последней ветке. (через Зака Холмана )
|
1
|
git checkout —
|
Этот синтаксис должен выглядеть довольно знакомым для пользователей * NIX. Команда cd имеет аналогичный ярлык ( cd - ), который будет переходить к последнему каталогу, в котором вы были. Вам никогда не придется вспоминать, как вы назвали эту ветвь функции, когда вам нужно вернуться назад; Просто git checkout - .
Показать, какие ветви объединены (или нет)
Работая с функциональными ветвями, вы можете быстро создать столько, что загромождают вывод git branch --list . Время от времени вы хотите избавиться от ветвей, которые превратили его в мастера. Но у вас, вероятно, есть небольшая пауза перед тем, как вы git branch -d <BRANCH> , но с помощью приведенных ниже команд вы можете уверенно удалить их, не задумываясь. (через Зака Холмана )
Если вы хотите увидеть, какие локальные ветки у вас есть, которые объединены с той ветвью, в которой вы находитесь, то все, что вам нужно, это:
|
1
|
git branch —merged
|
Обратное также доступно. Показать, какие ветви не были объединены в текущую выбранную ветку с помощью:
|
1
|
git branch —no-merged
|
Сделайте это с помощью нескольких простых инструментов UNIX, и вы сможете быстро удалить все, что уже было объединено:
|
1
|
git branch —merged |
|
Захватить файл из другой ветки без переключения веток
Допустим, вы экспериментируете с некоторыми рефакторингами, и у вас есть несколько веток, в которые внесены различные изменения. Если у вас есть изменения в файле в некоторой удаленной ветви, которую вы хотите внести в текущую рабочую ветку, то вы можете сделать любое количество шагов. Без приведенного ниже совета вы, вероятно, сохраните свои текущие изменения, переключите ветки и получите содержимое файла, который хотите изменить, переключитесь обратно (конечно, с помощью git checkout - ) и внесете свои изменения. Или вы можете просто извлечь этот файл, который объединит его с вашей текущей веткой (через Зака Холмана ):
|
1
|
git checkout <BRANCH> — path/to/file.rb
|
Ветви Git, отсортированные по дате последнего коммита
Итак, у вас есть загроможденный список ветвей, о котором мы говорили ранее; некоторые из тех, что вы убрали с флагом --merged . Но как насчет всех этих других отраслей? Как узнать, какие из них полезны или полностью устарели? Команда for-each-ref выведет список для каждой ветви и покажет справочную информацию для последнего коммита. Мы можем настроить вывод для включения некоторой полезной информации, но, что более важно, мы можем отсортировать список по дате. Эта команда выдаст нам список ветвей с последним сообщением о коммите и коммиттером, отсортированных в порядке убывания даты. (через Рейна Хенрикс )
|
1
|
git for-each-ref —sort=-committerdate —format=’%(committerdate:short) %(refname:short) [%(committername)]’
|
Хотя вы можете вводить эту команду каждый раз, я настоятельно рекомендую сделать ее псевдонимом и избавить себя от серьезных головных болей.
|
1
|
git config —global alias.latest «for-each-ref —sort=-committerdate —format=’%(committerdate:short) %(refname:short) [%(committername)]'»
|
Люди в стеклянных домах не должны использовать вину
Или, по крайней мере, они не должны использовать git blame без одного из параметров ниже. Виноватость сильна; это в основном как использование науки, чтобы доказать, что ты прав. Но будьте осторожны, многие изменения являются поверхностными, и чтобы найти реальный источник рассматриваемого кода, нужно немного больше охоты. Такие вещи, как удаление пробелов, перемещение текста на новые строки или даже перемещение текста из другого файла, могут быть проигнорированы, чтобы намного проще добраться до автора оригинального кода.
Прежде чем обвинить кого-то, убедитесь, что вы проверили один из них:
|
1
2
3
|
git blame -w # ignores white space
git blame -M # ignores moving text
git blame -C # ignores moving text into other files
|
Найти строку во всей истории Git (и удалить ее)
Время от времени вам нужно искать строку кода, которую вы знаете, что написали, но не можете найти. Он может застрять в какой-то отдаленной ветке, удалить его давным-давно или спрятаться на простом участке; но в любом случае вы можете найти любую строку в вашей истории git, смешав несколько команд. Во-первых, мы собираемся получить список всех коммитов, а затем grep каждого из них для нашей строки.
|
1
|
git rev-list —all |
|
Возможно, у вас есть друг, который случайно отправил в хранилище конфиденциальные данные: ключи доступа, пароли, секретный рецепт маринары вашей бабушки. Первое, что они должны сделать, это изменить свои пароли и отозвать доступ с этими ключами (и извиниться перед своей бабушкой). Затем вам нужно выследить поврежденный файл и удалить его из всей истории git, что звучит намного проще, чем есть на самом деле. После завершения этого процесса у всех, кто извлечет очищенные изменения, также будут удалены конфиденциальные данные. Вилы вашего репо, которые не объединяют ваши исходные изменения, все равно будут содержать скомпрометированные файлы (поэтому не пропускайте изменение паролей и отзыв ключей доступа).
Сначала мы переписываем историю git для каждой ветви, удаляя файл с конфиденциальными данными.
|
1
|
git filter-branch —index-filter ‘git rm —cached —ignore-unmatch <FILENAME>’ —prune-empty —tag-name-filter cat — —all
|
Добавьте файл в .gitignore и .gitignore обновление .gitignore .
|
1
2
3
|
echo <FILENAME> >> .gitignore
git add .gitignore
git commit -m «Add sensitive <FILENAME> file to gitignore»
|
Поскольку мы переписываем историю, вам необходимо принудительно отправить изменения на ваш пульт.
|
1
|
git push origin master —force
|
Скомпрометированные файлы все еще существуют в вашем локальном репозитории, поэтому вам нужно выполнить несколько задач по очистке, чтобы полностью их очистить.
|
1
2
3
4
|
rm -rf .git/refs/original/
git reflog expire —expire=now —all
git gc —prune=now
git gc —aggressive —prune=now
|
В репо вашего друга не должно быть конфиденциальных данных, и вы станете героем, который поможет им с вашими знаниями. (через StackOverflow и GitHub )
Игнорировать изменения в отслеживаемом файле
Работа с чужим кодом в вашей среде может означать, что вам нужно внести любое количество изменений конфигурации, чтобы запустить приложение. Слишком легко случайно внести изменения в те конфиги, которые предназначались исключительно для вашей среды. Таким образом, вместо того, чтобы всегда следить за этими файлами и держать их в «измененной» области подготовки, вы можете просто указать git index игнорировать изменения в этом файле. Вы можете думать об этом как о файле git ignored, который остается с репо. (через Арно Кумана )
|
1
|
git update-index —assume-unchanged <FILENAME>
|
Обнулить историю филиала
Иногда начинать с нуля — это именно то, что вам нужно сделать по ряду причин. Возможно, вы унаследовали кодовую базу, которую вы не можете обеспечить безопасным открытием исходного кода, возможно, вы просто собираетесь попробовать что-то совершенно новое, или, возможно, вы добавляете ветку, которая служит отдельной цели, которую вы хотите поддерживать с помощью репо (как GitHub Pages). Для этого случая есть очень простой способ создать новую ветку в вашем репо, которая по существу не имеет истории. (через Никола Паолуччи )
|
1
|
git checkout —orphan <NEWBRANCH>
|
Псевдонимы, без которых вы не можете жить
Хватит тратить время на ввод длинных команд и сделайте себе несколько полезных псевдонимов.
Ни одно обсуждение git не будет полным, если не говорить о различных псевдонимах, которые буквально экономят ваши минуты в году при сохраненных нажатиях клавиш. Хватит тратить время на ввод длинных команд и сделайте себе несколько полезных псевдонимов. Псевдонимы можно сделать, добавив их в ваш файл .gitconfig или используя git config --global alias.<NAME> "<COMMAND>" из командной строки git config --global alias.<NAME> "<COMMAND>" . Ниже приведены примеры псевдонимов, которые вы можете использовать в качестве трамплина для идей.
co: с функциональным рабочим процессом ветки, вы будете регулярно перемещаться между ветками. Спасите себя шесть символов каждый раз.
|
1
|
co = checkout
|
ds: всегда рекомендуется проверять изменения, которые вы собираетесь зафиксировать, прежде чем делать фактическую фиксацию. Это позволяет выявлять опечатки, случайное включение конфиденциальных данных и группирование кода в логические группы. Поместите ваши изменения и затем используйте git ds чтобы увидеть разницу между этими изменениями.
|
1
|
ds = diff —staged
|
st: вы должны быть хорошо знакомы с подробным выводом статуса git. В какой-то момент вы захотите пропустить все формальности и приступить к делу. Этот псевдоним показывает краткую форму статуса и включает в себя подробности ветви.
|
1
|
st = status -sb
|
изменить: вы забыли включить файл с вашим последним коммитом, или, может быть, у вас был один твик, который вам нужно было сделать? Внесите изменения в ваш последний коммит.
|
1
|
amend = commit —amend -C HEAD
|
отменить: иногда, изменение вашего последнего коммита недостаточно, и вам нужно будет отменить его. Этот псевдоним сделает шаг назад на один коммит и оставит изменения от этого коммита в стадии подготовки. Теперь вы можете внести дополнительные изменения или подтвердить новое сообщение.
|
1
|
undo = reset —soft HEAD^
|
ls: работать над базой кода с группой разработчиков означает пытаться не отставать от того, над чем работают люди. Этот псевдоним будет содержать однострочный журнал git, включающий дату и имя коммиттера.
|
1
|
ls = log —pretty=format:»%C(yellow)%h %C(blue)%ad%C(red)%d %C(reset)%s%C(green) [%cn]» —decorate —date=short
|
standup: этот псевдоним отлично подходит для просмотра того, над чем вы работали вчера, для любого типа ежедневного режима ожидания или просто для того, чтобы освежить память по утрам.
|
1
|
standup = log —since ‘1 day ago’ —oneline —author <YOUREMAIL>
|
График: сложную историю мерзавцев может быть трудно рассмотреть по прямой линии. Использование флага графика показывает, как и когда коммиты были добавлены в текущую ветку.
|
1
|
graph = log —graph —pretty=format’:%C(yellow)%h%Cblue%d%Creset %s %C(white) %an, %ar%Creset’
|
В заключение
Git может быть как удивительно простым, так и невероятно сложным. Вы можете начать с основ и начать со временем более сложные манипуляции с графиками. Нет необходимости гробить все это, прежде чем вы сможете его использовать. Команда, которая будет самой мощной, как вы узнаете, это man git-<command>-<name> . Попробуйте использовать его, прежде чем обратиться к Google за ответом.
Вы можете узнать больше о том, как компания, для которой я работаю, New Relic , использует git в нашем блоге или попробовать New Relic Pro бесплатно . Спасибо за прочтение! Если у вас есть какие-либо вопросы, сообщите нам об этом ниже!