Сведения о GIT
Узнайте о системе управления версиями, Git и о том, как она работает с GitHub.
Сведения об управлении версиями и GIT
Система управления версиями отслеживает историю изменений в процессе совместной работы над проектами. По мере того как разработчики вносят изменения в проект, в любое время можно восстановить любую более раннюю его версию.
Разработчики могут просматривать журнал проекта, чтобы узнавать следующее:
- какие изменения были внесены;
- кто внес изменения;
- какие изменения были внесены;
- зачем потребовались изменения.
Системы управления версиями предоставляют каждому участнику единое, согласованное представление проекта с возможностью отслеживать уже ведущуюся работу. Возможность просмотра прозрачной истории изменений с указанием их авторов и вклада в разработку проекта помогает участникам команды работать согласованно независимо друг от друга.
В распределенной системе управления версиями каждый разработчик имеет полную копию проекта и его журнала. В отличие от популярных централизованных систем управления версиями распределенные системы не требуют постоянного подключения к центральному репозиторию. GIT — это самая популярная распределенная система управления версиями. GIT широко применяется для разработки как программного обеспечения (ПО) с открытым кодом, так и коммерческого ПО, предоставляя важные преимущества отдельным разработчикам, командам и компаниям.
- GIT позволяет разработчикам просматривать всю временную шкалу изменений, решений и хода выполнения любого проекта в одном месте. С момента доступа к истории проекта разработчик получает всю необходимую информацию, чтобы разобраться в проекте и начать вносить свой вклад.
- Разработчики работают в разных часовых поясах. Благодаря распределенной системе управления версиями, такой как GIT, совместную работу можно вести в любое время, сохраняя целостность исходного кода. С помощью ветвей разработчики могут безопасно предлагать изменения для рабочего кода.
- Организации, использующие GIT, могут устранить коммуникационные барьеры между командами, чтобы те могли сосредоточиться на выполнении своих задач с максимальной эффективностью. Кроме того, GIT позволяет согласовать совместную работу экспертов над крупными проектами в масштабе всего предприятия.
Сведения о репозиториях
Репозиторий или проект GIT включает в себя полный набор файлов и папок, связанных с проектом, а также журнал изменений каждого файла. Журнал файла представлен в виде моментальных снимков на определенные моменты времени. Эти снимки называются фиксациями. Фиксации можно упорядочивать по нескольким линиям разработки, называемым ветвями. Так как GIT — распределенная система управления версиями, репозитории являются автономными единицами и любой пользователь, имеющий копию репозитория, может получать доступ ко всей базе кода и ее истории. С помощью командной строки или других удобных интерфейсов возможны также следующие действия с репозиторием GIT: взаимодействие с журналом, клонирование репозитория, создание ветвей, фиксация, слияние, сравнение изменений в разных версиях кода и многое другое.
С помощью таких платформ, как GitHub, GIT также предоставляет дополнительные возможности для обеспечения прозрачности проектов и совместной работы. Общедоступные репозитории помогают командам работать вместе над созданием максимально качественного конечного продукта.
Принципы работы GitHub
GitHub служит для размещения репозиториев GIT и предоставляет разработчикам средства для поставки более качественного кода: функции командной строки, проблемы (цепочки обсуждений), запросы на вытягивание, проверка кода и коллекция бесплатных и платных приложений в GitHub Marketplace. С такими уровнями совместной работы, как поток GitHub, сообществом 100 миллионов разработчиков и экосистемой с сотнями интеграции, GitHub изменяет способ создания программного обеспечения.
GitHub позволяет интегрировать совместную работу непосредственно в процесс разработки. Работа организована по репозиториям, в которых разработчики могут устанавливать требования или давать указания участникам команды. Затем, используя поток GitHub, разработчики просто создают ветвь для работы с обновлениями, фиксируют изменения, чтобы сохранять их, открывают запросы на вытягивание, чтобы предлагать и обсуждать изменения, и выполняют слияние запросов на вытягивание после их согласования. Дополнительные сведения см. в разделе «AUTOTITLE».
Сведения о планах и затратах на GitHub см. в разделе GitHub Pricing. Сведения о том, как GitHub Enterprise сравнивается с другими параметрами, см. в статье Сравнение GitHub с другими решениями DevOps.
GitHub и командная строка
Основные команды Git
Работая с GIT, разработчики используют определенные команды для копирования, создания, изменения и объединения кода. Эти команды можно выполнять непосредственно из командной строки или с помощью приложения, например GitHub Desktop. Ниже приведены некоторые распространенные команды для работы с GIT.
- git init — инициализирует новый репозиторий GIT и начинает отслеживание существующего каталога. В существующий каталог добавляется скрытая вложенная папка, в которой размещается внутренняя структура данных, необходимая для управления версиями.
- git clone — создает локальную копию проекта, который уже существует удаленно. Клон включает в себя все файлы проекта, журнал и ветви.
- git add — подготавливает изменение. GIT отслеживает изменения в базе кода разработчика, но для включения изменений в журнал проекта необходимо подготавливать их и создавать моментальные снимки. Эта команда выполняет первую часть этого двухэтапного процесса, то есть подготовку. Все подготовленные изменения станут частью следующего моментального снимка и журнала проекта. Раздельные подготовка и фиксация дают разработчикам полный контроль над историей проекта без необходимости изменять подход к написанию кода и работе в целом.
- git commit — сохраняет моментальный снимок в журнале проекта и завершает процесс отслеживания изменений. Иначе говоря, фиксация похожа на создание фотографии. Все, что было подготовлено с помощью команды git add , станет частью моментального снимка при использовании git commit .
- git status — выводит состояние изменений: не отслеживаются, изменены или подготовлены.
- git branch — показывает ветви, с которыми ведется локальная работа.
- git merge — выполняет слияние линий разработки. Эта команда обычно применяется для объединения изменений, внесенных в двух разных ветвях. Например, разработчик выполняет слияние, когда необходимо объединить изменения из ветви функции с главной ветвью для развертывания.
- git pull — применяет к локальной линии разработки обновления из удаленного аналога. Разработчики используют эту команду, если коллега выполнил фиксации в ветви удаленного репозитория и эти изменения нужно отразить в локальной среде.
- git push — обновляет удаленный репозиторий с учетом фиксаций, выполненных в ветви локально.
Пример. Участие в существующем репозитории
# download a repository on GitHub to our machine # Replace `owner/repo` with the owner and name of the repository to clone git clone https://github.com/owner/repo.git # change into the `repo` directory cd repo # create a new branch to store any new changes git branch my-branch # switch to that branch (line of development) git checkout my-branch # make changes, for example, edit `file1.md` and `file2.md` using the text editor # stage the changed files git add file1.md file2.md # take a snapshot of the staging area (anything that's been added) git commit -m "my snapshot" # push changes to github git push --set-upstream origin my-branch Пример. Создание нового репозитория и его публикация в GitHub
Сначала необходимо создать репозиторий на GitHub. Дополнительные сведения см. в разделе «AUTOTITLE». Не инициализируйте репозиторий с помощью файла сведений, GITIGNORE или файла лицензии. Этот пустой репозиторий ожидает добавления кода.
# create a new directory, and initialize it with git-specific functions git init my-repo # change into the `my-repo` directory cd my-repo # create the first file in the project touch README.md # git isn't aware of the file, stage it git add README.md # take a snapshot of the staging area git commit -m "add README to initial commit" # provide the path for the repository you created on github git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git # push changes to github git push --set-upstream origin main Пример. Участие в существующей ветви на GitHub
В этом примере предполагается, что у вас на компьютере уже есть проект с именем repo и что новая ветвь была отправлена в GitHub с момента последнего внесения изменений локально.
# change into the `repo` directory cd repo # update all remote tracking branches, and the currently checked out branch git pull # change into the existing branch called `feature-a` git checkout feature-a # make changes, for example, edit `file1.md` using the text editor # stage the changed file git add file1.md # take a snapshot of the staging area git commit -m "edit file1" # push changes to github git push Модели совместной разработки
Существует два основных способа совместной работы на GitHub:
- общий репозиторий;
- создание вилок и вытягивание.
В случае с общим репозиторием отдельные пользователи и команды явно назначаются участниками с доступом на чтение, запись или администрирование. Эта простая структура разрешений в сочетании с такими возможностями, как защищенные ветви, помогает командам быстро приступить к работе после внедрения GitHub.
Для проектов с открытым кодом или проектов, в которых могут участвовать любые пользователи, управление отдельными разрешениями может быть непростой задачей. В этом случае удобнее модель на основе вилок и вытягивания, которая позволяет всем, кто может просматривать проект, принимать участие в нем. Вилка — это копия проекта в личной учетной записи разработчика. Каждый разработчик имеет полный контроль над вилкой и может свободно реализовывать исправление или новую функцию. Результаты работы в вилках либо хранятся отдельно, либо переносятся обратно в исходный проект с помощью запроса на вытягивание. Лица, ответственные за проект, могут проверять предлагаемые изменения перед их слиянием. Дополнительные сведения см. в разделе «AUTOTITLE».
A3.3 Приложение C: Команды Git — Основные команды
Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.
git add
Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. Ниже перечислены наиболее интересные варианты использования этой команды.
Знакомство с этой командой происходит в разделе Отслеживание новых файлов главы 2.
О том как использовать git add для разрешения конфликтов слияния написано в разделе Основные конфликты слияния главы 3.
В разделе Интерактивное индексирование главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.
В разделе Деревья показано как эта команда работает на низком уровне, чтобы вы понимали, что происходит за кулисами.
git status
Команда git status показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
Мы познакомили вас с этой командой в разделе Определение состояния файлов главы 2, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.
git diff
Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей копией и индексом (собственно git diff ), разница между индексом и последним коммитом ( git diff —staged ), или между любыми двумя коммитами ( git diff master branchB ).
Мы познакомили вас с основами этой команды в разделе Просмотр индексированных и неиндексированных изменений главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.
О том как использовать эту команду для проверки на проблемы с пробелами с помощью аргумента —check можно почитать в разделе Правила создания коммитов главы 5.
Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…B в разделе Определение применяемых изменений главы 5.
В разделе Продвинутое слияние главы 7 показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями —theirs , —ours и —base .
Использование этой команды с опцией —submodule для сравнения изменений в подмодулях показано в разделе Начало работы с подмодулями главы 7.
git difftool
Команда git difftool просто запускает внешнюю утилиту сравнения для показа различий в двух деревьях, на случай если вы хотите использовать что-либо отличное от встроенного просмотрщика git diff .
Мы лишь вкратце упомянули о ней в разделе Просмотр индексированных и неиндексированных изменений главы 2.
git commit
Команда git commit берёт все данные, добавленные в индекс с помощью git add , и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.
Вы познакомились с основами модели коммитов в разделе Коммит изменений главы 2. Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add , что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.
В разделе Операции отмены главы 2 мы рассказали об опции —amend , используемой для изменения последнего совершённого коммита.
В разделе О ветвлении в двух словах главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.
Мы показали вам как подписывать ваши коммиты, используя опцию -S в разделе Подпись коммитов главы 7.
И наконец мы заглянули внутрь команды git commit в разделе Объекты коммитов главы 10 и узнали что она делает за кулисами.
git reset
Команда git reset , как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочем каталоге при использовании параметра —hard , что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.
Мы рассказали об основах использования git reset в разделе Отмена индексации файла главы 2, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью git add .
В разделе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.
Мы использовали git reset —hard чтобы отменить слияние в разделе Прерывание слияния главы 7, там же было продемонстрировано использование команды git merge —abort для этих целей, которая работает как обёртка над git reset .
git rm
Команда git rm используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
Мы немного разобрались с этой командой в разделе Удаление файлов главы 2, показали как удалять файлы из рабочего каталога и индекса и только из индекса, используя флаг —cached .
Ещё один вариант использования git rm приведён в разделе Удаление объектов главы 10, где мы вкратце объяснили как использовать опцию —ignore-unmatch при выполнении git filter-branch , которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов.
git mv
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
Мы лишь вкратце упомянули эту команду в разделе Перемещение файлов главы 2.
git clean
Команда git clean используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Мы рассмотрели множество опций и сценариев использования этой команды в разделе Очистка рабочего каталога главы 7.
Для чего нужна команда git status
Чтобы освоить Git и пользоваться им через командную строку, Вам необходимо освоить несколько команд. С их помощью Вы будете добавлять файлы, удалить файлы, изменять файлы и т.д. Но иногда Вам нужно будет проверить, сработала ли та или иная команда, или в общем понять, что Вы там «наделали» �� В этом Вам поможет команда git status.
С англ. status в данном случае так и переводится — «статус». То есть Вы можете посмотреть текущее состояние Вашего репозитория.
Итак, что можно проверить:
- Является ли папка Git репозиторием («есть» ли в ней Git) или нет. Например, если мы зайдем на Рабочий стол и напишем «git status»:
выводится сообщение об ошибке («Не является Git репозиторием, а также ни одна из материнских папок не является Git репозиторием»).
- Если же мы находимся в Git папке, увидим что-то подобное:
- Мы можем просматривать, какие файлы были добавлены или изменены. Например, если у нас появится новый файл, он будет отображаться красным:
- Если Git начнет за ним «следить», файл станет зеленым:
- Если мы поменяем файл file.txt (например, допишем одну строчку), то git status об этом нам сообщит (напротив файла написано modified — «изменено»):
- Если файл удалить, это тоже отобразится (напротив файла написано deleted — «удалено»):
Отлично! �� Теперь Вы знаете, что делает git status. Это важная команда — ее стоит запомнить!
Спасибо, что были с нами! ��
Надеемся, что наша статья была Вам полезна. Можно записаться к нам на курсы по Java на сайте.
- ← Команда git clone
- Основы работы с командной строкой (Терминалом) на Mac OS X →
Git status что делает
Рисунок 10 – Вызов git status после выполнения команды git add
Видим, что теперь текст сообщения несколько изменился. Строка с названием нашего тестового файла изменилась. Ранее она была выделена красным цветом (рисунок 7).
Сейчас же эта строка выделена зеленым цветом и добавилась приставка «new file: test_project.py». Это означает, что теперь git начал следить за изменениями этого файла, но пока мы их не зафиксировали. Другими словами, git увидел файл и готов зафиксировать это изменение. Для этого нам надо выполнить коммит (commit).
Шаг 4. Создаем коммит
Чтобы выполнить коммит, выполним следующую команду:
git commit –m «текст сообщения – начинаем использовать git!».
На рисунке 11 видим, что git обработал нашу команду и вернул результат, в котором сказано, что в ветке master изменен 1 файл, в нем добавлено 26 строк.
Рисунок 11 – Создание первого коммита
Другими словами, до того как мы добавили файл (git add) и создали коммит (git commit), нашей системе git нечего было отследживать, поскольку в нем не было ни одного коммита. Теперь немного остановимся на самой команде «git commit».
После команды git commit мы использовали параметр –m и в кавычках » » написали текст.
Это очень полезная фишка для комментирования изменений кода. Например, мы добавили в код новую функцию или исправили ошибку в работе программы и хотим зафиксировать это улучшение, кратко сформулировав смысл вносимых изменений в код. Сейчас в нашем проекте «test_project.py» нет проверок корректности данных, как и проверки наличия связи с удаленным сервером погоды (OpenWeatherMap).
Когда мы дабавим проверку корректности данных, нужно будет создать коммит и в качестве комментария указать:
«Добавлена проверка кода ответа от сервера OpenWeatherMap. Если код ответа: 200, данные корректны, в другом случае возникает обарботки исключительной ситуации».
Конечно, помимо сообщения при создании коммита рекомендуется использовать комментарии в коде программы и вести документацию.
Для отслеживания всех изменений git удобно использовать утилиту git-show — это утилита командной строки, которая используется для просмотра подробных данных об объектах Git (рисунок 12).
Рисунок 12 – Отображение подробной информации вызовом команды git show —pretty
Что делать, если ошибочно внесли неполное или некорректное описание коммита?
На этот случай не стоит паниковать. Всегда можно изменить содержание коммита.
Чтобы изменить последний коммит, используйте комманду: git commit –amend. После вызова команды откроется текстовый редактор, в котором можно изменить текст сообщения (рисунок 13).
Рисунок 13 – Окно редактора текста, в котором можно изменить последний коммит
После того, как вы внесете изменения в текст коммита, нужно сохранить изменения в этом файле. После этого в консоли отобразится «новое сообщение» измененного коммита (рисунок 14).
Рисунок 14 – Отображение изменений коммита
Попробуйте внести изменения в файл «test_project.py». Например, изменив его следующим образом:
import requests import sqlite3 # Connect to the SQLite database conn = sqlite3.connect("example.db") cursor = conn.cursor() # Create a table to store the data cursor.execute("""CREATE TABLE IF NOT EXISTS weather (id INTEGER PRIMARY KEY, city TEXT, temperature REAL)""") # Make a request to the API try: Response = requests.get("https://api.openweathermap.org/data/2.5/weather?q=London&appid=your_api_key") Response.raise_for_status() data = response.json() # Extract the relevant data city = data["name"] temperature = data["main"]["temp"] # Insert the data into the table cursor.execute("INSERT INTO weather (city, temperature) VALUES (?, ?)", (city, temperature)) # Commit the changes to the database conn.commit() # Close the connection to the database conn.close() except requests.exceptions.HTTPError as err: print(err):
Мы добавили в код проверку возникновения исключительных событий. Исключения необходимы для того, чтобы сообщать программисту об ошибках, а также корректно их обрабатывать, чтобы избавиться от экстренного завершения работы программы.
Практическое задание:
· сохраните изменения в файле с кодом и вызовите команду git status;
· посмотрите на результат;
· как применить эти изменения в системе git?
· создайте новый коммит, чтобы зафиксировать это изменение
Вот несколько шагов, которые помогут начать работу с Git:
Изучите основы: начните с изучения основных команд Git, таких как «git init», «git add», «git commit», «git branch», «git checkout», «git merge» и «git push».
В Интернете есть множество ресурсов, таких как учебные пособия, видеоролики и документация, которые могут помочь понять основные концепции и команды.
Лучший способ изучить Git – это использовать его. Создайте новый проект, возьмите наш тестовый проект или найдите проект с открытым исходным кодом и начните экспериментировать с командами Git. Совершайте коммиты, создавайте ветки и пробуйте разные сценарии рабочего процесса Git.
Что такое публичный и приватный репозиторий?
В Git репозиторий (или сокращенно «репо») — это набор файлов и каталогов, которые отслеживаются системой контроля версий. Репозиторий может быть как общедоступным, так и частным.
1. Общедоступный репозиторий — это репозиторий, доступный для всех, у кого есть URL-адрес репозитория. Любой может просмотреть файлы, загрузить их и сделать копию репозитория. Публичные репозитории часто используются для проектов с открытым исходным кодом, где каждый может внести свой вклад в код. Публичные репозитории также используются для обмена кодом с другими или для того, чтобы сделать код доступным для использования другими.
2. Частный репозиторий — это тот, который недоступен никому, кроме людей, которым был предоставлен доступ. Эти репозитории часто используются для проектов с закрытым исходным кодом, где код не предназначен для общего доступа. Частные репозитории также используются для хранения кода, который не готов к публичному выпуску, или для конфиденциальной информации, которой не следует делиться с общественностью.
Основное различие между двумя типами репозиториев заключается в том, что общедоступные репозитории видны и доступны всем, а частные репозитории видны и доступны только избранной группе людей.
Стоит отметить, что большинство служб хостинга Git, таких как GitHub, GitLab, Bitbucket, предлагают как общедоступные, так и частные репозитории с разными ценами и ограничениями, некоторые из них предлагают бесплатные планы для общедоступных репозиториев и взимают плату за частные.
В Git репозиторий (или для краткости «repo») — это набор файлов, каталогов и истории их версий. В Git есть два типа репозиториев: общедоступные и частные.
3. Публичный репозиторий – это репозиторий, доступный для всех. Любой может просматривать, клонировать и вносить свой вклад в код в общедоступном репозитории. Публичные репозитории обычно используются для проектов с открытым исходным кодом, где код предназначен для совместного использования и использования широким сообществом разработчиков.
4. Частный репозиторий – это репозиторий, доступный только для определенной группы людей. Только авторизованные пользователи могут просматривать, клонировать и вносить свой вклад в код в частном репозитории. Частные репозитории обычно используются для проектов с закрытым исходным кодом или для проектов, которые не предназначены для общего доступа.
GitHub, GitLab и Bitbucket — популярные платформы хостинга Git, которые предоставляют как общедоступные, так и частные репозитории. На этих платформах вы можете сделать свой репозиторий общедоступным или частным при его создании. Вы также можете изменить видимость репозитория позже, но изменить его обратно может быть немного сложнее, если он общедоступный.
Важно помнить, что термины «общедоступные» и «частные» репозитории относятся к хостинговой платформе и пользователям, имеющим доступ к репозиторию, а не к Интернету в целом.
Статистика использования git
Git – одна из наиболее широко используемых систем контроля версий в мире, и статистика ее использования отражает это. Вот некоторая статистика использования Git:
1. Популярность. Согласно опросу разработчиков Stack Overflow 2020, Git – самая популярная система контроля версий, которую используют более 88% разработчиков.
2. Проекты с открытым исходным кодом. По данным GitHub, на их платформе размещено более 100 миллионов репозиториев, и большинство из них представляют собой проекты с открытым исходным кодом, использующие Git в качестве системы контроля версий.
3. Использование в отрасли: Git используется в самых разных отраслях, включая разработку программного обеспечения, финансы, здравоохранение и правительство.
4. Кроссплатформенность: Git можно использовать в операционных системах Windows, Mac и Linux, что делает его кроссплатформенным инструментом.
5. Интеграция: Git можно интегрировать с широким спектром инструментов и сервисов, таких как GitHub, GitLab, Bitbucket, Jenkins и другими.
6. Совместная работа: Git позволяет нескольким людям одновременно работать над одной кодовой базой и имеет встроенные инструменты для совместной работы, такие как запросы на вытягивание и проверки кода.
7. Принятие: согласно официальному веб-сайту Git, более 100 000 организаций по всему миру используют Git для контроля версий.
Эти статистические данные показывают, что Git является широко распространенным и универсальным инструментом, который используется большим количеством разработчиков и организаций по всему миру.