Выполнение запроса pull

Как работать с запросами на фичи?

Для начала важно понять, что все фичреквесты разные. Их можно разделить на три основных типа:

1. Проблемы с существующими фичами. Пользователь столкнулся с технической проблемой и не понимает, как сдвинуться с мертвой точки;
2. Доработка фичей. Пользователь не знает, как достичь определенного результата с помощью продукта;
3. Запросы на новые фичи. Пользователь просит добавить что-то, чего раньше не было в продукте.

Давайте разберем более подробно. 

1. Проблемы с существующими фичами.

Идеальных продуктов не существует. Наверняка в вашем сервисе что-то не работает так, как нужно. Возможно, некоторые пользователи даже пишут: ”Фича, на которую я рассчитываю (и за которую плачу!) сломалась. Мне срочно нужна ваша помощь.” Конечно, можно просто отправить ошибку в Github и перейти к следующему диалогу, но мы считаем, что команда поддержки должна уметь показывать клиентам, как достичь результата, даже при наличии технических ограничений. 

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

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

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

2. Исправления фичей.

Другой распространенный сценарий – просьба добавить новую функциональность в ваш сервис. Служба поддержки будет первым местом, куда обратится пользователь с такой проблемой. 

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

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

3. Запросы новых фичей. 

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

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

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

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

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

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

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

Создаём Pull Request

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

Чтобы создать Pull Request, зайдём на страницу вашего форка. Справа от
выпадающего меню с выбором ветки есть кнопкаNew pull request».

Нажимаем её.

Вы попадаете в окно сравнения веток.

Вот элементы этого окна,по порядку:

1. Базовый репозиторий,в который будет создаваться PR. Это должен быть
   репозиторий,от которого вы делали форк. Если вы форкнули проект
   , а ваше имя пользователя GitHub — , то у вас
   будет проект .
2. Базовая ветка в этом репозитории,обычно .
3. Репозиторий,откуда должны вливаться изменения. Здесь должен быть выбран
   репозиторий в вашем аккаунте — .
4. Ветка,откуда будут вливаться изменения. Это должна быть ветка,которую мы
   создали в разделеСоздаём ветку».

Дальше просмотрите изменения — то ли это,что вы делали? Если да,то нажимайте
кнопкуCreate pull request». В моём примере её нет,т. к. ветки в форке и в
оригинале находятся в одинаковом состоянии. В вашем же случае внизу будет список
коммитов,которые попадут в исходный репозиторий,и,на других вкладках — сами
изменения и комментарии к изменениям.

После нажатия кнопки появится окно ввода сообщения Pull Request.

Сообщение PR — это описание того,что сделано и зачем. В отличие от сообщения
коммита,здесь уже нужно писать высокоуровневое описание того,какие изменения
сделаны. В частизачем», а также по формату самого сообщения — стоит
придерживаться тех же правил,что и в случае с коммитами. Короткий заголовок
(Title), в Comment — описание,а затем служебная информация().
Если вы писали команды закрытия задач в коммитах,здесь можно их не дублировать.
Если нет — напишите здесь.

Затем нажимаемCreate pull request». Он создаётся,о нём приходит уведомление
людям,поддерживающим проект,и он становится виден в исходном репозитории на
вкладкеPull requests». С этого момента начинается рецензирование изменений
(code review).

Подсказка: если сразу после того,как вы отправили ветку в свой репозиторий
() зайти на страницу репозитория,там будет предложение создать
Pull Request на вливание недавно отправленной ветки в master. Сделать это можно
как в вашем форке,так и в исходном репозитории. Это будет отдельная кнопка
вверху,и при её нажатии в качестве ветки для слияния будет указана та,куда вы
делали .

How it works

Pull requests can be used in conjunction with the Feature Branch Workflow, the Gitflow Workflow, or the Forking Workflow. But a pull request requires either two distinct branches or two distinct repositories, so they will not work with the Centralized Workflow. Using pull requests with each of these workflows is slightly different, but the general process is as follows:

1. A developer creates the feature in a dedicated branch in their local repo.

2. The developer pushes the branch to a public Bitbucket repository.

3. The developer files a pull request via Bitbucket.

4. The rest of the team reviews the code, discusses it, and alters it.

5. The project maintainer merges the feature into the official repository and closes the pull request.

The rest of this section describes how pull requests can be leveraged against different collaboration workflows.

Feature Branch Workflow With Pull Requests

The Feature Branch Workflow uses a shared Bitbucket repository for managing collaboration, and developers create features in isolated branches. But, instead of immediately merging them into , developers should open a pull request to initiate a discussion around the feature before it gets integrated into the main codebase.

There is only one public repository in the Feature Branch Workflow, so the pull request’s destination repository and the source repository will always be the same. Typically, the developer will specify their feature branch as the source branch and the branch as the destination branch.

After receiving the pull request, the project maintainer has to decide what to do. If the feature is ready to go, they can simply merge it into and close the pull request. But, if there are problems with the proposed changes, they can post feedback in the pull request. Follow-up commits will show up right next to the relevant comments.

It’s also possible to file a pull request for a feature that is incomplete. For example, if a developer is having trouble implementing a particular requirement, they can file a pull request containing their work-in-progress. Other developers can then provide suggestions inside of the pull request, or even fix the problem themselves with additional commits.

Gitflow Workflow With Pull Requests

The Gitflow Workflow is similar to the Feature Branch Workflow, but defines a strict branching model designed around the project release. Adding pull requests to the Gitflow Workflow gives developers a convenient place to talk about a release branch or a maintenance branch while they’re working on it.

The mechanics of pull requests in the Gitflow Workflow are the exact same as the previous section: a developer simply files a pull request when a feature, release, or hotfix branch needs to be reviewed, and the rest of the team will be notified via Bitbucket.

Features are generally merged into the branch, while release and hotfix branches are merged into both and . Pull requests can be used to formally manage all of these merges.

Forking Workflow With Pull Requests

In the Forking Workflow, a developer pushes a completed feature to their own public repository instead of a shared one. After that, they file a pull request to let the project maintainer know that it’s ready for review.

The notification aspect of pull requests is particularly useful in this workflow because the project maintainer has no way of knowing when another developer has added commits to their Bitbucket repository.

Since each developer has their own public repository, the pull request’s source repository will differ from its destination repository. The source repository is the developer’s public repository and the source branch is the one that contains the proposed changes. If the developer is trying to merge the feature into the main codebase, then the destination repository is the official project and the destination branch is .

Pull requests can also be used to collaborate with other developers outside of the official project. For example, if a developer was working on a feature with a teammate, they could file a pull request using the teammate’s Bitbucket repository for the destination instead of the official project. They would then use the same feature branch for the source and destination branches.

The two developers could discuss and develop the feature inside of the pull request. When they’re done, one of them would file another pull request asking to merge the feature into the official master branch. This kind of flexibility makes pull requests very powerful collaboration tool in the Forking workflow.

Для чего нужен

О том, что такое реквест, уже было сказано выше, теперь речь пойдет о том, зачем он нужен, если никаких плюсов с точки зрения практичного человека он не приносит. Но это только на первый взгляд. Занимаясь перерисовкой изображения в своем стиле, можно отточить собственные навыки, найти заказчика и многое другое. Те люди, которые работают не покладая рук над иллюстрацией книг и комиксов, оформляют страницы сайтов в интернете, нуждаются в таком своеобразном отдыхе. И вправду, профи, которые сутками напролет рисуют одно и то же, или те, кто не может продумать все детали произведения, те, кому нужно отвлечься, но не потерять вдохновения, — именно они отдают предпочтение и отводят свободное время на исполнение реквестов.

В чем минус? Тут все просто: так называемых халявщиков хватает, особенно в интернете. С недавних пор стало популярным ставить на место главной фотографии в профиле и дарить на день рождения портреты людей. А кто будет их писать? Правильно, художники, и желательно, за простое «спасибо», а то и без него. Самое неприятное, что такие люди обычно оперируют либо «легкостью» создания полноценного изображения, либо получением «бесценного» опыта, но про то, чтобы оформить полноценный заказ, мало кто думает.

Отправляем изменения

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

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

Перед тем как сделать запрос вы имеете возможность добавить комментарий,
просмотреть то, какие файлы будут изменены, какие коммиты добавлены.
В верхнем углу окна добавления запроса обратите внимание откуда куда и что
вы сливаете. Если необходимо слить основные ветки выбор падёт на репозиторий
, если отдельную ветку (вспоминаем branch) — так и указывайте её

А дальше… ждать. Пока придёт владелец оригинального репозитория и
примет/отклонит ваши изменения.

Ну вот, мы его достигли. Просветления то есть 🙂

Участвуем в Code Review

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

Со стороны автора Pull Request(а раз вы читаете это руководство,вы наверняка
автор) требуется с пониманием относиться к комментариям рецензента — они
направлены на повышение качества проекта. Если ошибка в сборке выявляется в
процессе рецензирования,это гораздо лучше,чем если она попадёт в репозиторий,
а следующий человек,который попытается поучаствовать в проекте,не сможет этого
сделать из-за той самой ошибки. Да и это касается не только сборки,разумеется.

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

Если кто-то ведёт себя неадекватно — не медлите. Сначала сообщите об этом
собеседнику и призовите его к благоразумию. Если не сработало — смело
обращайтесь к рецензенту или к автору данного текста(Панкову Михаилу —
@mkpankov). Это можно сделать в нашем чате.

Пожелание относительно процесса рецензирования — постарайтесь не сильно
затягивать с ответами на комментарии или изменением указанных вещей.

Почему это важно? Автор PR хорошо разбирается в том,что он сделал,а если
процесс затягивается на недели и месяцы,высока вероятность,что или автор,или
рецензент отвлекутся на другие вещи,а обратный вход в контекст изменений тоже
стоит усилий и времени.Другие вещи» здесь — это вся остальная жизнь человека.
Может на работе аврал,может личные проблемы,может заболел. В итоге может
получиться так,что ваш PR навеки повиснет в неготовом состоянии и так и не
будет влит

Конечно,нам бы этого не хотелось.

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

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

По мере того,как самые заметные вещи
исправляют,внимание уделяется менее заметным — это нормально

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

Когда этот этап завершается,рецензент нажимает кнопкуMerge Pull Request».
Ваши изменения влиты в основной репозиторий проекта.

Поздравляем! Теперь вы полноправный участник проекта.

хочу трейд\коллаб / Блог рисунков на заказ (коммишны) / Табун

Saturn_Z в Общеличный блог

Tumblr выпилит клопоту 17 декабря 190

Star_Dust в IRL Connection

RuBronyCon’18 большой фотоотчет с 2-ух дней 3

redhattim в Я рисую обоими копытами

Иллюстрации и скетчи к Сломанной игрушке (часть 3) 6

SDreamExplorerS в Музыка и ремиксы

Antares_89 в Гильдия переводчиков — Переводы комиксов и блогов

Спроси Пинки Пай и Торнадо 3 35

Brummbar в Я рисую обоими копытами

Дальняя дорога 8

ovnd в Киноблог Табуна

Личное мнение о ‘Робин Гуде: Начало» 1

Dany в Гильдия переводчиков — Переводы комиксов и блогов

Два моих любимых персонажа в одном комиксе /)^3^(\ 41

partizan150 в Эквестрийская Пустошь

Fallout Equestria: Атака мертвецов 8

Carolus_Mrax в IRL Connection

Как синий як на свой первый РБК в холодную Москву летал 22

ksunika в Табун стримит стримы

Стрим Sally Face: Эпизод 4 от MintMouse 05.12.2018 1

Sakrit в Общеличный блог

Позвони своей кобылке|добавлены записи разговоров 31

Trigger в Эквестрийская Пустошь

FoE:Remains 0.7 541

S_RodRigueZ в IRL Connection

О RuBronyCon 2018 со стороны Сомбры 21

INFERION в Музыка и ремиксы

Courage (Hope and Chances) — Rusty 1

Sakrit в Я рисую обоими копытами

Кривенькая Твай 2

Sakrit в Общеличный блог

Уютная литконфа… 81

shadowiq в Табун стримит стримы

Стримузня №1 11

DarkKnight в Блог Издателей Табуна

Сломанная Игрушка. Тираж 2018, новости 71

kito в Блог им. chaorace

Как можно относиться к смерти близких? 28

Ревью мерж-реквестов

(PREMIUM, ULTIMATE, SILVER, GOLD)

Ревью кода в мерж-реквестах — мощная фича GitLab. Члены команды ведут обсуждения, привязанные к конкретным строчкам кода в диффе, и даже могут их решать. Тем не менее, этот процесс может стать затруднительным в мерж-реквестах с большими диффами. Часто ревьюверу приходится оставлять 10 или более комментариев в одном обсуждении, и 9-ый или 10-ый комментарий могут сделать предыдущие комментарии ненужными. В итоге автор мерж-реквеста получает массу уведомлений, и ему приходится разбираться со всеми.

В этом релизе мы представляем Ревью мерж-реквестов. Это позволит ревьюверу писать в черновик столько комментариев, сколько ему нужно, убедиться, что они все необходимы, и затем отправить их одним действием. Так как черновики сохраняются в GitLab, ревьювер может разделить свою работу на несколько сессий, например, начать ревью на своем десктопе на работе и закончить вечером дома на планшете. Когда эти черновые комментарии отправляются, они отображаются как обычные отдельные комментарии. Это даст отдельным членам команды возможность проводить ревью кода так, как им удобно, но все еще вместе со всей командой.

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

Документация по обсуждениям и оригинальный тикет.

Значение слова

Вы заказываете мастеру арт, т. е. оставляете ему запрос на выполнение рисунка. Можно написать ему сообщение или оставить комментарий под его публикацией с просьбой нарисовать конкретный рисунок: «Мне нравятся Ваши пейзажи. Нарисуйте, пожалуйста, рассвет над океаном».

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

Некоторые художники сами предлагают своей аудитории бесплатно создать для них работу: «Ребята, что советуете нарисовать?». Они проводят конкурсы предложений, затем выбирают лучшую идею дл осуществления. Мастера выполняют запросы в удобное для них время и часто находят это полезным для собственных целей.

Портрет по просьбе

Как отменить изменения

Если что-то пошло совсем не так как хотелось, изменения можно «откатить».
Когда изменённый файл ещё не проиндексирован, сделать это просто:

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

Cмотрим на какой коммит откатиться. В примере откатываемся назад на 1 коммит.
Для изменения состояния в этой же ветке удалённого репозитория тоже придётся
использовать грубую силу — флаг :

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

Дословно можно понимать эту команду как «из коммита 4b9df4bbd вернуть files».
Затем останется только зафиксировать изменения (сделать коммит).

Кстати, git log очень полезная команда, её изучению определённо стоит уделить время.
Например, полезно знать, что при помощи флага мы можем получить список всех
коммитов, в которых менялась строка, а соответственно и имя автора коммита.

Или посмотреть все изменения, которые происходили с отдельным файлом:

Последний пример покажет как стереть историю коммитов (фактически удалить и запушить с флагом ):

Запрос код-ревью

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

“Но разве это не идет вразрез с целью по сохранению чистой истории коммитов?”

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

Допустим, вы открыли пулл-реквест через эти коммиты:

Псевдо-коммиты для демонстрационных целей (ради простоты использования); на самом деле не стоит нумеровать свои сообщения о коммитах.

Затем ревьюер оставляет комментарий к чему-то, что было связано с изменениями, которые вносит первый коммит. Если вы модифицируете этот коммит и принудительно сделаете push, ваши старые коммиты исчезнут из пулл-реквеста, и все коммиты, начиная с тех, которые были ребазированы, появятся в качестве новых коммитов после этого ревью:

Все коммиты отображаются как новые

Что изменилось с тех пор, как ревьюер в последний раз смотрел на пулл-реквест?Какие коммиты были модифицированы и поэтому требуют внимания, а какие нет и могут быть пропущены?

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

Если вы попытаетесь нажать на файл, который был прокомментирован, чтобы увидеть, отвечали ли на этот комментарий, или получить больше контекста для кода в окрестностях комментария, вас встретит вот такой очаровательный телескоп:

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

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

Можете сказать, что тут нового?

Вам все еще следует ребазировать из ветки master, но до тех пор, пока в коммиты, которые уже были просмотрены, не вносится значимых модификаций. Тогда ревьюерам не нужно будет просматривать их все снова. Рассмотрите возможность после принудительного push добавить комментарий со ссылкой на самый последний просмотренный коммит, чтобы ревьюеры могли продолжить с того места, где остановились.

Как лучше делать ревью пул-реквестов

Не одобряйте PR вслепую

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

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

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

Будьте вежливы и сначала
спрашивайте

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

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

1. «Разбей этот метод на три метода
   поменьше».
2. «Если ты разобьешь этот метод на
   три метода поменьше, это повысит
   читабельность кода».

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

Используйте отрывки кода

Когда я начинал делать ревью кода, я
часто писал что-то вроде «Это можно
упростить», «Здесь можно использовать
библиотеку lodash» и т. п. Но автор кода,
получавший такие советы, не был уверен
в том, что я имел в виду, и не знал, как
это применить на практике.

Со временем я заменил сообщения общего
характера на отрывки кода. Это занимает
больше времени, но вместе с тем позволяет
с легкостью сравнить существующий код
с предлагаемыми улучшениями и увидеть,
стоит ли их применять. Прилагаемый
сниппет может не быть на 100% аккуратным,
его цель – более понятно преподнести
информацию автору кода.

Конечно, это лишь совет, а не жесткое
правило. Если вы чувствуете, что чей-то
код тяжело читать, вы можете передать
свои ощущения разными способами. Иногда
бывает достаточно просто высказать
сомнение насчет сложности кода. Это
может помочь автору заметить проблему
и самостоятельно исправить код.

Делайте ревью кода, даже если
вы новый человек в команде

Часто новички не уверены, чьи пул-реквесты
они могут ревьюить, и когда они вообще
могут начинать делать PR-ревью. В каждой
команде могут быть свои соглашения
насчет того, когда человек может
«одобрять» пул-реквесты, но начинать
читать и комментировать их нужно сразу.
Вы можете даже задавать общие вопросы
автору насчет кода проекта и таким
образом перенимать лучшие подходы.

Мердж-коммит в PhpStorm

PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий.
Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант:
как подтянуть новые коммиты, с мерждем или ребейзом.
Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

Внимание

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

Что могу посоветовать

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

Но при работе в команде имеет смысл подумать над такими вещами:

• пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
• пулиться почаще — обратная ситуация, почаще получать свежие изменения
• всегда пультесь с флажком ребейза — git pull —rebase origin master
• не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
• не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
• больше практикуйтесь. Посадите домашний проект на git и работайте с ним

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

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними.
Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 7. Ветки — главная фишка git

⇦ Предыдущий урок
Урок 5. История коммитов, git log

git push rejected

Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое

Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?

Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера.
Те самые, которые успели сделать наши коллеги. То есть сделать git pull.

Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected.
Значит, нам нужно сначала сделать git pull, а затем снова запушить

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

Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git».
Это так называемый мердж-коммит, о нем чуть ниже.

Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.

Завершение работы

После вливания PR нужно прибраться в репозитории. Если ваши изменения
самодостаточны и после PR не требуется продолжать работу дальше,стоит удалить
ветку. Как вы помните,мы создали её раньше,чтобы удобнее управлять
изменениями.

Но сначала лучше обновить вашу локальную master-ветку — тогда убедится,
что ваша ветка уже влита в , и не будет предупреждать,что вы можете
потерять свои изменения.

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

1

git remote add upstream https://github.com/ruRust/rustycrate.ru.git

URL в конце — это URL того репозитория,который вы форкнули.(На всякий случай —
он написан в небольшом поле справа от переключателяHTTPS-SSH», правее зелёной
кнопкиNew pull request».)

Добавив его,можно обновить наш локальный :

1
2

git checkout master
git pull --rebase upstream/master

А теперь можно удалить нашу ветку локально:

1

git branch -d fix-protobaz

и на сервере:

1

git push --delete origin fix-protobaz

Теперь у нас чистый,обновлённый репозиторий. Можно начинать работу над новым
PR.

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

Если в какой-то момент возникают ошибки — сделайте . Очень
часто сам подсказывает,что можно сделать и как это сделать.
Если всё равно не получилось — обращайтесь в чат,поможем.

После этой публикации остаются неотвеченные вопросы: как поступать,если
случайно закоммитил не в ту ветку; что делать,если кажется,что потерял
ваши изменения; как работать с сервисом code review ; как
рецензировать чужие изменения и,возможно,другие.

С этими вопросами можно обращаться в чат,а в будущем мы постараемся написать
руководства и по этим темам.

Хороших вам коммитов,пусть проект собирается и тесты проходят.
Присылайте ваши Pull
Request’ы!