16 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

8 советов для более эффективной работы с Git

15 базовых советов по Git для эффективной работы каждый день

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git’ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

1. Используй свежее

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

2. Настрой инструмент

Настройте себе публичный email не аффилированный с текущей компанией. Это позволит вам тонко настраивать идентификацию под разные репозитории и не задумываться о настройках по умолчанию, а GitHub будет показывать вашу активность, даже если вы смените место работы.

Если вы не пользуетесь консолью и vim’ом для редактирования, то вам стоит настроить и ваш редактор:

3. Настрой autocomplete

В моей практике не часто встречается разработчик, который не настраивал автокомплит если работал в консоли. Однако если вы переходите с другого инструмента, отсутствие этой функциональности сильно вас затормозит.

Git из коробки предоставляет набор скриптов для автокомплита, но если ваш shell, как у меня, более экзотичен — найдите и поставьте автокомплит именно для него.

4. Ускоряй часто используемое

Настройте себе псевдонимы (aliases) для быстрой работы. Для каждого человека удобство ощущается по-разному и я не рекомендую увлекаться однобуквенными псевдонимами, особенно если вы часто работаете на других рабочих станциях или используете ssh для удалённой работы на серверах — вам либо придётся тратить время на борьбу с различиями, либо растаскивать свой файл настроек по всем машинам (что не всегда плохо, конечно). Также не старайтесь заменить псевдонимами любое сочетание команд — половину вы забудете, а к половине привыкните более, чем оно того заслуживает.

Я перешёл на Git с SVN, потому для меня базовые псевдонимы перекочевали оттуда, а “b” — единственный однобуквенный псевдоним.

5. Обзорность помогает решать проблемы

Я часто работаю с историей проекта — нужно понять, что и когда влилось, и какие состояния проекта этому предшествовали. Часто важно знать последовательность комитов и топологию дерева истории. Git из коробки помогает показать дерево истории проекта:

Но для полноты картины хочется видеть и авторов, и даты и в удобной расцветке, потому мой псевдоним выглядит не так дружелюбно с параметром –pretty=format: :

6. Следуй протоколу

Всегда клонируйте репозиторий, в который вносите правки по git+ssh протоколу, это работает быстрее чем по http и сэкономит время в процессе работы:

7. Разделяй источники

Если вы работаете с репозиториями по «форковой» модели (когда к основному репозиторию есть доступ только на чтение, а все pull-request’ы подаются из форка) называйте основной репозиторий upstream это поможет не путаться в командах отведения веток и push’а в свой origin . Не забывайте про протокол, если репозиторий открыт только для чтения, то его можно клонировать без ssh-слоя, что тоже даст экономию времени в процессе работы:

8. Контролируй процесс

Не используйте команду pull, это составная команда и делает несколько действий сразу. Часто при работе с репозиторием новички допускают ошибку не понимая, как эта команда обновляет текущую ветку, и замусоривают свою историю или неправильно работают с дефолтной веткой. Я рекомендую явно обновлять репозиторий локально, затем явно обновлять свою ветку:

9. Не вводи себя в заблуждение

Никогда не храните дефолтную ветку локально, всегда отводите ветку от актуальной удалённой, это позволит избежать путаницы и точно знать от чего и в какое время вы отвели ветку:

10. Не бойся исправлять

Если вы следите за чистотой истории и хотите исправить состояние проекта зафиксированное несколько комитов назад, то достаточно закомититься с параметром –fixup= и передать нужный хэш комита для последующего причёсывания истории

11. Не бойся быстро исправлять

Один из полезных псевдонимов — замена последнего комита текущим состоянием, позволяет «подклеить» текущее состояние к последнему зафиксированному, при этом не включая режим редактирования сообщения:

12. Перебазируй

Научитесь и пользуйтесь командой rebase в интерактивном режиме и с параметром –autosquash с которым использование –fixup будет ещё более удобным, а сам ребейз помогает причёсывать историю и аккуратно оформить комиты, например по принятым у вас guidline’ам, до подачи pull-request’а для успешного его принятия.

Читать еще:  Чумная колонна на улице Грабен в Вене

13. Сбрасывай ненужное

Научитесь и пользуйтесь командой reset она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью:

14. Контролируй деструктивный push

Если вы хотите запушить изменённую историю, советую использовать полный синаксис команды и не использовать ключ –force -f , это позволит не привыкать к настройкам по-умолчанию и не приведёт к случайным перетираниям истории на сервере:

15. Помни про летописца

Не забывайте про reflog эта команда поможет разобраться с проблемами в локальном репозитории если что-то пошло не так — спасательный круг для новичков, к которому они редко подходят:

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

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

7 советов по повышению продуктивности работы с Git

Перевод статьи «Become a Git Ninja: 7 Productivity Tips».

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

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

Автодополнение команд Git в терминале

Большинство команд, применяемых при испльзовании Git, начинаются с ключевого слова git, за которым следует пробел и второе ключевое слово. Поскольку между этими двумя командами есть промежуток, терминал воспринимает их как два разных слова, а при таких условиях обычное автодополнение при помощи клавиши Tab не работает (по умолчанию).

Git предоставляет специальный скрипт автодополнения; его нужно скачать, чтобы использовать этот функционал. Запустите следующую команду, чтобы скачать скрипт в вашу домашнюю директорию.

Затем добавьте следующие строки в файл .bash_profile в вашей домашней директории.

Этот код ищет скрипт автодополнения в вашей домашней директории и, если он там есть, запускает его при каждом вашем входе в bash.

Локальное удаление ветки в удаленном репозитории

Работа с ветками на удаленном репозитории может быть довольно трудоемкой задачей. Но удалить ветку на удаленном репозитории можно довольно быстро, для этого используется команда push. Мы предполагаем, что у вас есть право записи в удаленном репозитории.

Чтобы удалить ветку branch_name из удаленного репозитория remote_name, запустите следующую команду. Действовать нужно осторожно, потому что это действие отменить нельзя.

Запустив эту команду, вы, в сущности, делаете отправку (push) пустой ветки в branch_name и таким образом полностью удаляете branch_name из remote_name.

Безопасный принудительный push

Если вы переместили коммиты в своей локальной ветке или как-то еще изменили историю, ваш push в удаленный репозиторий будет отклонен. Обойти это можно, добавив к команде опцию —force, в результате чего будет перезаписана история удаленной ветки. Но это опасная процедура, поскольку со времени вашего последнего pull-а кто-то другой мог сделать коммит, а при таком подходе вы его перезапишете.

Более безопасный способ использования принудительного push это добавление опции —force-with-lease. Если с тех пор как вы последний раз забирали изменения из удаленного репозитория никто другой не вносил никаких новых изменений, эта команда будет действовать так же, как и с опцией —force. Но во всех других случаях ваш push будет отклонен. Отклоненный push даст вам понять, что, прежде чем снова пытаться отсылать ваши изменения, вам нужно обновить вашу локальную ветку (чтобы привести ее в соответствие с удаленной).

Отмена изменений в Git

Иногда случается, что вам нужно внести изменения в какие-то уже осуществленные операции. Здесь мы поговорим об отмене изменений трех видов: отслеживания файла, индексации изменений и создания коммита.

Чтобы отменить процесс отслеживания файла при помощи Git, выполните следующую команду:

Чтобы отменить изменения, внесенные в файл после последнего коммита, и проиндексированные, запустите команду:

Эта команда восстанавливает состояние файла staged_file по указателю HEAD, который указывает на последний коммит. А если вы уже успели сделать commit своих изменений, следующая команда поможет вам вернуться на предыдущую стадию.

Эта команда возвращает состояние репозитория на N коммитов до HEAD. Все изменения будут проиндексированы, то есть, эта команда не затронет изменения в ваших файлах. Сбрасывая коммит, вы будете возвращать назад состояние всего репозитория, сделать это для отдельного файла не получится.

Читать еще:  Руководство: Thymeleaf + Spring. Часть 3

Сохранение незафиксированных изменений при помощи «тайников»

Представьте, что вы работаете над новой фичей, и вдруг заходит босс и спрашивает о прогрессе предыдущей задачи. Ваша текущая фича не закончена, так что создавать коммит будет не логично. Что же делать?

Поможет вам git stash. Следующая команда сохраняет («прячет», англ stash — «прятать, утаивать, тайник») все незавершенные изменения и возвращается к состоянию репозитория на момент последнего коммита.

Когда захотите вновь вернуться к работе над своей фичей, используйте следующую команду, чтобы просмотреть все «тайники».

Вы увидите список всех сохраненных тайников с метками времени. При помощи следующей команды можно применить N-й тайник из списка.

Коммит отдельных изменений в файле

Что, если вы внесли в файл много разных изменений, но хотите, чтобы они были зафиксированы в разных коммитах? Обычная команда git add проиндексировала бы все изменения в файле, но если вы добавите опцию -р, вы запустите wizard, позволяющий проиндексировать изменения в файле выборочным образом.

Работа с большими файлами при помощи Git LFS

Хотя Git хорошо справляется с текстовыми файлами, ему не удается эффективно работать с бинарными. Примерами таких файлов могут послужить документы Excel, проекты Photoshop и прочие исполняемые файлы.

Здесь вам поможет Git LFS. Это расширение Git с открытым исходным кодом. Для работы с большими бинарными файлами оно заменяет эти файлы на текстовые указатели внутри Git, а содержимое файлов сохраняется на удаленном сервере. Таким образом вы сможете эффективно управлять репозиторием, а большими бинарными файлами (при внесении в них изменений) будет заниматься удаленный сервер.

Скачав и установив Git LFS в свою локальную систему, инициализируйте его для каждого репозитория при помощи следующей команды.

Чтобы отслеживать файлы определенного типа (скажем, PSD), запустите следующую команду:

Вы можете отслеживать и другие файлы, отредактировав файл .gitattributes.

Бонусный совет: отладка при помощи Git

Поскольку вы дотянули до конца статьи, вот вам бонусный совет!

Вы знаете, что Git — весьма полезный инструмент при дебаггинге вашей кодовой базы? Git Blame позволяет анализировать историю файла, а команда Bisect инициирует бинарный поиск по вашим коммитам. Узнать больше об этих командах можно здесь.

Итоги

Вот мы и подошли к концу нашего списка. Мы рассмотрели семь советов (плюс бонусный), следование которым поможет вам повысить эффективность работы с Git. Внедрите эти команды в свой рабочий процесс и пользуйтесь всеми преимуществами, которые они дают.

Начинаем работать с git — пошаговая инструкция

Первые шаги в освоении мира компьютерных технологий пройдены, ты знаешь, зачем сюда пришёл, к чему стремишься, и как этого добиться, упорно учишься, переходя от курса к курсу. За спиной первые написанные программы и отловленные баги, а впереди маячат светлые перспективы коммерческой разработки программного обеспечения.

Наверное, пора узнать…

Секреты командной разработки

Разработка – это почти всегда командная игра. Пора учиться работать в команде.
Даже если пока что в твоей команде только монитор, системник (или старенький ноутбук) и острое желание стать программистом, всё равно пора учиться.

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

Чтобы эффективно работать в команде, мало знать синтаксис языка, ключевые библиотеки и уметь обращаться с базами данных. Необходимо уметь работать в удобной для команды системе контроля версий.

О системах контроля версий их преимуществах и недостатках можно почитать здесь.
В этой статье мы перейдём от теории к практике и расскажем, как работать с git’ом.

Шаг 1. Выбираем git-хостинг

Git-хостинг на разных условиях предлагают десятки компаний.
Самые известные из них: Github, Sourceforge, Google Code, GitLab, Codebase. Выбери удобный интерфейс и регистрируйся на понравившемся хостинге.
В этой статье мы рассмотрим работу с git-хостингом на примере Github’а.

Шаг 2. Регистрация

Процедура регистрации на Гитхабе простая и интуитивно понятная даже для тех, чей уровень английского далёк от Upper Intermediate.

Логин, пароль, почта –> подтверждение, и связь с мировым сообществом программистов налажена.

Шаг 3. Создание репозитория

Ты можешь создать любое количество репозиториев, у каждого из которых будет issue tracking, wiki, условия для проведения code review и многое другое.
Политика разработчиков Github предполагает бесплатное использование хостинга для всех open-source проектов.

Чтобы создать новый репозиторий нажмём кнопку + в верхней части экрана и выберем New repository

Создание репозитория на Гитхабе




Многие разработчики рано или поздно сталкиваются с необходимостью создания приватного репозитория, код из которого доступен только их команде. Для этих случаев на Github’е есть определённый тарифный план.

Читать еще:  Читаем XML файл на Java с помощью JDOM Parser

Но пока острой необходимости в создании приватного репозитория у нас нет, создадим обычный.


Жмём волшебную кнопку Create внизу экрана, и репозиторий готов.

Шаг 4. Работа с репозиторием

Работа с репозиторием может вестись из командной строки, напрямую из среды разработки или из графического интерфейса (git — клиент приложения).

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

Шаг 5. Выбираем Гит-клиент

Потом, когда суть процессов изменения и обновления (восстановления) информации в репозитории станет для Вас очевидна, можно работать и через командную строку. В этом принципе работы есть немало своих преимуществ. Например, все новые опции Гитхаба реализуются сначала для использования в командной строке, и только потом адаптируются под графические интерфейсы.

Но вернёмся к git-клиентам.

Самыми популярными гит- клиентами на данный момент являются:

SmartGit


Удобное приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.

GitHub Desktop

«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.

Зато отлично подходит для начала работы с git.

GitKraken


Поддерживает GitHub, Bitbucket и Gitlab.
Кракен очень любят программисты – фрилансеры, которым периодически приходится менять команды, а значит, и условия командной разработки. Возможность работы с разными git-хостингами через привычное приложение со знакомым интерфейсом в таких случаях играет важную роль.

SourceTree

SourceTree позволяет работать с Bitbucket и GitHub. В приложении довольно простой интерфейс, подходящий, как для опытных программистов, так и для новичков.

Шаг 6. Работа со SmartGit


В этой статье мы рассмотрим работу с SmartGit.

Скачать SmartGit можно, например, отсюда:
Устанавливаем и запускаем.

Основные операции для работы с git


Clone


Первое, чему стоит научиться – это снимать копию проекта из удалённого репозитория в локальный.
Делается это довольно просто:

Clone


Затем копируем ссылку репозитория, созданного на Гитхабе (шаг 2)

Ссылка на репозиторий


Вставляем адрес удалённого репозитория в нужную ячейку в открывшемся окне, выбираем расположение нового локального репозитория у нас на компьютере, и получаем готовый локальный репозиторий.

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

Commit

Репозиторий готов – пора приступать к работе.
Написанный код мы помещаем в локальный репозиторий — папку .git (путь к которой мы указали в операции clone).

Добавление файла в локальный репозиторий


Если всё прошло успешно, в окошке SmartGit’а появится скопированный файл.

Новый файл в SmartGit



Для того чтобы зафиксировать изменения в локальном репозитории, нажимаем кнопку Commit.

Commit

В открывшемся окне пишем пояснительный комментарий к сохраняемому файлу и снова нажимаем кнопку Commit

Пояснения к Commit’у



Файл сохранён, а изменения внесены в журнал.

Файл отправлен в локальный репозиторий

Теперь заглянем на Github.com в наш удалённый репозиторий. Там до сих пор нет ни одного файла. Нужно срочно менять ситуацию.
Чтобы перенести изменения, внесённые в локальный репозиторий, в удалённый репозиторий, необходимо нажать кнопку Push.

Push



К слову, отправить изменения в удалённый репозиторий, нам предлагают ещё в точке Commit’а

Commit & Push


Возникает резонный вопрос: как получат изменения остальные участники разработки, если они клонировали проект в самом начале?
Для этого существует команда Pull, передающая в локальный репозиторий все изменения, происходящие в удалённом.

Pull



К слову, для командной разработки на Гитхабе есть ещё несколько важных опций.

Перенос информации из сторонних репозиториев на Гитхаб

Когда нужно собрать разрозненные кусочки кода в один проект, используйте кнопку Import repository и работайте с файлами в удобном репозитории Гитхаба.

Импортировать репозиторий

Кнопка New gist на этой панели предназначена для мгновенного обмена информацией.

А кнопка New organization открывает массу возможностей для командной разработки.

Заключение

О git’е можно писать ещё долго, подробно рассматривая возможные конфликты, создание и слияние деревьев, работу с ветками, но для начала эффективной работы достаточно знания основных команд и острого желания стать программистом.

Благодаря своей политике (поддержка open-sourse проектов) Github предоставляет удивительную возможность детально рассматривать программы, написанные как новичками, так и признанными гениями – программистами.

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

голоса
Рейтинг статьи
Ссылка на основную публикацию
Статьи c упоминанием слов: