Как пользоваться git для начинающих

Шаг 1: Зарегистрируйтесь и установите!

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

Теперь зайдите в свой терминал и представьтесь Git! Чтобы установить ваше имя пользователя длякаждый репозиторийна вашем компьютере введите

git config --global user.name "<your_name_here>"

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

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

git config --global user.email "<>"

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

Теперь вы готовы начать использовать Git на своем компьютере!

фотоМэтти АдамнаUnsplash

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

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

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

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

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий

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

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

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

Допустим, вы хотите создать новый репозиторий. Это место, где будет «жить » ваш проект. Если вы не хотите создавать новый репозиторий, то можете склонировать уже существующий. Именно так вы копируете чужой проект или берете нужную вам информацию для работы/учебы. Мы еще к этому вернемся, но чуть позже.

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

Лучше сразу добавлять в репозиторий README-файл с информацией о проекте. Это можно сделать в момент создания репозитория, поставив галочку в соответствующем поле.

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла

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

Новый репозиторий

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

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

• Для начала перейдите в ваш репозиторий.
• Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
• В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
• Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
• Нажмите кнопку Commit changes.

Изменение файла на GitHub

Подготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request

Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

Сотрудничество

В классических хранилищах исходного кода всегда есть четкое указание на то, что это за ветвь; она находится в центральном репозитории.

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

Рисунок 10. Два репозитория

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

При выгрузке ветви, которая существует только как ветвь дистанционного отслеживания (но не как локальная ветвь), Git автоматически создает локальную ветвь из ветви дистанционного отслеживания и выгружает ее.

После этого можно объединить содержимое удаленной ветви и своей собственной. На рисунке 11 показан процесс выгрузки удаленной ветви в локальную ветвь master, но это не обязательно, ее можно слить с любой другой ветвью с общей историей, например, с помощью обычной команды merge.

Рисунок 11. Извлечение и выгрузка удаленной ветви

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

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

Рисунок 12. Получение удаленных изменений

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

Команда удобна тем, что выполняет оба действия и .

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

Рисунок 13. Публикация изменения

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

Обратите внимание, что в таких случаях можно выполнить обычное слияние, а можно – слияние со смещением для переноса изменений из локальной ветви в новую, отредактированную вершину удаленной ветви. Помимо команд fetch и push, есть еще один способ распространения изменений; старая добрая почта

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

Помимо команд fetch и push, есть еще один способ распространения изменений; старая добрая почта. Существует команда , которая создаёт файл изменений для каждого коммита, ведущий от данного коммита к текущему состоянию ветви. Команда применяет эти файлы изменений к текущей ветви.

Предостережения

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

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

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

Создание проекта

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:

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

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

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

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

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

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Install Git on Windows

1. Navigate to the latest Git for Windows installer and download the latest version.
2. Once the installer has started, follow the instructions as provided in the Git Setup wizard screen until the installation is complete.
3. Open the windows command prompt (or Git Bash if you selected not to use the standard Git Windows Command Prompt during the Git installation).
4. Type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git for Windows. The advantage of downloading Git from is that your download automatically starts with the latest version of Git included with the recommended command prompt, . The download source is the same Git for Windows installer as referenced in the steps above.

Видео

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

Если у вас есть директория проекта, то просто перейдите в терминал, а в самой директории проекта выполните команду

git init

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

git init

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

cd new_projectgit init

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

git add <имя_первого_файла>

или добавьте сразу все файлы через:

git add .

Создать коммит с этими изменениями можно через команду:

git commit -m “<сообщение_коммита>”

Если изменения вас устраивают, напишите:

git push

и отправьте эти изменения в репозиторий. Проверить, есть ли изменения для отправки, можно в любое время по команде:

git status

При внесении изменений следует обновить и сами файлы:

git add <имя_файла>

или

git add — all

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

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

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

Ummmmm … что? Могу ли я сделать это на сайте?

Вы можете!

GIF черезGIPHY

Один из способов сделать это — просто проверить кнопку, о которой мы упоминали ранее, когда редактировали файл README. Супер просто!

Вы также можете в любое время создать новую ветку прямо на веб-сайте, перейдя в свой репозиторий, щелкнув раскрывающееся меню в левой и средней части экрана с надписью «Branch: master», введя имя ветви и выбрав Ссылка «Создать ветку» (или нажмите Enter на клавиатуре). Теперь у вас есть две ветви, которые выглядят одинаково! Это отличное место для внесения изменений и их тестирования, прежде чем вы захотите, чтобы они повлияли на основную ветку.

Создание ветки

Если вы работаете с отдельной веткой, ваши изменения влияют только на эту ветку.

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

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

• Нажмите вкладку запроса на извлечение рядом с верхним центром экрана.
• Нажмите зеленую кнопку «Новый запрос на извлечение»
• Перейдите в поле «Примеры сравнений» и выберите ветку, которую вы сделали, чтобы сравнить с исходной веткой.
• Посмотрите свои изменения, чтобы убедиться, что они действительно то, что вы хотите зафиксировать.
• Затем нажмите большую зеленую кнопку «Создать запрос на извлечение». Дайте ему название и напишите краткое описание ваших изменений. Затем нажмите «Создать запрос на извлечение!»

Новый запрос на извлечение
Создать пул-запрос

Теперь, если это ваш репозиторий, вы можете объединить ваш запрос на извлечение, нажав зеленую кнопку «Слить запрос на извлечение», чтобы объединить изменения в мастер. Нажмите «Подтвердить слияние», затем удалите ветвь после того, как ваша ветвь была включена с помощью кнопки «Удалить ветвь» в фиолетовом поле.

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

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

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

Создать репозиторий можно двумя способами:

• на сайте;
• через GitHub Desktop.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

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

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

• GNU GPL;
• MIT;
• Unlicense;
• WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Далее нажимаем на зеленую кнопку Create repository. Вы увидите список файлов в своем репозитории (пока это только автоматически сгенерированный файл README с описанием проекта) и содержание README, если он есть, а также файлы .gitignore и LICENSE, если они создавались. Ссылка на репозиторий будет выглядеть так: https://github.com/username/your_repo_name.git .