LINUX.ORG.RU
ФорумTalks

Почему взлетел GitHub?

 , , , ,


0

1

Выделил в отдельный тред обсуждение консольного клиента GitHub:

www.linux.org.ru/forum/talks/16499288?cid=16499698

Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал? Мне не устраивают сказки про «DVCS намного лучше централизированной репы», потому что большинство пользователей Git/GitHub используют его как централизированный репозиторий и сам GitHub развивался именно как централизированный хостинг.

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab. Причем, именно в таком ключе продолжает развивать эту инициативу Microsoft, ныне владеющий GitHub: дополнительные инструменты в виде виртуальной файловой системы для online-only работы с центральным сервером, при этом сохранение совместимости с консольными клиентом GitHub-а.

★★★★

Последнее исправление: byko3y (всего исправлений: 1)

Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал?

Потому что это стало очень удобным и перенесло DVCS в Web, развило концепцию социального кодинга.

Вот мы и дожили до момента, когда удобнее залезть на GitHub, вбить в поиске у проекта название какой-то функции и быстро посмотреть нужный контекст, чем запускать IDE или «грепать» по директориям на локальной тачке.

EXL ★★★★★
()

Хм-м-м, действительно, четыре месяца назад переехали на Git.

А раньше они на чём были? Давно уже на Git’е пылится этот .NET Core, несколько лет точно.

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

Именно так: UNIX-style разработки победил Windows-style, кроме такого вот активного перехода на Git, в современном Windows появился ещё WSL и WSL2.

Developers! Developers! Developers! Стали всё чаще и чаще выбирать UNIX-like окружения, и переход на Git, как и WSL/WSL2 весьма мудрый ответ Microsoft на эту ситуацию.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Потому что это стало очень удобным и перенесло DVCS в Web, развило концепцию социального кодинга

А типа у нас социального кодинга до GitHub небыло почти, что ли? И я еще раз подчеркиваю, что это ни разу не DVCS, а вполне себе централизированный репозиторий — но с отдельными плюшками для оффлайна, и с простым инструментом для бэкапа/копирования всего репозитория и переноса на другой централизированный сервер.

Вот мы и дожили до момента, когда удобнее залезть на GitHub, вбить в поиске у проекта название какой-то функции и быстро посмотреть нужный контекст, чем запускать IDE или «грепать» по директориям на локальной тачке

Уникальны ли они? Не думаю:

https://elixir.bootlin.com/linux/latest/source

Хорош ли UX у GitHub в целом? Очень спорно. Отдельные фичи хороши, многие фичи ужасны, как то просмотр истории.

byko3y ★★★★
() автор топика

GitHub

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

goingUp ★★★★★
()
Ответ на: комментарий от byko3y

А типа у нас социального кодинга до GitHub небыло почти, что ли?

Не было. Был поганый до сих пор SourceForge, который что тогда, что сейчас рассылает вирусы и рекламу вместо ПО.

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

А ещё раз подчеркну, что именно DVCS и раскрылось в полную силу в таких местах, как GitHub, где пользователи могли форкать проект, форкать форки и вносить в них различные изменения не завися от какой-то централизации.

Уникальны ли они? Не думаю:

Они не должны быть уникальными, они должны быть удобными. GitHub вполне себе адекватно и быстро ищет по проекту, а поскольку браузер всегда открыт, а IDE с нужным проектом – нет, поиск получается куда быстрее чем на локальной машине.

Хорош ли UX у GitHub в целом? Очень спорно. Отдельные фичи хороши, многие фичи ужасны, как то просмотр истории.

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

EXL ★★★★★
()

Более того, никому на самом деле не нужен Git

а под этим умозаключением есть какая-то умная мысль или просто личная гипотеза возведенная в абсолют?

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

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

ergo ★★★
()
Последнее исправление: ergo (всего исправлений: 2)

Отвечу уж тут.

Я могу понять разрабов, потому что пользоваться Git — это боль и унижение

Нет, не боль и не унижение.

fernandos ★★★
()

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab.

ядро внезапно разрабатывается без этих всяких гитхабов

Harald ★★★★★
()

Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал

Не гитхаб, а гит(х|л)аб. Он банально удобен.

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab

Мы про идиотов или нормальных? Для первых так и есть.

fernandos ★★★
()
Ответ на: комментарий от byko3y

А типа у нас социального кодинга до GitHub небыло почти, что ли?

Он был малоразвит.

Хорош ли UX у GitHub в целом

Гитхаб и гитлаб предоставляют примерно всё, что нужно разработчику и делают это относительно удобно.

fernandos ★★★
()

Он был банально более удобным. С простым интерфейсом и минимально необходимой функциональностью. SF, googlecode, bugzilla требуют заполнять какие-то поля для багов, а в GH просто пишешь текст в маркдауне. И код со ссылкой на скачивание выставлен на первое место, не надо копаться в куче страниц. Так же пул реквесты были только в нём (насколько я знаю), у других были патчи. Возможно, всё дело в пул реквестах.

xaizek ★★★★★
()

Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab

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

grem ★★★★★
()
Ответ на: комментарий от xaizek

в GH просто пишешь текст в маркдауне.

В соответствиями с требованиями проекта по оформлению? По крайней мере стараешься это делать.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab.

Однозначно нет. Хватит воспринимать github как хранилку git-репозиторий. github - ЭТО ИНСТРУМЕНТ СОВМЕСТНОЙ РАБОТЫ. Со всякими свистоперделками, смайликами, CI/CD, пулреквестиками без почты, иссуями и планированием работы, плагинчиками и милыми беседами над кусочками кода.

AlexVR ★★★★★
()
Ответ на: комментарий от Harald

ага, прислать git format-patch’и и дальнейшее обсуждение вести, в лучшем случае, в рассылке.

Некоторые используют исключительно такой подход.

grem ★★★★★
()
Ответ на: комментарий от EXL

А раньше они на чём были? Давно уже на Git’е пылится этот .NET Core, несколько лет точно

Самый старый релиз на гитхабе годовой давности:

https://github.com/dotnet/runtime/releases?after=v5.0.0-rc.2.20475.5

А по веткам и того меньше. То есть, может он там и лежал, но не разрабатывался.

UNIX-style разработки победил Windows-style, кроме такого вот активного перехода на Git, в современном Windows появился ещё WSL и WSL2

Какой еще unix-style? Докер-контейнеры на каждый чих? Это не юникс, а один вполне конкретный линукс. Как пояснил ранее я и руководитель отдела облаков в Microsoft, они делают ставку на облака, а потому если пользователи хотят линукс в облаках — будет линукс в облаках, получайте ажуру с линем и десятку с контейнерами линя; если пользователи хотят пользоваться клиентом GitHub — ради бога, мы купим ваш GitHub и доработает его клиент.

byko3y ★★★★
() автор топика
Ответ на: комментарий от goingUp

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

Ну ты же в курсе, что был как минимум еще BitBucket? Хотя их было (и есть) еще больше.

Оно могло вполне основываться на другой VCS и все равно победило бы

Во, ты правильно понимаешь. Git вообще тут не при делах, он никому не нужен, кроме Торвальдса и ко.

byko3y ★★★★
() автор топика
Ответ на: комментарий от grem

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

xaizek ★★★★★
()
Ответ на: комментарий от EXL

Был поганый до сих пор SourceForge, который что тогда, что сейчас рассылает вирусы и рекламу вместо ПО

На гитхабе нету вирусни и рекламы?

А ещё раз подчеркну, что именно DVCS и раскрылось в полную силу в таких местах, как GitHub, где пользователи могли форкать проект, форкать форки и вносить в них различные изменения не завися от какой-то централизации

В чем проблема «форкать» SVN репу на сервере?

GitHub вполне себе адекватно и быстро ищет по проекту, а поскольку браузер всегда открыт, а IDE с нужным проектом – нет, поиск получается куда быстрее чем на локальной машине

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

byko3y ★★★★
() автор топика

До GitHub open source разработка в основном происходила вокруг списков рассылки. Из инструментов совместной работы максимум был отдельный багтрекер. GitHub первый кто сделал нормальный инструмент, позволяющий вести совместную разработку за границами одной компании.

В этом плане GitHub для open source сделал больше, чем, например FSF.

maxcom ★★★★★
()
Ответ на: комментарий от ergo

а под этим умозаключением есть какая-то умная мысль или просто личная гипотеза возведенная в абсолют?

Самый главный аргумент в пользу того, что никому не нужен Git — это тот факт, что в основном GitHub/GitLab используются как централизированные репозитории. То есть, DVCS почти никому не нужен. Еще меньше преимущество у Git остается, если вспомнить про то, что был еще Mercurial и Bazaar — особенно Mercurial не уступал Git и даже в чем-то был лучше, много крупных проектов на Mercurial разрабатывалось. Но где сейчас Mercurial и где сейчас Git?

byko3y ★★★★
() автор топика
Ответ на: комментарий от fernandos

Я могу понять разрабов, потому что пользоваться Git — это боль и унижение

Нет, не боль и не унижение

А кактус и привычка, да.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Harald

ядро внезапно разрабатывается без этих всяких гитхабов

Я напоминаю, что Git был специализированным инструментом для разработки ядра Linux — так что в данном случае это не удивительно. Удивительна судьба GitHub на фоне аналогичных сервисов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от fernandos

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab

Мы про идиотов или нормальных? Для первых так и есть

Как ты думаешь, кто есть большинство пользователей GitHub? Они самые.

byko3y ★★★★
() автор топика
Ответ на: комментарий от fernandos

Гитхаб и гитлаб предоставляют примерно всё, что нужно разработчику и делают это относительно удобно

А какой-нибудь Fossil этого не делает? У тебя на локалхосте полная копия твоего проекта с доками и обсуждениями.

А типа у нас социального кодинга до GitHub небыло почти, что ли?

Он был малоразвит

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от xaizek

SF, googlecode, bugzilla требуют заполнять какие-то поля для багов, а в GH просто пишешь текст в маркдауне

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

И код со ссылкой на скачивание выставлен на первое место, не надо копаться в куче страниц

Да, приятная плюшка, которая была не у всех, но сейчас есть у всех. Но я не верю, что она решающая.

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В нормальных проектах обычно фиксированный workflow это сильно ограничивает количество сценариев использования гита. Количество сценариев фиксировано и в нормальных проектах они перечислены на вики проекта со всеми гит-командами. Это позволяет сократить «боль и унижение» до минимума.

Reset ★★★★★
()
Ответ на: комментарий от byko3y

А какой-нибудь Fossil этого не делает

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

Отправить патч разрабу по почте или в багтрекер? Чем это сильно хуже фич гитхаба

Вы сейчас серьёзно? Примерно всем. Гитхаб кроме того, что объединяет всё в одном месте, так ещё и делает это относительно удобно.

fernandos ★★★
()
Ответ на: комментарий от grem

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от AlexVR

Хватит воспринимать github как хранилку git-репозиторий. github - ЭТО ИНСТРУМЕНТ СОВМЕСТНОЙ РАБОТЫ

Да-да, ты правильно понял, Git вообще не нужен на GitHub-е, главное чтобы были вики, багтрекеры, маркдауны, и CI/CD.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Harald

хотя не, есть, но его предполагается присылать по почте, с указанием адреса своего репозитория

А в ответ предлагается присылать адрес, куда должен пойти автор своего репозитория. В истории разработки ядра линя вообще кто-то сливался с каким-то левым репозиторием?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

главное чтобы были вики, багтрекеры, маркдауны, и CI/CD.

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

Reset ★★★★★
()

почему и когда GitHub всех сожрал?

https://docs.google.com/spreadsheets/d/e/2PACX-1vQzqyebXkBsSNE1z6Tb6WQwR5TFrtRN3siBcmrYYZoHp-CnnsgMZ6MWdsTyRDOnesCAwBcY2nbjX0kA/pubchart?oid=2077168324&format=interactive

Почему? А что тогда было лучше SF? Ничего, поэтому и сожрал добавив чуть больше фич. Но и он убог - уделать GitHub как пол пальца обоссать, тем более когда оно под мелкомягкими.

никому на самом деле не нужен Git

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от grem

ага, прислать git format-patch’и и дальнейшее обсуждение вести, в лучшем случае, в рассылке

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от maxcom

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от fernandos

Простая логика: боль вызывает? Нет. А унижение? Тоже нет

Как вонаби-эксперт по UX ответственно заявляю: пользовательский интерфейс Git сильно сложнее выполняемых им функций и сильно менее понятен, чем аналоги. Так получилось, что мое мнение разделяют более одного человека:
https://xkcd.com/1597/
https://sqlite.org/whynotgit.html

byko3y ★★★★
() автор топика
Ответ на: комментарий от fernandos

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

Просто ткни в один из миллионов малопопулярных репозиториев на гитхабе, и оцени IQ и профессиональные навыки автора этого говнокода. Особенно оцени причину того, зачем автор выложил этот код на GitHub и как он пользуется преимуществами VCS в разработке своей поделки из одного-двух коммитов. 90%+ репозиториев на GitHub созданы тупо для резюме! Им даже сам GitHub не нужен. не то что Git.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Reset

В нормальных проектах обычно фиксированный workflow это сильно ограничивает количество сценариев использования гита. Количество сценариев фиксировано и в нормальных проектах они перечислены на вики проекта со всеми гит-командами. Это позволяет сократить «боль и унижение» до минимума

Как правило, большую часть боли снимает IDE, которое подсказывает невнесенные правки и позволяет в пару кликов или хоткеев закомитить правки и пул-пушнуть.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Просто ткни в один из миллионов малопопулярных репозиториев на гитхабе, и оцени IQ и профессиональные навыки автора этого говнокода

Говнокод говнокодом, но человек, вероятнее всего, понимает, что гит — не консольный клиент для гитхаба (тем более, он у них есть).

90%+ репозиториев на GitHub созданы тупо для резюме

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

fernandos ★★★
()

Пацаны, кто по понятиям живет

Вечер в хату!

Git/GitHub используют его как централизированный репозиторий

Нет! GitHub используют как хостинг с полезными фичами, отсутствующими в самом git.

yvv ★★☆
()
Ответ на: комментарий от byko3y

Это всё тривиальщина. Боль возникает при работе с бранчами. Но в нормальных проектах долгоживущие бранчи запрещены, мердж между брачами и пул без ребейза запрещен, в релизные бранчи можно только черри-пикать. Эти правила снимают почти всю боль.

Reset ★★★★★
()
Ответ на: комментарий от byko3y

Я ожидаю,что мои правки окажутся в проекте там, где их наконец примут. При отсутствии конфликтов.

Разумеется, что в слепую мало кто сливает.

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

grem ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.