Содержание статьи
И почему вы тоже должны это делать
Страница вашего репозитория GitHub выглядит следующим образом?
См. Проблему?
Давайте посмотрим еще раз.
Первый проект — активно разработанный, чистый, хорошо структурированный проект, написанный и поддерживаемый самим автором. Более 300 звезд — это самый популярный проект этого пользователя и, возможно, тот, который пользователь хочет продемонстрировать, описывая свой вклад в открытый исходный код.
Затем ниже мы видим разветвленный репозиторий, который выглядит несколько связано с первым. Тем не менее, трудно оценить вовлеченность пользователя, не углубляясь в это. Он соавтор? Является ли главный вкладчик? Отличается ли вилка от апстрима? Трудно сказать.
В-третьих, мы видим еще один оригинальный проект, но на этот раз не такой популярный, как плагин eslint выше. Это хорошо, возможно, однажды он получит свою долю любви, описание выглядит многообещающе.
В-четвертых, еще одна развилка, но на этот раз ничего не обновлялось уже более года. Я предполагаю, что пользователь нажал fork по ошибке?
Пятый — это некоторый эксперимент пользователя. В описании говорится, что это «действительно плохо», я не уверен, почему он все еще существует и может ли он представлять интерес для меня.
Наконец, я не совсем уверен, что содержит шестое хранилище. Я заглянул внутрь и там много файлов C #, но я не могу сказать, что они делают. Описание тоже не сильно помогает. Однако он есть вместе со всеми остальными репозиториями.
Проблема в том, что все эти репозитории находятся на одном уровне. Нет порядка, нет различия между ними. Они просто существуют в профиле пользователя.
Пользователь не виноват. GitHub не предоставляет какого-либо простого механизма для организации ваших репозиториев. Это беспокоит меня с тех пор, как я впервые присоединился к сайту в 2013 году, но я думаю, что нашел хорошее решение.
Почему важна структура
Две причины, почему я поднимая этот вопрос:
Сначала — ваше здравомыслие. Мне нравится держать вещи организованными. Хотя у меня есть только 82 репозитория на GitHub, количество программных проектов, которые я держу в автономном режиме, составляет тысячи. Я никак не могу вспомнить имя каждого из них, и если бы я оставил их только в GitHub, мне пришлось бы просматривать их один за другим, пока я не найду то, что ищу.
Если вы думаете, что 1000 GitHub-репозиториев никогда не произойдет, просто проверьте @sindresorhus. Я подозреваю, что он активно просматривает свои вилки и удаляет их, когда они в курсе последних событий.
Второй — рекрутеры и интервьюеры. Не секрет, что ваш профиль на GitHub дополняет ваше резюме при подаче заявления на работу. Иногда это обязательное поле в форме заявки. В других случаях это просто проверка данных, проводимая интервьюером или рекрутером.
Учитывая то, что вы обычно не получаете отзывов о производительности вашего приложения, зачем рисковать тем, что ваш профиль GitHub будет в плохой форме? Интервьюеры в основном смотрят на ваши репозитории, чтобы увидеть одну вещь: они чистые, читаемые и в хорошем состоянии? Я бы предпочел, чтобы они находили лучших из лучших только тогда, когда они ищут меня, а не какой-нибудь курс Udemy React Course, который я проделал днем, и я все еще хожу для дальнейшего использования.
Решение
Группируйте репозитории вместе, используя Организации!
Я храню только самые важные проекты на своей странице профиля. Проекты, которые я хочу, чтобы другие пользователи находили и читали. Проекты, которые я вычистил и которыми я горжусь. Проекты, которые, я надеюсь, другие найдут полезными. Проекты, в которых я принимаю и поощряю вклады.
Все остальное идет в Организацию. Вот как это отражено в моем профиле.
Что у меня здесь:
- aicioara-forks — Проекты, в которых я принимал участие. Все, на что я нажал «вилка», идет сюда. Будь то единственное изменение кода или большой вклад в открытый код. Мне никогда не нужно удалять устаревшие проекты.
- aicioara-шаблонная — Очень редко я начинаю новый проект с нуля. Вместо этого у меня есть типовые репозитории, которые настроены для различных фреймворков: реакции, чернил, расширения Chrome, без фреймворка и т. Д. Я группирую их, чтобы потом их можно было легко найти, либо с моего ноутбука, либо с рабочего компьютера. ]
- aicioara-gh-pages — У меня есть несколько доменов DNS, и все они указывают на какую-то страницу GitHub или другую. Я использую эту организацию, чтобы отслеживать свое присутствие в Интернете и находить вещи проще.
- aicioara-old — Репозитории, содержащие код, на который я могу ссылаться позже, но на самом деле не хочу быть связанным с. Возможно, это проект средней школы или университета без звезд, который больше не отражает то, как я пишу код. У меня нет времени на их обновление, мне все еще нужно когда-нибудь ссылаться на них, но я не хочу, чтобы они говорили: «Эй, вот как Андрей кодирует сегодня ».
Давайте посмотрим, как конкурент решает эту проблему.
GitLab на самом деле даже лучше. Организации здесь называются группами, но у вас также есть подгруппы. Сколько угодно и сколько угодно вложений, вы можете воссоздать всю структуру вложенных папок.
Bitbucket имеет концепцию проектов, которая очень похожа на GitHub Organizations, но гораздо более запутанная. Вы можете использовать их, только если вы передадите право владения команде но дескриптор команды может совпадать с дескриптором вашего пользователя, так что технически он остается вашим, за исключением того, что он не совсем тот же. Может быть, если я потрачу больше времени на то, чтобы разобраться в этом, я оценим конструкцию.
Заключение
В своем стремлении быть минималистичным и включать только минимум функций, GitHub решил не делать этого. дать разработчикам возможность организовать свой онлайн-код кода в разумной и значимой форме. Gitlab и Bitbucket последовали их примеру.
Один из хакерских способов добавить эту функцию — использовать функцию «Организации» (Группы в GitLab, Проекты в Bitbucket), но это связано с недостатком изменения URL проекта, что вам следует никогда не делайте для проекта, который уже популярен.
Загрузка...
