Содержание

Что такое Git? | Atlassian Git Tutorial

Git — абсолютный лидер по популярности среди современных систем управления версиями. Это развитый проект с активной поддержкой и открытым исходным кодом. Система Git была изначально разработана в 2005 году Линусом Торвальдсом — создателем ядра операционной системы Linux. Git применяется для управления версиями в рамках колоссального количества проектов по разработке ПО, как коммерческих, так и с открытым исходным кодом. Система используется множеством профессиональных разработчиков программного обеспечения. Она превосходно работает под управлением различных операционных систем и может применяться со множеством интегрированных сред разработки (IDE).

Git — система управления версиями с распределенной архитектурой. В отличие от некогда популярных систем вроде CVS и Subversion (SVN), где полная история версий проекта доступна лишь в одном месте, в Git каждая рабочая копия кода сама по себе является репозиторием. Это позволяет всем разработчикам хранить историю изменений в полном объеме.

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

Производительность

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

Некоторые системы управления версиями руководствуются именами файлов при работе с деревом файлов и ведении истории версий. Вместо обработки названий система Git анализирует содержимое. Это важно, поскольку файлы исходного кода часто переименовывают, разделяют и меняют местами. Объектные файлы репозитория Git формируются с помощью дельта‑кодирования (фиксации отличий содержимого) и компрессии. Кроме того, такие файлы в чистом виде хранят объекты с содержимым каталога и метаданными версий.

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

Рассмотрим пример: разработчик Элис меняет исходный код. Она добавляет функцию для будущей версии 2.0, после чего делает коммит и сопровождает изменения описанием. Затем она разрабатывает другую функцию и делает еще один коммит. Разумеется, эти изменения сохраняются в истории в виде отдельных рабочих элементов. Затем Элис переключается на ветку, соответствующую версии 1.3 того же ПО — так она сможет исправить баг, затрагивающий эту конкретную версию. Это нужно, чтобы команда Элис могла выпустить версию 1.3.1 с исправлениями до завершения работы над версией 2.0. Затем Элис вернется к ветке для версии 2.0 и продолжит работу над соответствующими функциями. Все перечисленные действия можно выполнить без доступа к сети, поэтому система Git отличается быстротой и надежностью, даже если работать в самолете. Когда Элис будет готова отправить все внесенные изменения в удаленный репозиторий, ей останется лишь выполнить команду push.

Безопасность

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

Использование Git гарантирует подлинность истории изменений исходного кода.

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

Гибкость

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

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

Контроль версий с помощью Git

Git — это лучшее решение для большинства команд разработки ПО. Разумеется, оценку следует проводить с учетом конкретных требований. Мы лишь хотим перечислить основные причины, по которым команды предпочитают использовать Git.

Превосходные характеристики

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

Git — признанный стандарт

Git является самым популярным инструментом своего класса и поэтому привлекателен по ряду причин. В Atlassian управление исходным кодом проектов практически всегда осуществляется в Git.

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

Однако привлекательность Git обусловлена не только высокой популярностью среди разработчиков. В системе также предусмотрена интеграция различных инструментов и сервисов, включая интегрированные среды разработки и собственные инструменты Atlassian. В число последних входит настольный клиент для распределенных систем управления версиями Sourcetree, система отслеживания задач и проектов Jira, а также сервис размещения кода Bitbucket.

Начинающим разработчикам, которые хотят приобрести ценные навыки работы с инструментами разработки ПО, следует изучить Git как одну из систем управления версиями.

Git — это качественный проект с открытым кодом

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

Вокруг Git сформировалось многочисленное сообщество пользователей, а сам проект получает активную поддержку со стороны сообщества. Система обладает подробной и качественной документацией: всем желающим в числе прочего доступны книги, учебные руководства, специализированные веб‑сайты, подкасты и обучающие видеоролики.

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

Критика Git

Git нередко критикуют за сложность освоения: одни термины могут быть незнакомы новичкам, а другие — иметь иное значение. Так, понятие revert (возврат к предыдущей версии) в Git имеет другой смысл, нежели в SVN и CVS. Тем не менее Git — очень мощная система, предлагающая пользователям широкие возможности. Их изучение займет какое‑то время, однако усвоенные навыки помогут участникам команды работать намного быстрее.

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

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

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

Что такое Git и GitHub

Git — распределенные системы контроля версий, которые помогают обмениваться кодом и «ковать» проекты в команде — отслеживать и контролировать все изменения в коде. Если вы занимаетесь разработкой приложений, веб-сайтов или игр, то наверняка сталкивались с этим.

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

Регистрация на GitHub: создание аккаунта

Для работы с платформой нужно создать аккаунт. Для этого переходим по ссылке и тапаем по кнопке Sign up.

На странице регистрации вводим данные:

  1. Адрес электронной почты. Если на почту уже был зарегистрирован аккаунт, на странице появится сообщение об ошибке: «Email is invalid or already taken».
  1. Пароль. Система рекомендует использовать для пароля последовательность из 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы.
  1. Имя пользователя. «Юзернейм» должен быть уникальным. При этом он не может начинаться или заканчиваться дефисом. 

Теперь нужно нажать кнопку Continue, принять или отклонить предложение о подписке на рассылку и пройти экстравагантную валидацию:

Затем подтвердите адрес электронной почты. 

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

Установка Git

Для работы с репозиторием необходимо скачать Git-терминал или GitHub Desktop. Что из этого выбрать — решать вам. Но предпочтительней уметь работать с командной строкой Git. Такое требование часто можно встретить в вакансиях. Вдобавок, знание командной строки позволяет работать с другими платформами, подобными GitHub.

Терминал

Если у вас установлен Linux, смело пропускайте раздел. С Mac и Windows другая история.

Mac OS

Если вы пользовались XCode, вероятно, Git уже установлен. В противном случае зайдите в терминал, выполните команду git и нажмите кнопку Установить.

После установки можно узнать версию Git.

git --version
Windows

На винду Git можно скачать с официального сайта или через пакет Git Chocolatey. Дополнительная информация о Git Windows доступна по ссылке.

GitHub Desktop. Краткий обзор

Непривычна работа в командной строке — установите «десктопную» версию (доступна на всех ОС). Она хорошо подходит для базовых операций.Установщик есть на официальной странице GitHub Desktop. Там же и наиболее подробное описание программы.

При первом запуске пользователя встречает окно с авторизацией.

А после — интерфейс с привычным функционалом: можно создавать и клонировать репозитории.

Важно отметить, что установка GitHub Desktop на Linux может отличаться в зависимости от дистрибутива. Рекомендуем ознакомиться с официальной инструкцией.

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

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

Первый способ — синхронизация с локальным репозиторием

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

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

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

git init
Загрузка файлов в репозиторий. Создание коммитов

Далее следует добавить все файлы проекта в своеобразный пакет изменений и сделать commit («закоммитить») — загрузить изменения.

git add main.py
git add GAN_core.py
git add dino_ds_api.py
git commit -m “первый коммит”

Последняя команда делает сам «коммит», а флаг -m указывает на сообщение «первый коммит».

В примере были «закоммичены» несколько python-файлов: main, GAN_core и dino_ds_api. Если вам нужно добавить в «коммит» все, что есть в директории, — используйте команду:

git add .

Теперь создадим репозиторий на GitHub. Для этого нужно нажать на кнопку Create repository.

В открывшемся окне обязательно к заполнению только поле с названием проекта. Оно должно быть кратким, но понятным. В нашем примере это gan-dino (gan от generative adversarial networks и dino от dinosaur).

Все остальное опционально:

  • Описание. Поле с кратким описанием проекта. 
  • Режим доступа. Для коммерческих или корпоративных продуктов обычно устанавливается режим private (репозиторий доступен ограниченному кругу лиц). В остальных случаях — public (доступно по ссылке).
  • Файл README. Если в репозитории нужно подробное описание проекта — поставьте галочку рядом с Add a README file. Но есть нюанс: для первого способа создания репозитория галочки быть не должно.
  • Конфигурация .gitignore. Бывает, что в проекте нужно разместить невидимые для Git файлы. Чтобы как-то их обозначить, придумали конфигурацию .gitignore, в которой их можно перечислить.
  • Лицензия. Чтобы никто не использовал ваш код в коммерческих целях без спроса, необходимо добавить файл с лицензией. В нем правообладатели прописывают правила использования своей интеллектуальной собственности.

Создадим public-проект gan-dino, без файла README и конфигурации .gitignore.

Далее GitHub показывает наборы команд, необходимые для загрузки исходного кода в репозиторий. Нас интересует второй блок.

git remote add origin https://github.com/t-rex-general/gan-dino.git
git branch -M main
git push -u origin main

Первая строка загружает origin —  прообраз нашего проекта в глобальном репозитории. Со второй командой мы познакомимся позже. Третья команда загружает (пушит) изменения в GitHub-репозиторий.

После ввода команд система попросит авторизоваться с помощью пароля и названия профиля.

После 13 августа 2021 года вместо пароля нужно вводить токен. 

Откройте настройки вашего аккаунта, выберите пункт меню Developer settings, кликните по Personal access tokens и generate new token. А затем повторите попытку.

Получилось! В репозиторий загрузились нужные файлы. Можно смело делиться ссылкой на него.

Второй способ — от глобального к локальному

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

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

Чтобы клонировать этот репозиторий себе на компьютер, нужно нажать на зеленую кнопку Code, скопировать HTTPS-адрес, перейти в терминал, в нужную директорию и ввести команду:

git clone https://github.com/t-rex-general/gan-dino2.git

В результате файл README.md появится в выбранной директории — локальном репозитории.

С помощью этой же команды можно клонировать и чужие проекты. Например, чтобы не писать все модули для определителя динозавров самостоятельно, можно клонировать чужой репозиторий себе на компьютер. Или сделать fork («форк»), то есть скопировать чей-то проект в свой GitHub-профиль для его доработки. 

Третий способ — внутри GitHub

Если нет возможности использовать Git-терминал или GitHub Desktop, можно работать напрямую с GitHub. Перед этим создаем репозиторий с файлом README.

Внутри GitHub есть онлайн-редактор кода и интерфейс работы с пространством имен (создание файлов, директорий и загрузка других элементов). 

Например, для создания нового файла достаточно нажать на кнопку Create new file. Откроется встроенный редактор кода. 

Потом необходимо сделать коммит.

Работа с ветками

С точки зрения Git, весь процесс разработки — это история коммитов. Такие истории называются ветками — своеобразными указателями на последний коммит. 

Представьте ситуацию: 

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

Создание веток через Git

Чтобы создать ветку (например, dev) в проекте, нужно ввести команду:

git branch dev

После ветка появится в общем списке.

git branch

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

git checkout dev

Попробуем изменить файл проекта и загрузить коммит.

Добавили в программу конструкцию if
git add main.py
git commit -m “добавили if”

Теперь можно посмотреть логи — историю добавления коммитов.

Действительно, второй коммит «улетел» в ветку dev. Если нас не устроили изменения, можно откатиться до предыдущего (любого) коммита по его номеру.

git checkout 61a8f08226eb8067d4e356387f1dcce5c79812dd

Чтобы запушить ветку в онлайн-репозиторий введем команду:

git push --set-upstream origin dev

Открываем репозиторий в GitHub и видим, что добавилась ветка dev:

Но если мы зайдем в main. py, то никаких изменений там не обнаружим, пока не выберем ветку dev.

Чтобы изменения затронули и main-ветку, нужно сделать merge — слияние веток.

Создание веток через GitHub

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

В рамках веток можно также вносить изменения — механизм работы не меняется. 

Слияние веток проекта

Мы почти разработали свой проект. Самое время объединить ветки dev и main.

Первым шагом необходимо переместиться в ветку main:  

git checkout main

Вторым шагом — сделать merge с веткой dev и запушить изменения:

git merge dev
git push

Теперь в GitHub-репозитории отображается актуальная информация.

Работа в команде: конфликты версий и git pull

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

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

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

Код различается: в программе слева выводится максимальная масса динозавра, а справа — последовательность из возможных значений. 

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

Отчет об ошибке

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

git pull

Если это сделать, в файле main.py появится структура, в которой будут видны изменения, которые внесли Вася и Гриша.

Теперь, если Василий считает свою версию более важной, он может убрать код Гриши из программы, и сделать пуш:

git add main.py
git commit -m “dino_weight”
git push

Репозиторий успешно обновлен.

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

Fork и Pull Request

Бывает, что ваш репозиторий кто-то форкает и вносит свои коррективы. Вы можете даже не знать, кто инициатор. Если он захочет поделиться корректировками с вами, то создаст запрос слияния (Pull Request). 

Зайдем с другого аккаунта, найдем репозиторий gan-dino через поисковую систему в GitHub и сделаем форк.

В нашем списке репозиториев появился новый gan-dino-FORK — это форк-образ gan-dino. Теперь можно внести изменения, например, в main.py, и сделать pull request.

Затем владельцу репозитория нужно подтвердить или отклонить запрос. Чтобы это сделать, нужно перейти во вкладку «Pull requests», выбрать интересующий pull-запрос и нажать одну из предложенных кнопок.

Домашнее задание

Любой конкурентоспособный разработчик должен разбираться в Git. Нелишним будет и знание GitHub, в котором есть много возможностей, значительно упрощающих работу над проектами в команде (project management). Например, дашборды во вкладке Projects, повторяющие функционал Trello и Jira.

GitHub — это целая социальная сеть для разработчиков из разных частей света. 

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

Используем GitHub в разработке сервисов

Присоединяйтесь к нашей команде и погрузитесь в наши git-проекты.

Ознакомиться с вакансиями

Если у вас остались вопросы по работе с Git или GitHub, напишите нам.

Что такое файл описания Git?

Получить эту книгу -> Задачи на массив: для интервью и конкурентного программирования

Время чтения: 15 минут

Git создает файл с именем description, который содержит имя репозитория, заданное пользователем. Он находится по адресу .git/description. Он имеет значение по умолчанию как безымянный репозиторий, и разработчики должны поместить фактическое имя и описание проекта в этот файл. Он используется Git как способ по умолчанию узнать имя репозитория.

Используется GitWeb и не рассматривается GitHub или GitLab.
GitWeb — это веб-интерфейс для проектов git. Его можно использовать для создания веб-приложения с функцией поиска, RSS-каналом и многим другим. Его можно рассматривать как нативную альтернативу внешним сервисам, таким как GitHub.

Значение файла по умолчанию описание :

 Безымянный репозиторий; отредактируйте «описание» этого файла, чтобы назвать репозиторий.

Пример файла описания:

 тест opengenus

Этот файл описания используется в нескольких случаях, таких как:

  • Это источник имени репозитория для хуков (скриптов оболочки Git)
    • Хуки
  • можно использовать для отправки электронной почты вкладам в случае новой фиксации, а в электронной почте можно разместить имя репозитория (из файла описания).

Поскольку он не поддерживается/не используется GitHub, вы найдете это значение по умолчанию для всех репозиториев GitHub, таких как TensorFlow.

 git-клон https://github.com/tensorflow/tensorflow
cd тензорный поток
компакт-диск .git
лс -а

Вывод (список содержимого):

 . ветки описание хуки инфо объекты рефы
.. config HEAD index журналы упакованных ссылок

Отредактируйте файл описания:

 vi description

Добавьте в файл «tensorflow» и сохраните его (ESC +: wq).

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

 статус git

Вывод:

 На мастере ветки
Ваша ветка обновлена ​​до «origin/master».
ничего не коммит, рабочее дерево чистое

Мы даже не можем зафиксировать его с другими изменениями.

Начальный новый репозиторий

Файл описания создается при инициализации нового проекта git. Мы проверим, инициализировав новый проект git.

Создайте новую папку с именем test и перейдите в нее:

 mkdir test
компакт-диск тест

Инициировать его как репозиторий git:

 git init

Вывод:

 Инициализирован пустой репозиторий Git в /home/opengenus/Desktop/test/. git/

Теперь это репозиторий git. Перейдем в папку .git и перечислим содержимое:

 компакт-диск .git
лс -а

Вывод:

 . .. описание конфигурации веток HEAD перехватывает информационные объекты refs

Как видим, файл описания присутствует. Если мы откроем его, следующее содержимое:

 Безымянный репозиторий; отредактируйте «описание» этого файла, чтобы назвать репозиторий.

Заключение

Вы можете не использовать файл описания, если вы работаете с:

  • GitHub
  • ГитЛаб
  • Использование git локально без использования gitweb

Файл описания используется только для:

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

github — Изменение описания репозитория в git

спросил

Изменено 3 года, 1 месяц назад

Просмотрено 27 тысяч раз

Я хочу изменить описание репозитория проекта, над которым я работаю, но кнопка «Изменить» не отображается на веб-сайте GitHub.

Я использую GitHub для Windows и предоставленную оболочку.

Хотя описание присутствует на веб-сайте .git\description файл имеет содержимое по умолчанию, а файл \description отсутствует в корневой папке . Где тогда хранится описание проекта, если оно присутствует на GitHub?

Я изменил .git\description , но изменения не видны в статусе git.

Как изменить описание проекта, не создавая файл \description в корневой папке или создавая ссылки на его .git\description версию?

  • git
  • github
  • github-for-windows

Файл .git\description используется только в программе Git-Web. Github даже не беспокоится об этом, и описание, которое вы вводите в своем локальном репозитории git, остается локальным для вас и никогда не будет передано в удаленное репо.

Чтобы изменить описание проекта на Github, посмотрите здесь: Как изменить описание репозитория на GitHub?

3

Вы можете изменять описания репозиториев GitHub только для проектов, которыми вы владеете .

No related posts.