Front end разработка как быть в курсе всех новинок, репозитории на Github


Содержание материала:

Как организовать сотрудничество на GitHub

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

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

Как можно присоединиться к разработке проекта? Думаю, вам известно, как использовать Git , чтобы вносить изменения в файлы и переносить их на сервер. Но есть преимущества принятия участия в разработке больших проектов с открытым кодом, и GitHub однозначно лучшее для этого место.

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

Начните с малого

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

Не бойтесь начать с малого : вместо того, чтобы пытаться исправить большие ошибки ( баги ) или переписать целый модуль, попробуйте найти недостатки в документации или ошибки кроссплатформенности, или даже простые синтаксические и грамматические ошибки ( пример на GitHub от пользователя mzgol).

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

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

Изучите экосистему проекта

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

Например, GitHub стандартизовал файл CONTRIBUTING.md (ознакомьтесь для примера с этим документом ). Подобные инструкции поддерживаются людьми, которые обслуживают базы кодов.

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

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

Использование Pull-Request для внесения изменений

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

Первое, что следует уяснить, это важность следования стандартам и соглашениям, принятым в проекте, над которым вы работаете (что уже обсуждалось выше). Стандартная рабочая среда на GitHub достаточно проста и позволяет:

  • Ответвлять выбранный репозиторий в ваш аккаунт;
  • Копировать репозиторий на локальную машину;
  • Выбирать ветку ( topic branch ) и вносить в неё изменения;
  • Переносить изменения из других веток в свою;
  • Использовать различные инструменты GitHub, чтобы создавать pull request’ы через обсуждения;
  • Применять полученные изменения;
  • Pull request сливается с проектом (как правило с основной веткой – master branch ), а topic branch удаляется из репозитария.

Внутри рабочей среды, вы можете увидеть множество отличий между разными проектами. Например, различия в соглашениях о названии тем. Некоторые проекты могут использовать соглашения типа bug_345 , где 345 это идентификатор (ID #) GitHub issue .

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

Шаг 1: Ответвление (Forking)

Ответвление репозитария на GitHub.com

Шаг 2: Клонирование

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

Шаг 3: Добавление Upstream Remote

Внесите изменения в клонированную директорию и тогда вы сможете добавить upstream remote , то есть указать удаленный репозиторий, с которым будет происходить слияние локальных правок:

Теперь вы сможете вносить изменения локально и синхронизировать их с удаленным репозиторием:

Шаг 4: Выбор ветки (Topic Branch)

Перед внесением изменений, выберите ветку:

Шаг 5: Создание правок

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

Шаг 6: Внесение правок

Далее, необходимо внести изменения, сделанные в ветке вашего проекта:

Шаг 7: Создание Pull Request’а

Наконец, вы можете создать pull request . Для этого, перейдите в вашу ветку репозитария. Там вы увидите надпись « Недавно измененные вами ветки » ( your recently pushed branches ), и если это так, можно выбрать « Сравнить и сделать Pull Request » ( Compare and Pull Request ).

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

Создание pull request через кнопку « Compare and Pull Request ».

Создание pull request посредством выпадающего списка веток

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

Если у кого-то имеются вопросы, они могут задать их в комментариях, а также попросить вас очистить и послать ваш pull request заново, или удалить его.

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

Как написал работник Github Зак Холман ( Zach Holman ) в документе « How GitHub Uses GitHub to Build GitHub », pull request это обсуждение. Именно в таком ключе они и должны восприниматься; вместо ожидания мгновенного принятия вашей правки, следует ждать её обсуждения.

GitHub Issues + Pull Requests = Дзен управления проектом

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

У Issues много отличных встроенных возможностей, но одна из наиболее важных, это интеграция с pull request’ами . Пользователь может сослаться на issue в своем коммите, просто добавив туда его цифровой ID.

Этот коммит автоматически пометит issue №3 как закрытый, когда соответствующий pull request будет принят. Данный способ автоматизации делает GitHub прекрасным инструментом для управления процессом разработки.

Поиск других способов взаимодействия

Зачастую, большие open-source проекты имеют преимущество при совместной работе над ними нескольких людей.

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

Например, такой проект, как Ruby on Rails , был известен своим сообществом; оно отвечало на вопросы на форумах и IRC-чатах, чтобы помочь повысить осведомленность об этом фреймворке, а также помочь направить его развитие путем обсуждения идей и найденных ошибок.

Такие способы взаимодействия обычно представлены форумами и чатами. Но не только: это могут быть почтовые рассылки, аудио- и видеоконференции, которые могут помочь определить направление развития проекта и создать живое, продуктивное сообщество вокруг проекта. Без такого сообщества, pull request’ы не эффективны.

Все зависит от отношения

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

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

Заключение

Если вы заинтересовались разработкой open-source проектов, то это прекрасно! Если вы решились принять участие в одном из них, то не забудьте о правильном отношении и принципе « начни с малого ». Это приблизит вас к моменту, когда вы увидите свое имя в только что присоединенном к проекту pull request’е .

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

Потенциал GitHub и мир open-source продолжают свой рост каждый день; начните сотрудничать с другими разработчиками и станьте частью этого мира!

Данная публикация представляет собой перевод статьи « How to Collaborate On GitHub » , подготовленной дружной командой проекта Интернет-технологии.ру

Для чего нужен GitHub Frontend-разработчику?

Здравствуйте, дорогие друзья! Рада вас снова видеть на страницах своего блога. Сегодняшняя статья будет скорее всего больше для новичков и разработчиков с небольшим опытом, которые только начали свой путь в IT: недавно закончили институт, курсы или ищут первую работу. И, наверное, той себе, какой я была 2 года назад (не так давно исполнилось 2 года, как я стала программистом, а в августе будет ровно два года, как я работаю в коммерческой разработке в найме).

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

  1. Любая задача вызывает у вас ступор, потому что ничего не понятно (наш мозг очень ленивое создание и не любит все новое и непонятное, потому что нужно тратить драгоценную энергию).
  2. На таск, который более опытный разработчик тратит 2-3 часа, у новичка уходит 2-3 дня.
  3. Вы отвлекаете от работы старших коллег вопросами, время которых стоит дороже, чем ваше.
  4. Новички постоянно что-то ломают, а потом долго ищут способ, как починить, потому что не знают.

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

Топ-пост этого месяца:  Какие вопросы для собеседования разработчика можно ожидать при приеме на работу знание механизмов JS

Используйте GitHub, чтобы наработать опыт

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

Во-вторых, чтобы получить опыт, можно поучаствовать в разработке open source библиотек. Попросите владельца репозитория накидать вам несложных для новичка тасков. За участие в open source проекте вам никто не заплатит, но когда вы попытаетесь сделать коммит в репозиторий библиотеки через pull-request, владелец репозитория либо его принимает, либо его отклоняет. И если отклоняет, то чаще всего дает обратную связь, почему ваш код плохой. Главное не стесняться спросить — разработчики, как правило, люди открытые и с удовольствием объясняют, что в вашем коде не так.

Используйте GitHub, чтобы найти работу

Рекрутеры IT-компаний, как правило, просматривают аккаунты разработчиков. Главное не полениться и помочь вас найти, аккуратно оформив аккаунт, репозитории и коммиты. Из своего опыта где-то за последние полгода мне поступало около 10 писем на мой почтовый ящик с приглашением на собеседование. И когда я задавала рекрутеру вопрос: «Откуда Вы меня нашли?», мне честно отвечали: «Я просматриваю аккаунты на гитхабе» (на тот момент у меня уже было более 400 коммитов за год и больше 20 репозиториев). Конечно приятно, когда работа уже начинает искать вас.

GitHub для общения с себе подобными

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

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

GitHub и Git — создание и работа с репозиторием

August 30, 2014

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

Вот такие получаются шаги, которые нужно осветить. Profit у всех этих сложностей, описанных мною выше, один — но большой! Заключается он в том, что проект, над которым вы работаете (даже в гордом одиночестве) находится на удаленном сервере, к которому можно подключиться из любого места и с любой машины. Так как он находиться на remote server, то с ним ничего не случиться, даже если ваша машина упадет\утонет\разобьется.

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

Все действия, описанные в этой статье, будут производиться под операционной системой Linux Mint 17 Cinnamon, в консоли. Поэтому пользователи Mac OS X найдут для себя почти все идентичным. Система Windows остается в стороне.

Создание SSH-ключей под Linux

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

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

Если показанная выше команда “скажет” вам, что директории не существует, то это означает, что у вас с системе установлен пакет SSH, отвечающий за создание и обработку ssh-ключей.

Установка пакета SSH

Под Linux Mint его нужно установить командой:

Создание пары ssh-ключей

Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:

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

Обязательный параметр — электронный адрес, к которому “привязывается” создаваемый ssh-ключ; данный email будет также использоваться мною для регистрации на GitHub.

Как только будет введена представленная выше команда, утилита запросит имя файла и местоположение для создаваемых ssh-ключей. Можно ничего не вводить, а просто нажать Enter . В этом случае программулька создаст и положит их по пути по умолчанию (который показан ею в скобочках):

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

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

После успешного ввода ssh-ключи будут созданы:

В состав пакета входит утилита , задача которой в управлении созданными ssh-ключами. Передадим ей в пользование только созданные мною ssh-ключи:

Можно посмотреть, что утилита “подхватила” и распознала предоставленные ею ssh-ключи:

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

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

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

Добавление ssh-ключа на GitHub

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

Для этого нажимаю на значок шестеренки в правом верхнем углу окна браузера — настройки профиля пользователя. В открывшемся окне (в его левой части) находим строку и нажимаем ее:

Откроется окно для добавления новых ssh-ключей в учетную запись пользователя на GitHub. Здесь все элементарно просто — нажимаем кнопку . В поле вводим название (произвольное) для импортируемого ssh-ключа.

В поле просто нажимаем Ctrl+V — содержимое буфера обмена (которое я получил ранее с помощью утилиты ) вставиться в это поле:

Жму на зеленую кнопку внизу окна. Ключ добавлен на GitHub и появиться в списке SSH-ключей:

Проверка SSH-соединения с GitHub

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

Для этой цели ввожу команду:

На ошибку в строке не стоит обращать внимание. В запросе командной строки печатаем и получаем:

Отлично! GitHub “узнал” меня и поприветствовал в строке . Это говорит о том, что ssh-соединение моей машины с GitHub установлено успешно и GitHub авторизует меня.

Однако, при настройке ssh-соединения возможны и ошибки. В этом случае может помочь статья — Error: Permission denied (publickey).

Создание нового репозитория на GitHub

Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:

Отлично! На GitHub я только что создал новый репозиторий . Теперь можно скопировать (склонировать) его на свою локальную машину командами:

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

Команда фиксирует изменения в локальном репозитории. Команда отправляет внесенные и зафиксированные изменения в локальном репозитории на удаленный репозиторий.

Вот, таким образом я наладил Git-работу своей машины с GitHub.

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Глоссарий терминов для Git и GitHub

Git или Гит — система контроля и управления версиями файлов.

GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.

Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.

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

Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.

Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.

Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.

Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.

Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.

Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.

Мастер (Master) — главная или основная ветка репозитория.

Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.

Пул (Pull) — получение последних изменений с удалённого сервера репозитория.

Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.

Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.

Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.

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

Основы работы с git и первый проект на github.com

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

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

ПО git может быть использовано для достижения следующих целей:

  • хранение истории изменений;
  • перемещение по истории изменений;
  • коллективная работа (слияние изменений + решение конфликтов);
  • резервное копирование.

Программа git эта изначально создана для Linux, и в дальнейшем была портирована под Windows. В следствие этого у неё отсутствует оконный интерфейс, вся работа ведется в консоли, либо через сторонние программы. Например, работа с git поддерживается в IDE PhpStorm, однако в рамках данной статьи мы рассмотрим работу с git только «напрямую».

Топ-пост этого месяца:  Реклама Out-Stream от Google AdWords - новый видеоформат для мобильных

Папка с содержащимися в ней объектами под контролем git называется репозиторием. При этом git позволяет хранить копию проекта и все контрольные точки на удаленном сервере. При этом файлы, хранящиеся на Вашем компьютере называются локальным репозиторием, а файлы, загруженные на сервер — удаленным репозиторием. Удаленные репозитории могут быть публичными или частными (для организаций). Мы рассмотрим один из публичных бесплатных репозиториев под названием github.com.

После регистрации на сервисе нужно создать первый репозиторий, делаем это по ссылке https://github.com/new. Здесь нужно заполнить имя проекта и выбрать тип репозитория — Public. Стоит отметить, что доступ к просмотру файлов после публикации их в публичном репозитории будет иметь любой желающий. Если Вы хотите создать частный репозиторий, скрытый от лишних глаз, придется заплатить. На момент написания статьи стоимость месячной подписки составляла $7. Также ОБЯЗАТЕЛЬНО. нужно поставить галочку напротив пункта «Initialize this repository with a README». Это позволит склонировать репозиторий на Ваш компьютер, сразу после создания.

После создания репозитория мы получаем ссылку на него, имеющую следующую структуру: https://github.com/ваш-ник/имя-репозитория. В моём случае ссылка получилась такой: https://github.com/ivashkevitch/newrep. Перейдя по данному адресу Вы увидите ссылку с подписью «Clone URL». В моём случае это https://github.com/ivashkevitch/newrep.git. Именно эта ссылка будет использоваться если кто-то, включая Вас, захочет склонировать Ваш репозиторий на свой компьютер.

Теперь переходим непосредственно к работе с git. Переходим по ссылке https://git-scm.com/download/win и скачиваем дистрибутив для вашей версии ОС. После завершения установки запускаем программу по появившемуся ярлыку Git Bash. Запускается консольное окно с поддержкой команд Linux. То есть перемещение по папкам, отображение листинга директорий будет осуществляться командами cd и ls соответственно. Выберем папку на локальном компьютере для репозитория. В моём случае это D:/openserver/domains/. Выполняем команду в консоли Git Bash:

Теперь склонируем удаленный репозиторий в текущую директорию. Для этого выполним команду git clone, после которой идёт Clone URL, в моём случае:

Создастся папка с именем проекта, содержащая в себе только один файл — README.md. В нём содержится информация о проекте на github — его имя и описание.

Теперь создадим наш первый файл, который мы хотим добавить под контроль git. Создаём его в только что появившейся папке с проектом и называем index.php. Пусть этот скрипт будет выводить phpinfo. Листинг файла:

Добавим данный файл под контроль git. Для этого в консоли введем команду:

И создадим контрольную точку с названием «Создание index.php. Вызов функции phpinfo().». Для этого выполним команду:

Указание параметра -m является обязательным, иначе откроется текстовый редактор vim. (На всякий случай: выйти из него можно нажав ESC, затем «:q!» без кавычек и нажать Enter.) Контрольная точка создалась, но хранится она только в локальном хранилище. Для отправки изменений на удаленный сервер необходимо выполнить команду:


и после ввода имени пользователя и пароля на github.com будет выполнена отправка в удаленный репозиторий.

Теперь если перейти по URL нашего репозитория на github.com мы увидим добавленный файл index.php с сообщением, указанным к контрольной точке.

Внесём изменения в файле index.php, добавив вывод текста «Hello, world!» перед выводом phpinfo. Содержимое файла станет таким:

Проиндексируем изменения в файле в проекте командой:

Вместо этого можно при вызове команды git commit давить флаг -a, следует заметить, что новые файлы при этом в индекс добавлены не будут!

и отправим изменения на сервер github:

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

Кликнув по имени файла можно посмотреть все его контрольные точки.

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

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

Начинаем работу github

Сразу скажу, что эта «статья» больше для новичков чем для старожил и я буду рад если дадут дельный совет.

Намедни, недавно решил отвлечься от основной работы и всё таки примкнуть к open source сообществу и написать свой велосипед и заодно разобраться с тем как работать

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

Нам нужно установить git. Мануал курить отсюда

Теперь приступим к созданию репозитория. Для начала нужно зарегистрироваться на сайте github.com, если, конечно, у вас нет там аккаунта

Потом необходимо создать репозиторий

После успешного создания репозитория вам выдадут адрес репозитория. Сохраните его.

Учтите что мы создали пустой репозиторий без файлов.

Далее заходите в терминал (*nix системы) или в коммандную строку Windows.

Переходите в директорию где бы вы хотели клонировать наш репозиторий к себе локально.

А потом выполняйте команду

и создайте там пустой файл. Мы создадим файл README.md — это файл описания нашего проекта

И добавим его в отслеживание git`ом введя команду в терминале

Теперь этот файл у нас будет отслеживатся git`ом и его изменения будут фиксироваться с помощью git`a

Далее нам нужно наш локальный репозиторий «подружить» с нашим удаленным.

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

Адрес репозитория, само собой, меняйте на свой.

Что-бы удостовериться что вы правильно «соединили» локальный репозиторий с удаленным введите команду

Теперь нам нужно закоммитить (проще говоря — зафиксировать) наши изменения (добавление файла README.md в репозиторий).

А теперь все изменения нам нужно залить на удаленный репозиторий

У вас должно запросить логин и пароль к github как на скрине выше (при вводе пароля будет казаться что вы ничего не вводите — но это всё вранье)

Теперь давайте перейдем в наш репозиторий через браузер и посмотрим — есть ли там наш файл

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

Спасибо всем кто заинтерисовался.

Если будет интересно то в следующий раз опишу как сделать так чтобы composer видел ваш githubовский репозиторий.

P. S. Конструктивная критикая, советы приветствуются

Front-end разработка

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

Современный developer должен легко владеть html5, css3, JavaScript (и как минимум JQuery). У каждого специалиста есть свои наработки, которые он хранит в виде framework. Многие разработчики в работе пользуются популярными , такими как: Twitter, Bootstrap, Foundation 3, Compass.

Что необходимо знать разработчику:

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

Вот основные базовые навыки:

    JavaScript

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

Система управления версиями файлов GIT

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

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

RequireJS инструменты делают возможной разработку с использованием небольших модульных файлов JS и CSS , а затем конкатенируют и минифицируют их с помощью своего инструмента оптимизации для дальнейшего использования.

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

Инструменты разработчика, встроенные в браузер

За последние несколько лет инструменты для разработчиков, встроенные в браузеры, ощутимо усовершенствовались. Если научиться ими правильно пользоваться, то они могут существенно улучшить опыт разработки. Стоит выбрать один браузер, чьи инструменты разработчика будут использоваться на постоянной основе, но не надо отказываться полностью от инструментов в других браузерах, так как в них время от времени на основе откликов разработчиков добавляются новые полезные возможности. В Dragonfly от Opera, в частности, были добавлены некоторые возможности, выделяющие её инструменты разработчика на фоне других, например: (экспериментальный) CSS- профилировщик, настраиваемые горячие клавиши, удалённая отладка без необходимости , а также возможность сохранять и использовать пользовательские цветовые палитры.

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

  1. ssh для подключения к другой машине или серверу
  2. scp для копирования файлов на другую машину или сервер
  3. ack или grep для поиска файлов в проекте по строке или шаблону
  4. find для обнаружения файлов, чьи названия совпадают с данным шаблоном
  5. git для выполнения хотя бы базовых действий вроде add, commit, status и pull
  6. brew для использования Homebrew для установки пакетов
  7. npm для установки пакетов Node
  8. gem для установки пакетов Ruby

  • Тестирование

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

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

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

    ТИПИЧНЫЙ ВЕРСТАЛЬЩИК

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

    Преимущества создания сайта на Github

    При работе с хостингом от Github, можно сразу отметить несколько существенных преимуществ:

    • Вам не потребуется покупать и ежегодно оплачивать домен;
    • Вам не потребуется вносить ежемесячный платеж на оплату хостинга;
    • Вы сможете сразу продемонстрировать свою работу клиентам;
    • Многие веб-разработчики и заказчики, которые не по наслышке знают о github, с уважением отнесутся к вам, увидев в конце популярное «github.io».

    Этап первый: регистрируем аккаунт

    Попробуем создать сайт вместе. Переходим на сайт Github и в форме, состоящей из трех полей вводим будущий username, email и пароль.

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

    На следующей странице располагается небольшой опрос, но этот шаг можно пропустить, кликнув на skip this step

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

    Топ-пост этого месяца:  Урок 1. Модульное тестирование на PHP. PHPUnit. Установка PHPUnit

    Этап второй: создаем репозиторий

    После регистрации вы попадете на стартовую страницу. Чтобы начать проект, необходимо кликнуть на Start a project.

    И Вас сразу перекинет на страницу по созданию репозитория. Настройки просты: достаточно ввести имя репозитория (имя будущего домена), в нашем случае это tpvesrtak.github.io, установаем галочку около «Initialize this repository with a README» и жмём Create repository. Description заполнять не обязательно.

    Все, репозиторий создан.

    Этап третий: наполняем сайт

    Создание одного лишь репозитория недостаточно. Важно наполнить его файлами, иначе при переходе по ссылке, вида username.github.io мы увидим следующее:

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

    Если сайт готов, то необходимо на странице репозитория нажать на кнопку Upload files.

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

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

    Итак, мы загрузили 2 файла. Теперь необходимо создать 2 папки: css и font. Рассмотрим на примере создание папки для css. Для этого необходимо нажать на кнопку Create new file.

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

    Помните, слеш обязателен!

    После css/ можно написать слово empty. Выглядеть все это будет так:

    Все, больше ничего писать не нужно, просто жмем зеленую кнопку внизу Commit new file. После этого мы сразу же попадаем в папку css, куда необходимо загрузить все файлы css. Как это сделать — мы уже знаем. Файл empty можно удалить.

    Аналогичную операцию повторим и с папкой font и ее файлами.

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

    Этап четвертый: любуемся сайтом

    Самая ожидаемая часть. Смотрим на результат по ссылке: https://tpverstak.github.io

    Надеюсь, статья будет полезна многим, т.к. создавать сайты на Github просто, а самое главное — бесплатно!

    Почему ваш GitHub-репозиторий никому не интересен

    Люди делают проекты, размещают их на GitHub, рассчитывают на обратную связь, на интерес. И очень обидно, когда явно видно, что ваш репозиторий никому не интересен, нет ни просмотров, ни отзывов, никакой другой реакции. Как будто вы выкладываете проекты в пустоту. Почему так бывает? Очень может быть, что вы при публикациях допускаете важные ошибки. Но для начала напомним, что такое GitHub и какая от него польза.

    GitHub – это веб-платформа для управления версиями, которая позволяет разработчикам программ работать совместно. Ресурс стал основой для принципиально нового подхода специалистов в области IT к работе.

    На сегодняшний день GitHub – самый популярный сервис кодового хостинга и самое крупное веб хранилище программных решений. Здесь нашли свое начало известнейшие стартапы, здесь размещены некоторые коды решений Google, Amazon и Facebook.

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

    К людям с высокими рейтингами на GitHub, чаще обращаются за помощью и предлагают работу представители IT-компаний. Т.е. собственный репозиторий на GitHub – это одновременно и возможность найти решение сложной задачи, и профессиональная рекламная площадка, где вы продвигаете себя как специалиста.

    Как бы то ни было, если ваш репозиторий «не работает», ему чего-то не хватает. Приведем наиболее часто допускаемые ошибки.

    Описание проекта: зачем это нужно?

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

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

    В чем дело? Проекты-конкуренты имеют краткое, но информативное описение. Подумайте, чем конкретно Ваш проект выделяется среди аналогов. Опишите его важные особенности и преимущества. Расскажите кратко и понятно: что он может делать и почему это решение интереснее конкурентов. Помните, что одна из важных задач вашего репозитория GitHub– продвигать и продавать проект и ваши навыки. Если вы сами не обоснуете, почему именно данное решение является нужным и интересным, вряд ли это сделает кто-то другой.

    Как сделать красивое описание

    Почитайте, как пишут ваши коллеги. Подумайте еще раз: какое из преимуществ – самое важное. Его нужно указать в 1-2 предложении. А если есть такая возможность, даже включить в заголовок.

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

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

    Не злоупотребляйте зависимостями

    Наглядно проблему описывает широко известная история от одного из программистов на Stack Overflow. Он рассказывал, как взялся однажды за изучение программного решения, в котором сразу увидел шесть зависимостей. Будучи уверен в своих силах, он намеревался их легко обработать. В процессе разработчик понял, что к каждой зависимости привязаны следующие. К тому моменту, когда ему надоело пытаться разобраться с продолженным кодом, он успел найти около двадцати зависимостей.

    Так вот, не придумывайте новые зависимости. Используйте готовые или вовсе их избегайте. Альтернатива – предоставить инструкцию, которая поможет быстро увидеть и изучить все существующие зависимости. Это довольно легко сделать в Python и R.

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

    Запомните: пользовательская документация — это «входная дверь» в ваш проект. Чем доступнее она будет, тем больше пользователей доберутся до сути вашей работы.

    Многие IT-шники не любят работать с документацией. А потому нередко хорошие проекты сопровождаются такими вариантами:

    • Файл Readme;
    • Небольшое ознакомление в Readme плюс ссылка на документацию в формате PDF;
    • Указание wiki-страницы GitHub ссылкой;
    • Ссылка на сайт с официальными документами.

    Это, конечно, лучше, чем полное отсутствие документации. Но все равно маловато.

    При создании документов мы рекомендуем обязательно включать такие пункты:

    • Перечень системных требований (постарайтесь сделать его максимально подробным).
    • Функциональность: описание возможностей и задач, которые решает продукт.
    • Инструкции по установке и запуску.
    • Руководство пользователя с примерами и скриншотами.

    Кроме того, очень полезно выложить:

    • Частые вопросы (FAQ) с вашими ответами.
    • Инструкции разработчику: как протестировать качество работы, проверка результатов через командную строку и т.д.
    • Текст лицензионного соглашения.
    • Контакты.

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

    Исправляйте баги и выпускайте обновления

    Если GitHub-проект свежий, оснащен хорошим описанием и необходимой документацией, при этом в нем нет видимых багов, вероятность интереса к нему высока.

    Но через какое-то время после публикации находятся изъяны и уязвимости, и их нужно незамедлительно закрывать. Тем более, что список таких проблем по любому из проектов виден всем посетителям.

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

    С одной стороны, это очень удобно, так как разработчик может быстро увидеть все выявленные баги и уязвимости. С другой стороны, весь этот перечень ошибок видит любой посетитель. Именно сюда заглядывает большинство пользователей ГитХаба, чтобы определить «сырость» решения.

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

    И последнее: а так ли вы хороши?

    Если вы все делаете, вроде бы верно, но ваши решения все равно не привлекают интереса или вызывают негатив, стоит всерьез подумать: может быть вам просто рано показывать свои достижения, а нужно немного еще поучиться?

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

    Не спешите показывать свои таланты. Посмотрите, что предлагают другие, как работают с ГитХабом ваши коллеги, изучите возможности проекта. Помните: опыт вы наработаете, знания получите, а вот репутация – вещь крайне хрупкая. И если вы попадете в списки «говнокодеров», доказать обратное будет не так просто. Не спешите к славе и монетизации своих решений – убедитесь, что вам и правда есть чем поделиться с коллегами.

    Как создать репозиторий на GitHub через командную строку?

    В папке с проектом создаю локальный репозиторий ( git init ), выполняю весь необходимый минимум ( git add . , git commit -m «Описание коммита» ), и пробую выложить его в свой аккаунт на GitHub:

    А возвращается ошибка:

    remote: Repository not found. fatal: repository ‘https: // github.com / Gooddjamp/git_prj.git/’ not found

    Помогите решить проблему, как выложить свой проект на GitHub.

    3 ответа 3

    Linux / OS X

    Создаем удаленный репозиторий, указывая имя учетной записи.

    Вводим пароль от учетной записи:

    Enter host password for user ‘USER_NAME’:

    Репозиторий demo создан.

    Теперь выгружаем проект.

    Windows

    Вариант 1:

    Устанавливаем утилиту cURL и перезагружаемся. Дальше последовательность идентична Linux.

    Вариант 2 (Спасибо @PinkTux):

    Cкачиваем архив wget, разархивируем в любое место на диске и прописываем путь в переменной PATH . Открываем командную строку и пишем следующее:

    Обратите внимание на экранирование кавычек (обратный слэш перед кавычкой) в —post-data . Не смотря на отсутствие необходимости перезагрузки, все же способ имеет и недостаток — необходимо явно в строке указывать пароль.

    Таким способом можно создавать репозитории с различными параметрами.Вот туд приведен полный перечень параметров. Например для создания приватного репозитория (если у вас есть конечно такая привилегия) нужно подставить в первую строку после -d :

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

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

    (Впрочем, конфликты тут не страшны — можно же и push -f сделать)

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

  • Добавить комментарий