Pull to refresh
  • by relevance
  • by date
  • by rating

Кнопка слияния на GitHub (Merge)

Git
Translation
C «Запросами на пулл 2.0» стало легче, чем когда-либо, делать проверку кода и принимать патчи. Мы широко используем этот механизм на GitHub, и я люблю его применять в моих открытых проектах.

Взять, к примеру, запрос на пулл по исправлению документации в God:

image

Традиционно, это слияние запроса на пулл требует множество шагов с помощью командной строки Git. Но больше это не так!
Читать дальше →
Total votes 51: ↑49 and ↓2 +47
Views8.9K
Comments 10

Pull request'ы на GitHub или Как мне внести изменения в чужой проект

Git
Tutorial
По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:
Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»
Читать дальше, но теперь уже обо всём по порядку
Total votes 84: ↑80 and ↓4 +76
Views359.7K
Comments 31

Зачем пользователи GIT-а редактируют свои коммиты

Open sourceGit
В последних двух выпусках Радио-T ведущие пытались обсудить GIT. Евгений (@Umputun) задавался вопросом зачем нужен rebase и очень удивился, когда я спросил, редактирует ли он коммиты. На мой взгляд, чтоб понять GIT, достаточно вникнуть в процесс разработки Linux Kernel, т к создавался он именно для этого.
Читать дальше →
Total votes 113: ↑103 and ↓10 +93
Views55.8K
Comments 123

GitHub Flow: рабочий процесс Гитхаба

GitGitHub
Translation
Краткое предисловие переводчика.
Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow


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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба


Читать дальше →
Total votes 111: ↑105 and ↓6 +99
Views114.3K
Comments 47

Графики вклада с учётом часовых зон

GitHub
Translation
7 марта мы добавили ко графикам вашего вклада учёт часовых зон. GitHub используется повсеместно — и мы хотим, чтобы это отразилось в его возможностях. Если вам довелось работать из Японии, Австралии или Улан-Батора, мы хотим учитывать ваш вклад с вашей точки зрения.

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

Испортить вашу нынешнюю полосу продуктивной работы мы не хотим, так что учёт часовых зон начнётся только для вклада, совершённого после понедельника 10 марта 2014 года (Temps Universel Coordonné).

Желаем весело провести время (вашей зоны)!
Total votes 12: ↑9 and ↓3 +6
Views5.2K
Comments 3

Как писать отличные пулл-реквесты

Website developmentGitHub
Translation
С ростом компании, люди и проекты меняются. Для продолжения развития культуры, которую мы хотим иметь в GitHub, мы сочли полезным напомнить самим себе цели, которые преследуем в коммуникациях. Мы недавно представили эти гайдлайны, чтобы помочь самим себе быть лучше, когда мы взаимодействуем через пулл-реквесты.
Читать дальше →
Total votes 55: ↑46 and ↓9 +37
Views20.9K
Comments 10

Лучший Pull Request

Website developmentGitAtlassian
Sandbox
Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.
Читать дальше →
Total votes 46: ↑45 and ↓1 +44
Views43.6K
Comments 25

Как создать идеальный Pull Request

VoximplantWebsite developmentProgrammingGit
Translation
С ростом компании меняются люди и проекты. Не так давно в блоге GitHub появилась интересная статья, в которой автор рассказывает, как делать, а как лучше не делать Pull Request’ы. Перевод, традиционно, спрятан под катом.

Читать дальше →
Total votes 27: ↑26 and ↓1 +25
Views20.2K
Comments 11

Как изменение двух строк кода может занять несколько дней

Open sourceProgrammingJavaAmazon Web ServicesGitHub
Интересно верит ли кто-либо еще что работу разработчика можно измерить количеством строк кода? Попробуем вместе развенчать этот старый, как мир, миф своими красными глазами.


Сложно ли изменить две строчки кода?
Как прочувствовал это на своей шкуре...
Total votes 45: ↑37 and ↓8 +29
Views20.1K
Comments 44

Советы по стилю. Как написать читаемый React-код

СберJavaScriptProgrammingReactJS
Когда разработчик проводит code review, ему редко хватает времени вникнуть в каждую строку: приходится быстро продумывать различные ситуации, в которых этот код может не работать. При анализе существует несколько моментов, на которые стоит обращать внимание, чтобы быстро понять, как именно код работает. Подсмотрели у Nirmalya Ghosh несколько приемов, как сделать javascript-код изящнее при создании компонентов с помощью библиотеки React. Хотя у нас есть свои особенности разработки в ЕФС, о которых вы можете прочитать в этой статье, некоторые из описанных под катом приемов мы находим интересными. Читаем и обсуждаем в комментариях!


Читать дальше →
Total votes 15: ↑10 and ↓5 +5
Views8K
Comments 10

GitHub Pull Requests в Visual Studio Code

MicrosoftOpen sourceProgrammingVisual StudioGitHub
Translation
Как и во многих других проектах с открытым исходным кодом, в сообществе Visual Studio Code используются запросы на принятие изменений. С их помощью разработчики совместно исправляют ошибки и добавляют новые функции. Недавно мы обновили общедоступную пробную версию GitHub Pull Requests for Visual Studio Code, тем самым устранив проблему, с которой мы и миллионы разработчиков сталкиваемся каждый день: невозможность просматривать исходный код там, где он был написан, — в редакторе.

Читать дальше →
Total votes 30: ↑29 and ↓1 +28
Views13.4K
Comments 20

Применение расширяемых политик Pull Request в VSTS для поддержки процесса разработки

Visual StudioAPIMicrosoft AzureDevelopment ManagementDevOps
Tutorial

Часто в рамках проверки Pull Request, помимо, собственно, code review, возникает необходимость проделывать набор рутинных проверок. Некоторые проверки могут касаться оформления PR. Другие — проверять смежные условия, которые составляют основу процесса принятия изменений.
Если рутинные проверки не автоматизированы, человек может начать их забывать или обходить. Потому, что рутина — это скучно.


Visual Studio Team Services предлагает довольно удобную инфраструктуру для обработки Pull Request. Сюда входят настраиваемые политики merge builds, назначение ревьюеров, правила слияния принимаемых изменений. Все это дополненной удобной системой обсуждения и комментирования кода.


Мощнейшим инструментом расширения процесса Pull Request являются внешние подключаемые политики.


Об их создании и использовании и поговорим (и посмотрим код)

Читать дальше →
Total votes 4: ↑4 and ↓0 +4
Views1K
Comments 2

Как быстрее вливать пуллы в upstream?

Open sourceProgrammingGitHub
Друзья, сегодня я хочу рассказать вам про одну идею, которая давно поселилась в моей голове. Она возникла много лет назад и смысл её в том, чтобы сделать сервис, который бы аггрегировал и представлял в удобном виде все коммуникации, происходящие вокруг интересных вам GitHub проектов. Такой сервис будет в первую очень полезен тем, у кого много своих проектов на GitHub, или тем создаёт много пуллов и тикетов в чужих проектах.

Я верю в то, что люди, создающие тикеты и пуллы делают это ради того, чтобы улучшить те opensource проекты, которые им небезразличны. А для этого нужно, чтобы тикеты превращались в пуллы и пуллы своевременно мерджились. Чем быстрее будет происходить этот процесс, тем быстрее будет развиваться OpenSource.

Однако, на GitHub часто бывает, что коммуникация вокруг тикета или пулла затихает и теряется. Происходит это по разным причинам, но как правило — из-за того, что какой-то из участников пропускает email-отбивку о комментарии. Причины могут быть разные, а результат всегда один — тикет теряется и иногда проходят годы, прежде чем про него вспоминают.
Читать дальше →
Total votes 20: ↑18 and ↓2 +16
Views2.1K
Comments 22

Code review — улучшаем процесс

ProgrammingPerfect codeGitDebuggingDevelopment Management
Sandbox
image

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?
Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views9.4K
Comments 10

YouTrack теперь с просмотром пул-реквестов в задачах

JetBrainsDevelopment ManagementProject managementAgileProduct Management
Привет, Хабр!

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

image

За подробностями добро пожаловать в пост.
Читать дальше →
Total votes 13: ↑11 and ↓2 +9
Views2.7K
Comments 0

Когда твой код стал общим: история от дебюта до эндшпиля

WrikeProgrammingGitDartMicrosoft Azure


«Отстаньте от меня, пожалуйста, я — творец! Дайте мне творить!», — программист Геннадий уже третий раз за вечер проговаривает эту мантру у себя в голове. Тем не менее пока что он не написал ни одной строчки кода, потому что в библиотеку, которую пытается развивать, прилетел еще один пулл-реквест. А, согласно политике компании, ревью кода должно проходить с минимальными задержками. Теперь Геннадий думает, как поступить: не глядя принять изменения, так же не глядя их отклонить или все-таки потратить драгоценное время, чтобы разобраться в их сути. Ведь кто, кроме него? Он этот код написал, он за ним и будет следить. А все изменения возможны только через его персональное согласие, ведь это Библиотека Судного Дня. 
Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views3.1K
Comments 0