Github что это за программа и нужна для чего
19.08.2015
Статья будет полезна тем техническим писателям, кто слышал от разработчиков такие слова, как Github, коммитить, репозиторий, и хочет разобраться, что же это такое, а также тем, кто выбирает такую систему контроля версий для нужд своей компании, чтобы документация к программным продуктам являлась не только теоретически, но и фактически частью этих продуктов, развиваясь совместно с разрабатываемыми программами.
Подумайте о тысячах и тысячах полностью бесплатных и открыто доступных пакетов исходного кода для программного обеспечения профессионального уровня, которые вы можете установить и «ковыряться» с ними на собственном компьютере для развлечения и заработка (помните, условия лицензий отличаются, так что всегда проверяйте их перед установкой). Сложно подсчитать, но на самом деле средний пользователь компьютера имеет прямой доступ к программам стоимостью многие миллионы долларов, если их оценивать старым общепринятым способом. Это верно в любом значении данной фразы.
GitHub ПРОСТО О СЛОЖНОМ, Зачем нужен GitHub ?
Мы не только можем исследовать бесконечное разнообразие программного обеспечения, мы можем также совместно работать с людьми в различных часовых поясах, в различных частях мира, и всё это, не говоря им ни единого слова (хотя я настоятельно рекомендую наладить хорошие коммуникации со стоящими соавторами). Когда вы создаёте общедоступное место для выкладки файлов проекта программы, опишите чёткие задачи, которые должны быть выполнены, и любой, кто имеет доступ, сможет их выполнять и применять (коммитить) свои изменения в репозитории. Соавторы помогают вам развивать проект без необходимости отправлять флоппи-диски почтой по кругу.
Как хранить проекты программ, публично или приватно
И хотя есть множество способов, с помощью которых можно хранить и распространять свободное программное обеспечение, один из наиболее популярных — создать репозиторий на Github.
Github предлагает два основных варианта: вы можете загружать исходные файлы публично и использовать их инструменты и дисковое пространство бесплатно, или вы можете платить вместо этого небольшие деньги, чтобы сохранить свой исходный код приватно, с доступом только для вас и вашей группы. Вы должны определить, согласны ли с Условиями пользования сервисом, но при этом учтите, что всё больше разработчиков используют Github как место для хранения своей работы. Если сделаете свои файлы публичными на Github, то любой сможет клонировать копию вашего проекта, но если для вас это нормально – продолжайте и наслаждайтесь открытостью.
К счастью, вы не должны быть классическим разработчиком программного обеспечения, чтобы использовать Github. Писатели также часто работают в Markdown, HTML или каком-либо другом текстовом формате, сохраняют свои файлы в репозиториях Github.
Что такое GitHub?
Моя философия, которую придумал не я, но которая становится всё более распространённой, заключается в том, что документация и исходный код должны жить вместе в одном и том же репозитории. Часто документы и исходный код связаны друг с другом, например, через контекстно-зависимую справку. Но держать даже автономную документацию в том же месте, где находятся и другие файлы проекта, всё же имеет смысл. Исходный код не требуется — вы можете так же просто разместить на Github свой роман, созданный по модели краудсорсинга, даже если за ним совсем нет исходного кода.
Github — это не единственный сайт, где можно хранить проекты. Вы можете посмотреть в сторону bitbucket.org, поддерживаемый компанией Atlassian, возможно, он вам подойдёт лучше.
Github и git
Hadoop — это фреймворк первостепенного значения в мире больших данных, и его открытый исходный код доступен на Github для всех, кто хочет «раскрутить» его.
Git, программа управления версиями, разработанная для открытого проекта Linux, обеспечивает работу Github и возникла раньше него на много лет. С помощью git любой пользователь может клонировать ваш репозиторий и затем делать что угодно с копией ваших файлов. Однако ваш исходный репозиторий остаётся нетронутым, пока вы не согласитесь применить в исходном репозитории изменения. Git касается процесса выкладки изменений в репозитории в виде запросов на применение изменений (pull request).
Если вы технический писатель, у которого голова кругом идёт от использования git и Github, то я настоятельно рекомендую учебные пособия, которые разработала Сара Кинири (Sarah Kiniry): http://technicolorwriter.com/why-agile-writers-need-to-use-git/.
Если вы следуете философии хранения документов и кода вместе, вам может потребоваться использование текстовых форматов для документации. Существует несколько инструментов, совершающих правильное отслеживание в репозитории бинарных файлов. В случае с текстовыми форматами вы можете просто создавать диффы между различными версиями (коммитами) файлов и смотреть, в чём различия.
Для изображений пуристы часто используют текстовый формат SVG (Scalable Vector Graphics). Но вы можете использовать стандартные форматы, такие как PNG или JPG, и просто принять, что вам потребуется вручную сравнивать различные версии изображений в случае необходимости.
Доклад Сары на саммите STC 2015 был посвящён тому, как git позволяет вам заниматься археологией своего проекта. Идя по следам коммитов, вы можете увидеть, какую работу сделали разработчики. Если кто-то из разработчиков забыл вам рассказать о небольшой, но критической детали, вы можете найти её в этих отчётах. Если разработчики используют многословные комментарии к коммитам (что в некоторых случаях является обязательным требованием), ваши шансы разобраться во всём возрастают ещё больше. По моему опыту, учитывая комбинацию читабельных комментариев в системе контроля версий, применяемых в рецензировании кода, а также последующее использование JIRA, практически невозможно не заметить изменения в программном обеспечении, если технический писатель уделяет этому хоть какое-то внимание.
Психология «коммитов»
Как и писатели, многие из нас хотят выполнять работу идеально перед тем, как кто-либо увидит результат. Нам трудно показывать грубую, незаконченную работу. Тем не менее, если вы хотите закоммитить свою работу и следовать обычному рабочему эджайл-процессу, вы не должны быть идеальными.
Культура вашего рабочего места и особый тип проекта (например, работа управленца или RFP) влияет на производственный процесс, но опыт показывает, что команде важнее увидеть что-то неидеальное раньше, чем ничего не видеть неделями вообще, и затем им придётся сказать, что вы были всё это время не правы. Когда вы начинаете с чего-то неидеального, процесс обратной связи позволяет вам делать работу лучше. Имейте в виду, что вам нужно найти способ чувствовать себя комфортно по отношению к окончательному состоянию документа, перед тем, как он будет представлен для широкой аудитории, даже если он менее идеален, чем бы вам хотелось. На конференции Write the Docs в 2015 году писатель из Atlassian сказал прямо, что при их непрекращающемся процессе поставки им необходимо принимать документы, которые иногда не полностью обновлены. Будьте честны и открыты для вашей команды и для ваших начальников в отношении того, что можете сделать и что они ожидают.
Git против SVN (Subversion)
И SVN (Subversion), и git являются системами контроля версий, двумя способами создания репозиториев, в которых вы можете коммитить изменения и тщательно отслеживать всё, что вообще происходит с вашей кодовой базой. Но эти две программы имеют некоторые различия в реализации и несколько разную философию. Вы можете начать с git, потому что Github доступен бесплатно и лёгок в изучении.
Мне более привычен SVN, который я использую с 2008 года для работ с закрытым программным обеспечением. Нам требуется всё дерево SVN, чтобы продукт стал готовым к релизу, а каждый разработчик работает с веткой, часто несколько разработчиков (писателей или кодеров) работают с одной и той же веткой.
По моему опыту, если технические писатели и программисты работают вместе таким образом, все они закончат свою работу одновременно (разрабатывать и документировать), что способствует развитию их культуры. SVN даёт пользователям возможность ограничивать по функциональности отдельные файлы или целые ветки, если важно предотвратить внесение мгновенных изменений. SVN хороша для создания централизованной культуры, и для малых, и для больших команд. SVN также имеет репутацию более простой для начального изучения системы, с пронумерованными коммитами, которые легче отслеживать по отчётам.
Одна git имеет множество преимуществ сама по себе. Она продвигает децентрализованное видение мира, без главного репозитория с привилегированным положением. Это видение хорошо работает на многих открытых проектах. С помощью git вы можете регулярно коммитить в свою ветку, даже если у вас нет доступа к сети.
При использовании SVN каждый коммит требует доступа к сети, что может препятствовать осуществлению коммитов с необходимой частотой. Для большой децентрализованной команды проблемы с сетью, которые могут мешать разработчикам подключаться к центральному репозиторию, более вероятны.
Оболочка Git Bash — один из способов взаимодействия с git, но также доступны другие оболочки, включая оболочки с графическим интерфейсом.
JIRA, инструмент от Atlassian, который стал обязательным во многих компаний для использования в качестве багтрекера, трекера отслеживания функций и возможности планировать спринты, может работать и с git, и с SVN. Рецензирование кода, управляющееся открытым способом — важная часть процесса разработки (и если документы сохраняются в виде кода, рецензирование кода также работает и для документов).
Для рецензирования кода я использую Code Collaborator, который хорошо работает с SVN, и моё исследование показывает, что CC может также хорошо работать и с git. Также доступно множество других инструментов для рецензирования кода.
Я игнорирую другие программы контроля версий, такие как perforce и Mercurial. Однако к ним применимы те же основные принципы. В целом, если вы хотите начать прямо сейчас работать в системе контроля версий для собственного проекта, используйте git. Если вы работаете в компании, которая использует SVN или другую систему контроля версий, и она правильно внедрена, у вас всё будет хорошо.
Просто убедитесь, что совершаете коммиты согласно правилам вашей команды, и делаете это достаточно часто. Вы не можете отслеживать изменения, если не коммитите эти изменения, и можете потерять свою работу, если не совершаете коммиты регулярно. Как часто? У вашей команды могут быть свои правила, но, по моему мнению, не стоит это делать реже, чем раз в день, если вы вообще работали с этим файлом в этот день.
SVN и git имеют команды, которые пугают даже опытных пользователей. Для меня в SVN это команда switch, потому что с помощью неё очень легко «запороть» ветку. В git, насколько я читал, опасна команда rebase. Но вы должны очень постараться, чтобы совершить настолько неисправимое изменение, что оно будет хуже полного отсутствия коммитов.
Преимущество текстовых инструментов для рецензирования кода
Несмотря на то, что использование простого сравнения отличий для различных текстовых файлов возможно, использование их для бинарных форматов может быть очень неудобным. Скажем, вы можете коммитить бинарные файлы по мере работы над ними, и можете всегда откатиться на предыдущую версию, даже если потребуется провести исследование вручную, чтобы определить, что у вас в руках та старая версия, которая нужна. Но инструменты рецензирования кода для бинарных файлов использовать куда более сложно.
Бинарные форматы обычно проприетарные. Например, если использовать неструктурированный FrameMaker для создания .fm-файлов, то только те сотрудники, у которых есть FrameMaker, смогут увидеть исходные файлы. Вы можете раздать свои PDF-ки экспертам по предмету, и возможно, другие инструменты для рецензирования, но я точно убедился, что использование инструментов рецензирования кода несоизмеримо лучше.
Github поддерживает собственную версию Markdown, очень простую систему текстового форматирования, которая хорошо работает для технических писателей, интегрирующих свои документы с кодом. Разработчики любят Markdown, потому что его формат легко читать, с его помощью легко писать, и составлять описания можно в любом техническом редакторе, будь то emacs, Oxygen или Блокнот.
Github также позволяет без проблем совместно работать группе, внутри которой используются разные операционные системы. У одного разработчика может быть Mac, другой может использовать Linux, а ещё один — Windows, но это не имеет значения для git и Github. По моему опыту, могут быть некоторые сложности в совмещении SVN в Linux и SVN в Windows вследствие тонких программных различий.
Принимая во внимание, что DITA использует XML-файлы, являющиеся текстом, DITA может хорошо работать в производственном процессе, в котором интегрированы документы в код. Хотя человек, не знакомый с DITA, не сможет редактировать файлы, что делает DITA несколько менее открытым, чем «человекочитаемые» форматы, такие как Markdown или restructuredText.
Ваш сайт Github в качестве портфолио
Я часто читаю о HR-менеджерах, которые говорят, что хотят увидеть работы разработчика программного обеспечения на Github. Конечно, многие из нас работают в компаниях, у которых нет свободного программного обеспечения, так что мы определённо не можем выложить эту работу в Github на всеобщее обозрение. Тем не менее, Github — отличное место для хранения проектов, которые вы можете сделать общедоступными. Если вы сделали работу самостоятельно, ваши коммиты расскажут историю для любого, кто исследует отчёты. В отличие от явного плагиата, вы не можете подделать работу, которую сделали в репозитории Github (или SVN).
Github для совместной работы
Многие писатели считают Google Docs лучшим решением для совместного писательства. Я его использовал, когда Том Джонсон (Tom Johnson) редактировал в сентябре 2014 года публикацию для STC Intercom о документировании API, я тогда был соавтором этой статьи.
Но Gitub также хороший способ взаимодействия. Хотя вы и не можете видеть, как все остальные набирают в реальном времени, вы можете легко прокрутить вперёд и назад и увидеть, кто какие внёс изменения. Если вы и ваш соавтор делаете что-то, что конфликтует друг с другом, Github поможет вам разрешить этот конфликт.
Что доступно на Github?
Многие открытые проекты перемещены на Github. Просто совершите поиск на тему, которая вас интересует, например, «музыка», и вы обнаружите по крайней мере один проект, который к этому относится. Когда вы посещаете веб-сайт открытого проекта, то скорее всего увидите ссылку на его Github-репозиторий.
Также техническим писателям будет интересно: документация API к Github и документация Github являются моделями понятной, простой документации, которую используют буквально миллионы людей. Не бойтесь коммитов, изучите этот вопрос и решите для себя, каким образом участие в работе Github может быть выгодным для вас.
Источник: protext.su
Работа с GitHub (1/3)
Всем доброго времени суток! Вы, наверное, слышали такое слово как GitHub? В любом случае именно сегодня мы поговорим о том, что это такое и научимся азам работы с ним.
Что такое GitHub?
GitHub — это сервис, который был разработан с целью давать разработчикам делиться своими проектами, разрабатывать их вместе, а также следить за версиями, т.к. GitHub основан на системе контроля версий Git.
Основным плюсом GitHub является то, что он бесплатен для OpenSource проектов, но, если проект частный, то уже придется платить.
Каждый человек может создать репозиторий, где хранить какой-то свой проект и, если захочет, показывать его другим людям. Другие же могут просматривать все файлы проекта и их исходный код с подсветкой синтаксиса, а если нужно, то могут их даже скачать или изменить.
Регистрация
Регистрация в данной системе очень простая. Вам нужно лишь перейти по ссылке
Там ввести незанятый логин, email и пароль и после чего нажать на кнопку Sign Up for GitHub. Теперь перейдите в указанную вами почту и подтвердите регистрацию, перейдя по присланной вам ссылке. Теперь авторизуйтесь и. вы уже зарегистрированы. Не трудно, правда?
Создаем репозиторий
Чтобы создать свой репозиторий, найдите в правом верхнем углу знак плюса и нажмите на него, выбрав там пункт New repository.
В самом начале введите имя вашего проекта, а затем его описание(необязательно).
Ниже вы можете видеть радио-переключатель с режимами Public и Private. Первый означает, что ваш репозиторий будет виден всем и вы можете выбрать тех, кто сможет совершать с ним коммиты(commit). Второй же означает, что репозиторий будет закрытым, но вы можете выбрать, кто сможет коммитить и просматривать его.
Ниже вы можете установить галочку, чтобы сразу инициализировать этот репозиторий с файлом readme.
Теперь нажмите на кнопку Create repository.
Поздравляю! Вы создали свой первый репозиторий!
Установка GitHub
Для Windows есть программа windows.github.com
Для Mac есть mac.github.com
Эти программы позволяют работать с графическим интерфейсом, мы же будем работать с командной строкой. Если у вас mac, то там все работает из коробки, ну, а если вы счастливый обладатель windows, то вам придется поставить msysqgit
Откройте терминал(командную строку) и введите следующее:
Если вы увидите версию, то все работает.
Клонируем репозиторий
Перейдите в созданный вами репозиторий и найдите справа текстовое поле, подписанное HTTPS. Там вы найдете ссылку, которую нужно скопировать.
Откройте терминал и введите следующее:
git clone YOURLINK YOURNAME
Вместо yourlink вставьте скопированную ссылку и через пробел введите любое имя, которое хотите. Если вы не введете имя, то оно будет таким же, как и название репозитория.
Теперь внутри папки git появился склонированный нами репозиторий. Внутри вы можете обнаружить файл readme.txt. Пока что это все, что у нас есть.
Настройка
Когда вы делаете какие-то изменения, то все это сохраняется и отображается. В этом большой плюс систем контроля версий. Но нам нужно сделать несколько настроек.
В терминале введите следующее:
git config —global user.name «Ваше имя»
git config —global user.email «Ваш email»
Если теперь вы введете
git config user.name
То получите указанное имя.
Итак, на этом заканчивается первая часть, посвященная работе с GitHub. Сегодня мы в основном возились с настройками, но дальше будет интересней, и вы сразу поймете всю прелесть данного сервиса. Спасибо за внимание!
Создано 07.07.2014 20:29:17
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
- Кнопка:
Она выглядит вот так: - Текстовая ссылка:
Она выглядит вот так: Как создать свой сайт - BB-код ссылки для форумов (например, можете поставить её в подписи):
Комментарии ( 1 ):
vladik200061 08.07.2014 11:12:43
я сервис github.com не использую, тк в беспалатной версии мало функций, по моему даже ветки создавать нельзя. рекомендую bitbucket.org, он и для новичков будет полезнее
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Источник: myrusakov.ru
GitHub — установка и работа
GitHub — самый крупный веб-сервис для хостинга IT-проектов и их совместной разработки.
Вначале регистрируемся на GitHub.
Вводим данные и нажимаем большую, зелёную кнопку.
На следующей странице нажимаем
Далее жмём + New repository
Здесь придумываем название для репозитория и жмём
Если хотите приватный реп (видимый только Вам), то придётся платить денежки.
Файл README по желанию, хотите создайте, хотите не создавайте.
Оказываемся на вот такой страничке, и нажимаем SSH:
Теперь нужно добраться до формы для ввода ssh-ключа. В правой колонке нажимаем Settings
Нажимаем Deploy keys
Нажимаем Add deploy keys
Далее нам нужно установить Git на компьютер и создать ключи.
Открываем терминал и устанавливаем Git:
sudo apt-get install git
Почтовый адрес укажите тот, который вводили при регистрации на github.
На все вопросы нажимайте Enter.
Ключи готовы.
Сообщаем о ключе ssh-агенту:
ssh-add ~/.ssh/id_rsa
Идём в папку ~/.ssh (она скрытая), находим файл id_rsa.pub, открываем его текстовым редактором, копируем содержимое, вставляем его в поле Key и жмём кнопку Add Key.
Title можно не заполнять, а галку надо поставить.
Кликаем на myrepo и видим знакомое окно:
Осталось совсем немного. Нужно указать локальной системе git имя пользователя и email, которые указавали при регистрации.
Возвращаемся в терминал и даём следующие команды: (их можно выполнить, находясь в любом каталоге)
git config —global user.name «istarik»
Переходим в папку с проектами, которые Вы собираетесь хранить на Github: (работа с github ведётся из конкретной папки)
cd /home/USER/myproject
У Вас разумеется своя папка.
И даём команды, которые предлагает github:
Команда echo «# myrepo» >> README.md необязательна, а git add README.md изменим на git add * .
git init
Добавляем всё файлы находящиеся в папке:
git add *
Делаем коммит с названием «first commit»
git commit -m «first commit»
Указываем путь к Вашему репозиторию: (замените istarik/myrepo на своё)
Заливаем файлы в основную ветку:
git push -u origin master
На вопрос ответьте yes
Ну вот, Вы и «запушили» свои файлы на github.
Обновите страничку и увидите результат:
Теперь надо разобраться с командами
Клонировать репозиторий
Скопировать репозиторий расположенный на github, к себе на компьютер. (Например Вы решили присоединиться к разработке чьего-либо проекта.)
cd /home/USER/myproject2
В папке myproject2 появятся файлы из репозитория.
Добавить изменённый файл
Предположим Вы сделали какие-либо изменения в файле file.c и хотите отправить его в репозиторий.
Добавление изменений в индекс — «коммит»:
Индекс — это список сделанных изменений, на основании которого, программа git выполняет операции.
git commit -a
Откроется текстовый редактор, с предложением сделать пометку. Напишите что-нибудь типа ‘second commit’ и закройте редактор.
Чтоб редактор не открывался, пометку можно сделать и так:
git commit -a -m «second commit»
Отправляем файл в репозиторий — «пушим»:
git push
Пометка присваивается только изменённым файлам.
Добавить новый файл
Если у Вас появились новые файлы, то чтоб добавить их всех вместе, нужно дать команду:
git add *
В индекс добавятся все новые файлы.
А чтоб добавить выборочно, то команда такая:
git add file.txt
git add hello.php
git commit -a -m «New file»
git push
Удалить файл из репозитория
git rm file.txt
git commit -a -m «Del file»
git push
На диске файл останется.
Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):
git status
Обновление данных из репозитория
Если Вы занимаетесь совместной разработкой проекта, и Ваш коллега что-то менял в нём, то чтобы эти изменения появились на Вашем компьютере, надо сделать pull.
git pull
Данная команда получает обновленную версию из удаленного репозитория текущей ветки, при этом она проверяет на наличие различных проблем при объединении репозиториев и сообщает об этом.
История изменений
Чтобы посмотреть историю всех изменений, надо скомандовать:
git log
Или для конкретного файла:
git log file.c
С просмотром сделанных изменений:
git log -p file.c
С именами файлов и псевдографическим изображением:
git log —stat —graph
Изменения, сделанные в заданном коммите:
git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Хэш смотреть в git log
Кем в последний раз правилась каждая строка файла:
git blame file.c
Откатиться к конкретному коммиту
git reset —hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Хэш смотреть в git log
То же самое, но файлы на диске остаются без изменений:
git reset —soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Ветки
Работать с ветками, стоит начинать после того, как наберётесь опыта.
Допустим Вы хотите сделать некоторые изменения в проекте, однако не уверены, выйдет ли из этого что-то хорошее.
В таких случаях нужно создать новую ветку:
git branch vetka
И перейти в неё:
git checkout vetka
Теперь что бы Вы не делали, это не затронет основную ветку — master.
Если вышло что-то хорошее, мерджим ветку в master.
git commit -a
Коммит всех изменений в vetka.
git checkout master
Переключаемся на master.
git merge vetka
Если ничего хорошего не вышло, возвращаемся к основной ветке:
git checkout master
Замерджить все ветки локального репозитория на удаленный репозиторий: (merge — операция слияния разных версий)
git push origin
origin — имя основного репозитория.
Аналогично предыдущему, но делается пуш только ветки master:
git push origin master
master — имя основной ветки репозитория. (о ветках ниже)
Запушить текущую ветку, не вводя целиком ее название:
git push origin HEAD
Получить список веток, с которыми работаем
git branch
Звездочкой будет отмечена текущая ветвь.
Просмотреть все существующие ветви:
git branch -a
Удалить ветку (после мерджа):
git branch -d vetka
Просто удалить ветку:
git branch -D vetka
Обновление веток репозитория
Обновить все ветки из удаленного репозитория:
git pull origin
Обновить основную ветку из удаленного репозитория:
git pull origin master
Разрешение конфликтов (когда оные возникают в результате мерджа):
git mergetool
git tag some_tag
За тэгом можно указать хэш коммита.
Удаление untracked files:
git clean -f
«Упаковка» репозитория для увеличения скорости работы с ним:
git gc
Файл .gitignore
Создайте в папке с Вашими проектами файл .gitignore и впишите в него то, что не хотите выкладывать в репозиторий.
Например в него можно записать вот такие строки:
*.txt *.exe
Файлы с расширением txt и exe, не будут никуда отправляться.
На этом пожалуй всё.
В статье использованы материалы с сайта eax.me
—>
Поддержать автора
Задать вопрос по статье
Известит Вас о новых публикациях
Источник: istarik.ru
Github что это за программа и нужна для чего
Ключевое отличие — Git против Github
Система контроля версий — это программное обеспечение, которое помогает разработчикам программного обеспечения работать совместно и вести полную историю своей работы. Он может хранить изменения файлов и модификации исходного кода. Каждый раз, когда пользователь изменяет проект, система контроля версий принимает состояние проекта и сохраняет их.
Эти различные сохраненные состояния проекта известны как версии. Например, если программист создает веб-сайт, он сохраняется как версия 1. Позже, если программист добавляет на этот веб-сайт еще одну страницу, эти изменения сохраняются как версия 2. Аналогичным образом изменения сохраняются как версии в системах контроля версий. Git и Github — это два термина, связанных с контролем версий. В ключевое отличие между Git и Github заключается в том, что Git — это система контроля версий с открытым исходным кодом, а Github — это хостинг для репозитория Git.. В этой статье обсуждается разница между Git и Github.
1. Обзор и основные отличия
2. Что такое Git
3. Что такое Github
4. Сходства между Git и Github
5. Сравнение бок о бок — Git и Github в табличной форме
6. Резюме
Что такое Git?
Для небольшого проекта может не потребоваться создание системы контроля версий, но необходимо управлять большими проектами. Предположим, что программный проект разрабатывают три программиста. Каждый программист может выполнять свои собственные задачи. В конце концов, объединение всего вместе может привести к конфликтам, потому что изменений очень много.
Системы контроля версий решают эту проблему. Каждый разработчик знает, какие изменения произошли в проекте, и это сэкономит много времени. Есть два типа систем контроля версий. Это централизованная система контроля версий и распределенная система контроля версий. В централизованная система контроля версий, центральный сервер хранит все файлы.
Если центральный сервер выходит из строя, никто вообще не может сотрудничать. Если диск центрального сервера поврежден и нет резервной копии, история всего проекта может быть потеряна. Следовательно, распределенные системы контроля версий были представлены.
Git — это распределенная система контроля версий с открытым исходным кодом. Он популярен, чем другие системы контроля версий, такие как SVN, CVS и Mercurial. Репозиторий — это пространство данных для хранения всех файлов, связанных с проектом. У каждого разработчика есть свое личное рабочее пространство в виде рабочей копии, известной как локальный репозиторий.
Они могут вносить изменения в локальный репозиторий при отсутствии подключения к Интернету. Можно фиксировать изменения и просматривать журналы, когда они отключены.
Как только подключение к Интернету установлено, изменения могут быть перенесены на главный сервер, который является удаленным репозиторием. В случае выхода из строя основного сервера его можно восстановить с помощью локального репозитория. В целом, в Git доступно множество функций для улучшения разработки программного обеспечения. Он распространяется, легкий, быстрый, надежный и безопасный.
Что такое Github?
Github — это веб-хостинг для репозитория контроля версий Git. Он предоставляет такие услуги, как управление исходным кодом и распределенный контроль версий, например Git. Он также содержит дополнительные функции. Он обеспечивает контроль доступа, отслеживание ошибок, запросы функций и управление задачами для каждого проекта.
Одним из реальных примеров Github на уровне предприятия является Dominion Enterprise. Это ведущая маркетинговая служба и издательская компания. У них есть несколько офисов по всему миру. Их веб-сайты ежедневно привлекают большое количество посетителей. У них распределенная техническая команда, они преследуют разные цели и работают независимо.
Им нужно знать, над чем работает каждая команда, и делиться ресурсами. Была потребность в гибкой платформе, которая могла бы поддерживать различные рабочие процессы и безопасное место для обмена кодами. Они использовали Github в качестве службы хостинга репозитория для управления версиями Git.
В чем сходство между Git и Github?
- Оба связаны с контролем версий.
В чем разница между Git и Github?
Git против Github
Резюме -Git против Github
Слова Git и Github похожи, но они разные. Git — это система контроля версий, которая обеспечивает управление исходным кодом для разработки надежного и точного программного обеспечения. Github — это хостинговая платформа для Git. Большинство разработчиков знакомы с Github, и к нему легко адаптироваться.
Разница между Git и Github заключается в том, что Git — это система управления версиями с открытым исходным кодом, а Github — это веб-хостинг для репозитория Git. Они используются для создания качественного программного обеспечения.
Скачать PDF-версию Git vs Github
Вы можете скачать PDF-версию этой статьи и использовать ее в автономных целях в соответствии с примечанием к цитированию. Пожалуйста, скачайте PDF-версию здесь. Разница между Git и Github
Источник: ru.strephonsays.com