Git основы: Git за полчаса: руководство для начинающих

Основы Git за 5 минут. Git — штука таинственная и непонятная… | by Olga Sayfudinova | NOP::Nuances of Programming

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

Допустим, вы захотели клонировать репозиторий со скриншота, представленного выше. Для начала скопируйте ссылку клонирования (см. выше). Затем откройте терминал и через cd перейдите в область на компьютере, куда будут копироваться файлы. Если вы хотите клонировать ветку master, то напечатайте git clone и вставьте ссылку, как это показано ниже:

git clone https://github.com/JamesOkunlade/old-apple.git

Для клонирования определенной ветки репозитория сделайте следующее:

git clone https://github.com/JamesOkunlade/old-apple.git -b branch-name

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

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

Если ветка уже создана:

git checkout branch-name

Если вы создаете новую ветку опций:

git checkout -b branch-name

Ваша команда или коллега-разработчик могут изменять ветки репозитория. И каждый раз перед написанием кода вы должны вливать эти изменения в ветку, с которой будете работать. Перейдите в ветку через checkout и выполните команду git pull. Последние изменения будут влиты в локальный репозиторий.

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

Для захвата всех файлов (кроме исключений изgit ignore) понадобится git add. Захват текущего состояния отдельно взятого файла (к примеру, index.html) делается через git add index.html.

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

git commit -m ‘commit message’

Сообщение в коммите должно пояснить специфику сохраняемых снимков. Например:

git add index.html

git commit -m ‘создание кнопки формы опции’

Две команды можно объединить через оператор&&:

git add index.html && git commit -m ‘создание html структуры футера’

git stash сохранит все изменения ветки, которые вы не хотите коммитить. Это значит, что вы можете ждать, пока другой разработчик закоммитит и вольет копию своих изменений в ветку, и параллельно экспериментировать с той же веткой. Git всячески это приветствует. Если вы хотите просто влить новые изменения в локальный репозиторий, но не выполнять слияния с веткой, то просто сохраните эти изменения черезstash. git stash сохранит копию этих изменений. Их можно будет просмотреть через список git stash.

git merge – это команда, которая сливает два разных снимка репозитория. Вы можете сливать разные снимки изменений одной и той же ветви, сделанные разными разработчиками. Либо же можно сливать разные снимки разных веток.

При переходе в ветку master команда git merge сливает ветку dev с master и наоборот.

По аналогии с тем, как вы сохраняете снимки в Google Фото, и их видят другие люди, имеющие доступ, git push отправляет локальный репозиторий на сервер, доступный другим пользователям.

git push -u origin branch-name

Перевод статьи James Okunlade: The essentials of Git explained in five minutes

Основы работы с Git. Базовые команды

Ранее мы писали о том, как установить и настроить Git на Windows и Linux. В этой статье мы рассмотрим основные команды для работы с Git.  Специалисты компании HyperHost ежедневно работают с репозиториями, поэтому инструкция без “воды” только нужная информация.

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

Схематически этот процесс можно представить так как на рисунку ниже.

1.  И так, начать нужно с создания нового репозитория (не забываем, что нужно создавать рабочую директорию и открывать Bash в том же месте, где находится папка Git), для этого вводим в терминале команду:

git init

После этого появляется скрытая папка .

Для просмотра текущего состояния файлов и локального репозитория в целом,  в терминале нужно ввести команду:

git status

На скрине показаны состояние файлов:

new file -это файлы, которые только что проиндексировали (под контролем Git),

deleted — это файлы, которые были удалены с локального репозитория, 

modified -это файлы, которые были изменены, но их изменение еще не были зафиксированы,

untracked files -это файлы которые еще не проиндексированы (не под контролем Git).

2.Для добавления файлов под контроль Git нужно для начала  проиндексировать файлы:

 git add article.rtf

где article.rtf — файл, который хотим проиндексировать.

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

 git add .

3.Для фиксации индексированных изменений:

git commit -m “Комментарий к коммиту”

Очень удобно если Вы хотите сразу и добавить файлы в индекс и зафиксировать изменения, то это можно сделать не 2-мя, а одной командой :

git commit -a -m “Комментарий к коммиту”

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

  git remote add test URL

где test — названия Вашего репозитория, 

URL — URL-адрес Вашего репозитория.

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

git remote -v

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

git clone URL

5.Для заливки информации в удаленный репозиторий (например: GitHub, Bitbucket и т. д.) введите команду:

 git push

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

Для большей наглядности мы в удаленному репозитории в файл t2.txt, в котором внутри находилось ‘mariachange’ изменили на ‘ mariachange2’

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

 git fetch

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

Для того чтобы  они появились нужно после  git fetch ввести команду:

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

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

git log

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

git show 6441b05a802163b77c9d6f39f4fed7c44d925893

 где 6441b05a802163b77c9d6f39f4fed7c44d925893 — id коммита (смотрим по логам)

На скрине сделан вывод, что мы делали в коммите 6441b05a802163b77c9d6f39f4fed7c44d925893, для большей наглядности взят последний коммит, где  в файле t2. txt к содержимому ‘mariachange’ была добавлена цифра 2.

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

git diff

Удалить файл с репозитория:

git rm photo1.png

где photo1.png — файл который хотите удалить.

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

Создать ветку можно командой:

git branch test

где test -название ветки

Просмотр всех веток:

git branch -v

Зеленым цветом выделяется ветка, на который мы сейчас работаем.

Чтобы  переключится с одной ветки на другую:

 git checkout test

Переключение с ветки master на test.

Для удаление ветки (локально):

git branch -d article

где article -название ветки.

Чтобы удалить ветку на удаленном сервере:

git push origin :test

где origin — название удалённого репозитория

test — название ветки.

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

git merge test

Слияние текущей ветки с веткой test.

Далее разберем как сделать откат файла до определенного состояния. В качестве примера используем файл t2.txt в котором находится содержимое ‘mariachange2’ (состояние при коммите 6441b05a802163b77c9d6f39f4fed7c44d925893)добавляем содержимое ‘откат файла до определенного состояния’ и делаем коммит с комментарием ‘2’, также добавляем слово ‘коммит’ и также фиксируем изменения с комментарием ‘3’. Все эти изменения заливаем в удаленный репозиторий.

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

git checkout 6441b05a802163b77c9d6f39f4fed7c44d925893 t2.txt

где 6441b05a802163b77c9d6f39f4fed7c44d925893 — id коммита

t2. txt — файл в котором делается откат.

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

Команда ГиперХост  желает продуктивной и приятной работы с Git.

Основы работы с Git — Разработка на vc.ru

{«id»:217955,»url»:»https:\/\/vc.ru\/dev\/217955-osnovy-raboty-s-git»,»title»:»\u041e\u0441\u043d\u043e\u0432\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Git»,»services»:{«facebook»:{«url»:»https:\/\/www.facebook.com\/sharer\/sharer.php?u=https:\/\/vc.ru\/dev\/217955-osnovy-raboty-s-git»,»short_name»:»FB»,»title»:»Facebook»,»width»:600,»height»:450},»vkontakte»:{«url»:»https:\/\/vk.com\/share.php?url=https:\/\/vc.ru\/dev\/217955-osnovy-raboty-s-git&title=\u041e\u0441\u043d\u043e\u0432\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Git»,»short_name»:»VK»,»title»:»\u0412\u041a\u043e\u043d\u0442\u0430\u043a\u0442\u0435″,»width»:600,»height»:450},»twitter»:{«url»:»https:\/\/twitter.

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

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

Этап 1. Проверка ветки

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

Если увидели этот результат, то притормозите!

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

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

Итак, что же следует делать, если вы находитесь на ветке master?

Этап 2. Переключение на новую ветку

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

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

Этап 3. Написание кода

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

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

Этап 4. Просмотр статуса

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

Если все в полном порядке, то для индексации этих изменений просто введите в терминал следующую команду:

Зеленый цвет файлов означает, что изменения были проиндексированы:

Этап 5. Создание коммита

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

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

git commit -m “useful info about the code I wrote”.

Флаг -m указывает команде git commit, что вы добавляете полезный комментарий о коде. Итак, его уже можно отправлять, но прежде немного задержимся еще на одном этапе.

Этап 6. Проверка ветки

Догадываюсь, что вас не обрадует предложение по нескольку раз вводить в терминал команду git branch. Но так надо. Проверим дважды — от нас не убудет. Затовы избавите себя от необходимости запоминать имена веток, поскольку за вас это сделает инструмент!

Этап 7. Отправка

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

Вы увидите нечто подобное:

Если вы используете VScode, то эта команда + клик на http-адрес перенесут вас на этап 8. И вот ваша ветка запущена в эфир!

Этап 8. Запросы на слияние

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

Кликните на Pull request для активации процесса

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

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

Этап 9. Лицом к лицу с master

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

Если все сработало, то вы увидите эти зеленые строки плюсов:

Этап 10. Итоги

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

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

Основы Git за 5 минут

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

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

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

Вот о чем поговорим:

1. Git clone.
2. Git checkout.
3. Git pull.
4. Git add и commit.
5. Git stash и merge.
6. Git push.

Git clone

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

Допустим, вы захотели клонировать репозиторий со скриншота, представленного выше. Для начала скопируйте ссылку клонирования (см. выше). Затем откройте терминал и через cd перейдите в область на компьютере, куда будут копироваться файлы. Если вы хотите клонировать ветку master, то напечатайте git clone и вставьте ссылку, как это показано ниже:

git clone https://github.com/JamesOkunlade/old-apple.git

Для клонирования определенной ветки репозитория сделайте следующее:

git clone https://github.com/JamesOkunlade/old-apple.git -b branch-name

Git checkout

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

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

Если ветка уже создана:

git checkout branch-name

Если вы создаете новую ветку опций:

git checkout -b branch-name

Git pull

Ваша команда или коллега-разработчик могут изменять ветки репозитория. И каждый раз перед написанием кода вы должны вливать эти изменения в ветку, с которой будете работать. Перейдите в ветку через checkout и выполните команду git pull. Последние изменения будут влиты в локальный репозиторий.

Git add и commit

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

Для захвата всех файлов (кроме исключений изgit ignore) понадобится git add. Захват текущего состояния отдельно взятого файла (к примеру, index.html) делается через git add index.html.

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

git commit -m ‘commit message’

Сообщение в коммите должно пояснить специфику сохраняемых снимков. Например:

git add index.html

git commit -m ‘создание кнопки формы опции’

Две команды можно объединить через оператор&&:

git add index.html && git commit -m ‘создание html структуры футера’

Git stash и merge

git stash сохранит все изменения ветки, которые вы не хотите коммитить. Это значит, что вы можете ждать, пока другой разработчик закоммитит и вольет копию своих изменений в ветку, и параллельно экспериментировать с той же веткой. Git всячески это приветствует. Если вы хотите просто влить новые изменения в локальный репозиторий, но не выполнять слияния с веткой, то просто сохраните эти изменения черезstash. git stash сохранит копию этих изменений. Их можно будет просмотреть через список git stash.

git merge – это команда, которая сливает два разных снимка репозитория. Вы можете сливать разные снимки изменений одной и той же ветви, сделанные разными разработчиками. Либо же можно сливать разные снимки разных веток.

При переходе в ветку master команда git merge сливает ветку dev с master и наоборот.

Git push

По аналогии с тем, как вы сохраняете снимки в Google Фото, и их видят другие люди, имеющие доступ, git push отправляет локальный репозиторий на сервер, доступный другим пользователям.

git push -u origin branch-name

Перевод статьи James Okunlade: The essentials of Git explained in five minutes

Основы Git — Python для сетевых инженеров

О Git

Система контроля версий (Version Control System, VCS):

• отслеживает изменения в файлах
• хранит несколько версий одного файла
• позволяет откатить изменения
• знает кто и когда сделал изменения

Git:

• распределенная система контроля версий
• широко используется
• выпущен под лицензией GNU GPL v2

Git хранит изменения как snapshot всего репозитория. Этот snapshot выполняется после каждого commit.

Файл в Git может быть в таких состояниях:

• committed — файл сохранен в локальной базе
• modified — файл был изменен, но еще не сохранен в локальной базе
• staged — файл отмечен на добавление в следующий commit

Соответственно, есть три основные части проекта Git:

• каталог Git (.git) — тут хранятся метаданные и база данных объектов проект
• рабочий каталог — копия определённой версии проекта
• область подготовленных файлов (staging area) — информация о том, что должно попасть в следующий commit

Установка Git

Установка Git

$ sudo apt-get install git

Первичная настройка Git

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

$ git config --global user.name "pyneng"
$ git config --global user.email "pyneng.course@gmail. com"

Посмотреть настройки можно таким образом:

Инициализация репозитория

Создадим с нуля репозиторий Git.

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

[~/tools]
$ mkdir first_repo

И перейти в него:

[~/tools]
$ cd first_repo

Теперь, в новом каталоге необходимо дать команду git init:

[~/tools/first_repo]
$ git init
Initialized empty Git repository in /home/vagrant/tools/first_repo/.git/

После этой команды, в каталоге создается каталог .git, в котором содержится вся информация, которая необходима для работы Git.

Отображение статуса репозитория в командной строке (только для Linux/Mac OS)

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

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

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

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

cd ~
git clone https://github.com/magicmonty/bash-git-prompt.git .bash-git-prompt --depth=1

А затем добавить в конец файла ~/.bashrc такие строки:

GIT_PROMPT_ONLY_IN_REPO=1
source ~/.bash-git-prompt/gitprompt.sh

Для того чтобы изменения применились, перезапустить bash:

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

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

[~]
vagrant@jessie-i386:
$ 

Если же перейти в репозиторий Git:

Работа с Git

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

git status

Для этого в Git есть команда git status:

Git сообщает, что мы находимся в ветке master (эта ветка создается сама и используется по умолчанию) и что ему нечего добавлять в commit. Кроме этого, git предлагает создать или скопировать файлы и после этого воспользоваться командой git add, чтобы git начал за ними следить.

Создадим первый файл README и добавим в него пару произвольных строк текста:

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

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

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

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

. gitignore

.README.un~ — это служебный файл, который не нужно добавлять в репозиторий.

В git есть возможность сказать, что какие-то файлы или каталоги нужно игнорировать. Для этого, надо указать соответствующие шаблоны в файле .gitignore в текущем каталоге:

Для того чтобы git игнорировал undo файлы vim, можно добавить, например, такую строку в файл .gitignore:

Это значит, что Git должен игнорировать все файлы, которые заканчиваются на .un~.

После этого, git status показывает:

Обратите внимание, что теперь в выводе нет файла .README.un~. Как только в репозитории добавлен файл .gitignore, файлы, которые указаны в нем, игнорируются.

git add

Для того чтобы Git начал следить за файлами, используется команда git add.

Можно указать, что надо следить за конкретным файлом:

Или за всеми файлами:

Проверим как теперь выглядит вывод git status:

Теперь файлы находятся в секции “Changes to be committed”.

git commit

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

У команды git commit есть только один обязательный параметр — флаг -m. Он позволяет указать сообщение для этого коммита:

После этого, git status отображает:

Фраза “working directory clean” обозначает, что нет изменений, которые нужно добавить в Git или закоммитить.

Дополнительные возможности git

git diff

Команда git diff позволяет просмотреть разницу между различными состояниями.

Например, внесем изменения в файл README и .gitignore, но не будем добавлять их в репозиторий. Команда git status показывает, что оба файла изменены:

Если дать команду git diff, она покажет внесенные изменения:

То есть, команда git diff показывает какие изменения были внесены с последнего коммита.

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

Чтобы показать отличия между staging и последним коммитом, надо добавить параметр –staged:

Закоммитим изменения:

git log

Иногда нужно посмотреть когда были выполнены последние изменения. В этом поможет команда git log:

По умолчанию команда показывает все коммиты, начиная с самого свежего.

С помощью дополнительных параметров, можно не только посмотреть информацию о коммитах, но и какие изменения были внесены. Флаг -p позволяет отобразить отличия, которые были внесены каждым коммитом:

Более короткий вариант вывода можно вывести с флагом --stat:

Дополнительная информация

Мы рассмотрели далеко не все возможности Git. Это лишь базовый минимум, который позволит начать с ним работать.

Дополнительные ресурсы, которые позволят глубже познакомиться с Git:

Основы Git || CodenameCRUD — бесплатное обучение веб-разработке

Мы упомянули Git в курсе Введение в веб-разработку и у вас была возможность использовать его в работе в курсе Rails project, а сейчас настало время копнуть поглубже и понять, что именно из себя представляет Git.

Посмотрите хороший обзор Git, где даны примеры команд с пояснениями. Далее ответьте на вопросы.

Пункты для размышления

Просмотрите вопросы и проверьте, знаете ли на них ответы. Проверьте себя снова после выполнения задания.

• Что такое Git?
• Что такое SCM?
• Что такое VCS?
• Зачем Git нужен разработчику?
• Зачем Git нужен команде разработчиков?
• Как создать локальный репозиторий Git для проекта?
• Как его создать на Github?
• Как выполнить commit для внесенных изменений?
• Чем отличается внесение файла в буфер (staging) от фиксации изменений (committing changes)?
• Какая разница между командами commit и push?
• Как проверить статус репозитория в git?
• Как посмотреть историю коммитов (из командной строки)?
• Как это сделать на сайте Github?
• Что такое «Merge»?
• Что такое «Pull Request»?
• Для чего предназначена команда «fork» ?
• Для чего предназначена команда «clone» ?

Задания:

1. Если еще не видели, посмотрите видео с канала Github на Youtube:

   1. Основы Git #1: Что такое VCS? ознакомит вас с контролем версий ПО и необходимостью этого функционала для разработчика.
   2. Основы Git #2: Что такое Git? введет вас в курс процессов, происходящих в Git.
   3. Основы Git #3: Начало работы. Здесь показана инсталляция Git. Скорее всего вы уже установили Git на своем компьютере, в этом случае нет необходимости проводить повторную установку.
   4. Обзор: Основы Git и GitHub содержит более последовательную и цельную информацию о процессах, протекающих в Git. Терминология будет несколько специфичной и будет охватывать довольно обширную область; постарайтесь впитать информацию, она пригодится в будущем. В материале также содержится информация о некоторых полезных файлах помощи и инструментах, используемых для визуализации процессов Git.

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

3. Выполните также короткое упражнение по Git.

Дополнительные ресурсы

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

Поделиться уроком:

Работа с Git через консоль — Блог HTML Academy

Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу.

Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.

Полезные материалы по Git

Система контроля версий Git

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

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

Git — важный навык веб-разработчика

А лучший способ научиться программировать — профессия «React-разработчик». В программе три интенсива, прокачка навыков и оплачиваемая стажировка.

Устанавливаем Git

Если раньше вы не работали с Git, сперва его нужно установить. Способы зависят от операционной системы вашего компьютера.

Установка в Linux

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

• Если у вас 21 или более ранняя версия Fedora, используйте yum install git.
• Для 22 и последующих версий Fedora вводите dnf install git.
• Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git.

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

Установка на macOS

1. Скачиваем Git со страницы проекта.
2. Запускаем загруженный файл.
3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя: git config --global user.name "ваше имя"

Для добавления почтового адреса вводите: git config --global user.email адрес

Обратите внимание, что в командах, указанных выше, есть опция --global. Это значит, что такие данные будут сохранены для всех ваших действий в Git и вводить их больше не надо. Если вы хотите менять эту информацию для разных проектов, то в директории проекта вводите эти же команды, только без опции --global.

Регистрация на GitHub

Что такое GitHub?

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

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

1. Переходим на сайт GitHub. Cтартовая страница GitHub.
2. Для начала регистрации:
   • Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей проходим верификацию. Первый шаг регистрации профиля на стартовой странице GitHub.
   • После заполнения данных и успешного прохождения верификации нажимаем на кнопку Select a plan. Второй шаг регистрации профиля на стартовой странице GitHub.
3. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
4. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Подтверждение электронного адреса.
5. После верификации GitHub предложит создать новый репозиторий, организацию или узнать больше о GitHub. Этот пункт пока можно пропустить и перейти в профиль. Переход в ваш профиль.Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге ~/.ssh, поэтому нужно проверить содержимое этого каталога.

1. Открываем консоль.
2. Вводим cd ~/.ssh, чтобы перейти в нужный каталог. Переходим в нужную директорию.
3. Используем ls, чтобы увидеть список всех файлов в каталоге. Открываем список файлов в директории. Ищем пару файлов с названиями вида имя и имя.pub. Обычно имя — id_rsa, id_dsa, id_ecdsa или id_ed25519. Файл с расширением .pub — ваш публичный ключ, а второй — ваш приватный, секретный ключ. Если таких файлов или даже каталога .ssh у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
4. Добавляем ключ в ssh-agent (сгенерированный или уже существующий). Проверяем доступность ключа командой eval "$(ssh-agent -s)" и добавляем с помощью ssh-add ~/.ssh/your_key_name, где указываем верный путь до файла с ключом и его имя. Добавляем ключ в shh-agent. Несколько важных примечаний:
   • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в ~/.ssh/config связь ключа с доменом.
   • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой eval "$(ssh-agent -s)". Может появиться такое сообщение об ошибке: «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

     В Сmder для запуска ssh-agent можно использовать команду start-ssh-agent.

     Если проблема осталась, рекомендуем работать в Git Bash.

   • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш ~/.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

     Host *
      AddKeysToAgent yes
      UseKeychain yes
      IdentityFile ~/.ssh/id_rsa

     Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K ~/.ssh/id_rsa. Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

   • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой chmod 700 ~/.ssh/
5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
   • Если вы на Windows clip .
   • Для пользователей macOS pbcopy .
   • На Linux используйте sudo apt-get install xclip, чтобы установить необходимый для копирования пакет xclip, а затем введите xclip -sel clip . Или введите команду cat ~/.ssh/id_rsa.pub, контент документа появится прямо в консоли и вы сможете скопировать ключ оттуда.

   Можно пойти другим путём, открыть файл id_rsa.pub прямо в папке и просто скопировать содержимое оттуда.

6. Переходим на страницу для работы с ключами в вашем профиле на GitHub. Страница с настройками ключей в вашем профиле.

   Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

   Добавляем в свой профиль SSH-ключ.

   Если всё сделано верно, в списке появится новый ключ.

   Успешно добавленный ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Работа с репозиториями

Для начала определим, что такое репозиторий. Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.

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

Как сделать форк мастер-репозитория?

Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.

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

Открываем консоль, переходим в директорию, где хотим сохранить папку с проектом, и вводим команду:

git clone [email protected]:your-nickname/your-project.git

Если вы правильно настроили SSH-ключи, Git начнёт процесс копирования репозитория на ваш компьютер. Если вы видите ошибку, в которой написано Error: Permission denied (publickey), скорее всего, вы ошиблись где-то при выполнении инструкции по настройке SSH-ключа. Вернитесь на несколько абзацев ранее и попробуйте повторить процесс настройки.

Если вы не хотите вручную вводить адрес репозитория, вы можете зайти на страницу проекта, нажать зелёную кнопку Clone or download (клонировать или скачать), выбрать Clone with SSH (клонировать по SSH) и скопировать адрес, который находится в текстовом поле. Этот адрес вы можете вставить в команду git clone.

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

git clone [email protected]:_your-nickname_/_your-project_.git folder_name

Теперь, на вашем компьютере, в папке your_project или в той, название которой вы указали самостоятельно, находится полная копия репозитория c GitHub.

Чтобы начать работу с проектом, надо оказаться в его директории. Для этого используем команду cd, после которой указываем название проекта на вашем компьютере: cd your-project

Работу над проектом принято вести в ветках. В каждом репозитории есть как минимум одна ветка. Это основная ветка, которую создаёт сам Git, она называется master . Обычно в ней находится стабильная версия программы без ошибок. Если вы хотите исправить баг, добавить новую функциональность в проект, попробовать какую-то технологию, но не хотите сломать код в основной ветке, вы ответвляетесь из master и трудитесь в своей новой ветке. Здесь вы можете реализовывать свои идеи, не переживая, что рабочий код сломается. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединяется с основной.

Создадим новую ветку. Открываем терминал, вводим команду git branch. Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master создаём новую ветку: git checkout -b имя-новой-ветки.

Если текущая ветка не master, сначала переключимся в основную ветку: git checkout master. Мы делаем это, чтобы новая ветка содержала свежую, на момент создания, рабочую версию проекта.

Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.

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

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

Если вы хотите сохранить изменения не во всех файлах, для начала можно ввести команду git status. Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

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

Если вы хотите сохранить все изменения разом, вводите git add -A.

Теперь мы можем сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды git commit -m "ваше сообщение". Текст сообщения должен быть лаконичным и в то же время сообщать о том, что делает коммит (внесённые изменения). Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте».

Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внесли и сохранили, пока локальны. Их нужно послать на GitHub.

Чтобы отправить свои изменения (коммиты) в репозиторий на GitHub, введите команду git push origin название-текущей-ветки, где origin означает репозиторий, который был склонирован на компьютер, то есть ваш форк.

Теперь заходим на страницу нашего форка и создаём пулреквест, чтобы слить свой код с данными в мастер-репозитории. Что такое пулреквест? Это предложение изменить код в репозитории.

Любое предложение можно принять или отвергнуть. Так же и с пулреквестом. После его создания, он должен получить ревью и одобрение так называемого коллаборатора — пользователя GitHub, который имеет права администратора в мастер-репозитории. Им может быть ваш коллега-разработчик, техлид, наставник. Если к вашему коду нет вопросов, пулреквест принимается и изменения из вашей ветки попадают в master главного репозитория. Если в код нужно внести изменения, пулреквест отклоняется, и вам нужно снова пройти по цепочке локальные изменения — сохранение — коммит — пуш, только пулреквест заново делать не нужно. Если вы продолжаете вести работу в той же ветке и пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки.

Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

1. В локальном репозитории вводим команду git checkout master, переходим в master.
2. Теперь забираем (подтягиваем) изменения из ветки master мастер-репозитория git pull academy master. Academy здесь — сокращённое название мастер-репозитория, такое имя используется в проектах студентов Академии, вы можете выбрать любое другое название. Забираем изменения из мастер-репозитория. Если консоль выдаёт ошибку и говорит, что не знает директории с таким именем, нужно добавить ссылку на этот репозиторий:

   git remote add academy [email protected]:your-repo.git

   Вместо academy указывайте своё название и оно закрепится за этим репозиторием.
3. Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master. Отправляем изменения в форк.

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

Git Workflow | Учебник Atlassian Git

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

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

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

Что такое успешный рабочий процесс Git?

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

• Соответствует ли этот рабочий процесс размеру команды?
• Легко ли исправить ошибки с помощью этого рабочего процесса?
• Возлагает ли этот рабочий процесс на команду какие-либо новые ненужные когнитивные издержки?

Централизованный рабочий процесс

Централизованный рабочий процесс — отличный рабочий процесс Git для команд, переходящих с SVN.Как и Subversion, централизованный рабочий процесс использует центральный репозиторий, который служит единой точкой входа для всех изменений в проекте. Вместо trunk ветвь разработки по умолчанию называется master , и все изменения фиксируются в этой ветви. Этот рабочий процесс не требует никаких других веток, кроме master .

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

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

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

Как это работает

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

Для публикации изменений в официальном проекте разработчики «помещают» свою локальную ветку master в центральный репозиторий. Это эквивалент svn commit , за исключением того, что он добавляет все локальные коммиты, которых еще нет в центральной ветке master .

Инициализировать центральный репозиторий

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

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

пользователь ssh @ хост git init --bare /path/to/repo.git

Обязательно используйте действительное имя пользователя SSH для пользователя , домен или IP-адрес вашего сервера для хоста и место, где вы хотите сохранить репо для / path / to / repo.мерзавец . Обратите внимание, что расширение .git обычно добавляется к имени репозитория, чтобы указать, что это чистый репозиторий.

Размещенные центральные репозитории

Центральные репозитории часто создаются через сторонние службы хостинга Git, такие как Bitbucket Cloud или Bitbucket Server. Процесс инициализации чистого репозитория, описанный выше, выполняется за вас службой хостинга. Затем служба хостинга предоставит адрес для доступа к центральному репозиторию из вашего локального репозитория.

Клонировать центральное хранилище

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

git clone ssh: //user@host/path/to/repo.git

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

Внести изменения и зафиксировать

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

  git status # Просмотр состояния репозитория git add # Создание файла git commit # Зафиксировать файл  

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

Отправка новых коммитов в центральный репозиторий

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

  git push origin master  

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

Управление конфликтами

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

Прежде чем разработчик сможет опубликовать свою функцию, он должен получить обновленные центральные коммиты и переназначить свои изменения поверх них. Это все равно, что сказать: «Я хочу добавить свои изменения к тому, что уже сделали все». В результате получается идеально линейная история, как в традиционных рабочих процессах SVN.

Если локальные изменения напрямую конфликтуют с вышестоящими коммитами, Git приостанавливает процесс перебазирования и дает вам возможность вручную разрешить конфликты. Самое приятное в Git заключается в том, что он использует те же команды git status и git add как для генерации коммитов, так и для разрешения конфликтов слияния.Это позволяет новым разработчикам легко управлять своими собственными слияниями. Кроме того, если у них возникнут проблемы, Git позволяет очень легко прервать всю перебазировку и повторить попытку (или обратиться за помощью).

Пример

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

Джон работает над своей функцией

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

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

Мэри работает над своей функцией

Тем временем Мэри работает над своей собственной функцией в собственном локальном репозитории, используя тот же процесс редактирования / этапа / фиксации. Как и Джона, ей все равно, что происходит в центральном репозитории, и ей на самом деле все равно, что Джон делает в своем локальном репозитории, поскольку все локальные репозитории частные .

Джон публикует свой очерк

Как только Джон завершит работу над своей функцией, он должен опубликовать свои локальные коммиты в центральном репозитории, чтобы другие члены команды могли получить к нему доступ. Он может сделать это с помощью команды git push , например:

  git push origin master  

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

Мэри пытается опубликовать свою характеристику

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

  git push origin master  

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

  ошибка: не удалось отправить некоторые ссылки в '/ path / to / repo.git 'hint: обновления были отклонены, потому что вершина вашей текущей ветки находится за подсказкой: ее удаленная копия. Объедините удаленные изменения (например, «git pull»). Подсказка: перед повторным нажатием. Подсказка: подробности см. в «Примечании о быстрой перемотке вперед» в «git push --help».  

Это не позволяет Мэри перезаписывать официальные коммиты. Ей нужно загрузить обновления Джона в свой репозиторий, интегрировать их с локальными изменениями, а затем повторить попытку.

Мэри перезагружается поверх коммитов Джона

Мэри может использовать git pull для включения изменений восходящего потока в свой репозиторий.Эта команда похожа на svn update — она ​​извлекает всю историю коммитов восходящего потока в локальный репозиторий Мэри и пытается интегрировать ее с ее локальными коммитами:

  git pull --rebase origin master  

Параметр --rebase указывает Git переместить все коммиты Мэри в верхнюю часть ветки master после синхронизации с изменениями из центрального репозитория, как показано ниже:

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

Мэри разрешает конфликт слияния

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

Если Мэри и Джон работают над несвязанными функциями, маловероятно, что процесс перебазирования вызовет конфликты. Но если это произойдет, Git приостановит перебазирование в текущем коммите и выведет следующее сообщение вместе с некоторыми соответствующими инструкциями:

  КОНФЛИКТ (содержание): конфликт слияния в  

Самое замечательное в Git то, что любой может разрешить свои собственные конфликты слияния. В нашем примере Мэри просто запустила бы git status , чтобы узнать, в чем проблема.Конфликтующие файлы появятся в разделе Unmerged paths:

  # Необъединенные пути: # (используйте "git reset HEAD ...", чтобы отключить сцену) # (используйте "git add / rm ...", чтобы отметить разрешение) # # оба изменены:  

Затем она отредактирует файлы по своему усмотрению. Как только она будет довольна результатом, она может обработать файл (ы) обычным способом и позволить git rebase сделать все остальное:

  git add git rebase - продолжить  

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

Если вы дойдете до этого момента и поймете, но понятия не имеете, что происходит, не паникуйте. Просто выполните следующую команду, и вы вернетесь туда, откуда начали:

  git rebase --abort  

Мэри успешно публикует свой очерк

После завершения синхронизации с центральным репозиторием Мэри сможет успешно опубликовать свои изменения:

  git push origin master  

Куда идти дальше

Как видите, можно воспроизвести традиционную среду разработки Subversion, используя лишь несколько команд Git.Это отлично подходит для перевода команд с SVN, но не использует распределенную природу Git.

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

Другие распространенные рабочие процессы

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

Разветвление функций

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

Рабочий процесс Gitflow

Рабочий процесс Gitflow был впервые опубликован в популярном сообщении в блоге Винсента Дриссена в 2010 году на сайте nvie.Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет никаких новых концепций или команд, помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли разным ветвям и определяет, как и когда они должны взаимодействовать.

Разветвление рабочего процесса

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

Рекомендации

Универсального рабочего процесса Git не существует. Как было сказано ранее, важно разработать рабочий процесс Git, который повысит продуктивность вашей команды. Помимо командной культуры, рабочий процесс также должен дополнять бизнес-культуру. Такие функции Git, как ветки и теги, должны дополнять график выпусков вашего бизнеса. Если ваша команда использует программное обеспечение для отслеживания задач, вы можете использовать ветки, которые соответствуют выполняемым задачам.Кроме того, при выборе рабочего процесса следует учитывать следующие рекомендации:

Короткоживущие ветви

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

Минимизировать и упростить реверты

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

Соответствует графику выпуска

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

Сводка

В этом документе мы обсудили рабочие процессы Git. Мы подробно рассмотрели централизованный рабочий процесс с практическими примерами. Расширяя централизованный рабочий процесс, мы обсудили дополнительные специализированные рабочие процессы. Некоторые ключевые выводы из этого документа:

• Не существует универсального рабочего процесса Git
• Рабочий процесс должен быть простым и повышать продуктивность вашей команды
• Требования вашего бизнеса должны способствовать формированию рабочего процесса Git

Чтобы прочитать о следующей проверке рабочего процесса Git из нашего исчерпывающего описания рабочего процесса Feature Branch.

Введение в Git и GitHub для начинающих (Учебное пособие)

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

Шаг 0: Установите git и создайте учетную запись GitHub

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

Следуйте инструкциям здесь, чтобы установить git (если он еще не установлен). Обратите внимание, что в этом руководстве мы будем использовать git только в командной строке. Хотя есть несколько отличных графических интерфейсов пользователя git (графические пользовательские интерфейсы), я думаю, что проще сначала изучить git, используя специфические для git команды, а затем опробовать графический интерфейс git, как только вы освоитесь с этой командой. Примечание: 95% других онлайн-ресурсов и обсуждений git также предназначены для интерфейса командной строки.

Как только вы это сделаете, создайте здесь учетную запись GitHub.

Git и GitHub

Небольшое отступление: git и GitHub — это , а не одно и то же. Git — это инструмент управления версиями с открытым исходным кодом, созданный в 2005 году разработчиками, работающими над операционной системой Linux; GitHub — компания, основанная в 2008 году, которая производит инструменты, которые интегрируются с git. Вам не нужен GitHub для использования git, но вы не можете использовать GitHub без использования git. Есть много других альтернатив GitHub, таких как GitLab, BitBucket, и решения для самостоятельного размещения, такие как gogs и gittea.Все они называются в git-speak «пультами дистанционного управления» и не являются обязательными. Вам не нужно использовать пульт для использования git, но это упростит обмен вашим кодом с другими.

Шаг 1. Создайте локальный репозиторий git

При создании нового проекта на локальном компьютере с помощью git вы сначала создаете новый репозиторий (или, часто, для краткости, «репо»).

Чтобы использовать git, мы будем использовать терминал. Если у вас нет большого опыта работы с терминалом и основными командами, ознакомьтесь с этим руководством (если вы не хотите / не нуждаетесь в коротком уроке истории, перейдите к шагу 3.)

Для начала откройте терминал и перейдите туда, где вы хотите разместить проект на локальном компьютере, используя команду cd (сменить каталог). Например, если у вас есть папка «проекты» на рабочем столе, введите что-то вроде:

Чтобы инициализировать репозиторий git в корне папки, выполните команду git init:

Шаг 2: Добавьте новый файл в репо

Добавьте новый файл в проект с помощью любого текстового редактора или с помощью сенсорной команды.`touch newfile.txt` просто создает и сохраняет пустой файл с именем newfile.txt.

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

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

По сути, здесь говорится: «Эй, мы заметили, что вы создали новый файл с именем mnelson.txt, но, если вы не используете команду ‘git add’, мы не собираемся ничего с ним делать».

Интерлюдия: промежуточная среда, фиксация и вы

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

Коммит — это запись того, какие изменения вы внесли с момента последнего коммита.По сути, вы вносите изменения в свое репо (например, добавляете файл или изменяете его), а затем говорите git, чтобы эти изменения были внесены в коммит.

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

Итак, как сказать git, какие файлы нужно поместить в коммит? Вот тут-то и пригодится промежуточная среда или индекс. Как видно на шаге 2, когда вы вносите изменения в свое репо, git замечает, что файл был изменен, но не будет с ним ничего делать (например, добавляя его в коммит).

Чтобы добавить файл в коммит, вам сначала нужно добавить его в промежуточную среду. Для этого вы можете использовать команду git add (см. Шаг 3 ниже).

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

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

Шаг 3. Добавьте файл в промежуточную среду

Добавьте файл в промежуточную среду с помощью команды git add.

Если вы повторно запустите команду git status, вы увидите, что git добавил файл в промежуточную среду (обратите внимание на строку «Изменения, которые необходимо зафиксировать»).

Повторим, что в файле , а не еще были добавлены в коммит, но вот-вот будут.

Шаг 4. Создайте фиксацию

Пора создать свой первый коммит!

Выполните команду git commit -m "Ваше сообщение о фиксации"

Сообщение в конце фиксации должно быть связано с тем, что содержится в фиксации — может быть, это новая функция, может быть, это исправление ошибки, может быть, просто исправление опечатки.Не помещайте сообщения типа «asdfadsf» или «foobar». Это огорчает других людей, которые видят ваш коммит. Очень очень печально. Коммиты живут вечно в репозитории (технически вы можете удалить их , если вам действительно, действительно нужно, но это беспорядочно), поэтому, если вы оставите четкое объяснение своих изменений, это может быть чрезвычайно полезно для будущих программистов (возможно, в будущем вы!) которые пытаются понять, почему через годы произошли некоторые изменения.

Шаг 5: Создайте новую ветку

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

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

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

Допустим, вы находитесь в основной ветке и хотите создать новую ветку для разработки своей веб-страницы. Вот что вы сделаете: Запустите git checkout -b <имя моей ветки>. Эта команда автоматически создаст новую ветку, а затем «проверит вас», что означает, что git переместит вас в эту ветку за пределы основной ветки.

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

Имя ветки со звездочкой рядом с ней указывает, в какой ветке вы находитесь в данный момент.

Примечание к названиям филиалов

По умолчанию первая ветвь каждого репозитория git называется `master` (и обычно используется в качестве основной ветки в проекте). В рамках общей работы технологической индустрии по борьбе с расизмом некоторые группы начали использовать альтернативные имена для ветки по умолчанию (например, в этом руководстве мы используем «первичный»).В другой документации и обсуждениях вы можете встретить «главный» или другие термины, используемые для обозначения основной ветви. Независимо от названия, просто имейте в виду, что почти у каждого репозитория есть основная ветвь, которую можно рассматривать как официальную версию репозитория. Если это веб-сайт, то основная ветвь — это версия, которую видят пользователи. Если это приложение, то основная ветвь — это версия, которую загружают пользователи. Это не технически, не требуется (git не обрабатывает какие-либо ветки иначе, чем другие ветки), но именно так git традиционно используется в проекте.

Если вам интересно решение использовать разные имена веток по умолчанию, на GitHub есть объяснение их изменения здесь: https://github.com/github/renaming

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

Шаг 6: Создайте новый репозиторий на GitHub

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

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

После нажатия кнопки GitHub попросит вас назвать свое репо и предоставить краткое описание:

Когда вы закончите заполнение информации, нажмите кнопку «Создать репозиторий», чтобы создать новое репо.

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

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

Шаг 7. Отправьте ветку на GitHub

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

Чтобы отправить изменения в новую ветку на GitHub, вам нужно запустить git push origin yourbranchname. GitHub автоматически создаст для вас ветку в удаленном репозитории:

Вам может быть интересно, что означает это слово «origin» в приведенной выше команде. Когда вы клонируете удаленный репозиторий на локальный компьютер, git создает для вас псевдоним.Почти во всех случаях этот псевдоним называется «происхождение». По сути, это сокращение для URL-адреса удаленного репозитория. Итак, чтобы отправить свои изменения в удаленный репозиторий, вы могли бы использовать любую команду: git push [email protected]: git / git.git yourbranchname или git push origin yourbranchname

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

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

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

Шаг 8: Создайте запрос на вытягивание (PR)

Запрос на перенос (или PR) — это способ предупредить владельцев репо о том, что вы хотите внести некоторые изменения в их код. Это позволяет им просмотреть код и убедиться, что он хорошо выглядит, прежде чем вносить изменения в основную ветку.

Вот как выглядит PR-страница до того, как вы ее отправили:

И вот как это выглядит после того, как вы отправили PR-запрос:

Внизу вы можете увидеть большую зеленую кнопку с надписью «Merge pull request».Нажав на эту кнопку, вы внесете изменения в основную ветку.

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

Шаг 9: Объедините PR

Идите дальше и нажмите зеленую кнопку «Merge pull request». Это объединит ваши изменения в основную ветку.

Когда вы закончите, я рекомендую удалить вашу ветку (слишком много веток могут стать беспорядочными), поэтому также нажмите эту серую кнопку «Удалить ветку».

Вы можете дважды проверить, что ваши коммиты были объединены, щелкнув ссылку «Коммиты» на первой странице вашего нового репо.

Это покажет вам список всех коммитов в этой ветке. Вы можете увидеть тот, который я только что слил, вверху (запрос на слияние №1).

Вы также можете увидеть хэш-код фиксации справа.Хэш-код — это уникальный идентификатор для этой конкретной фиксации. Это полезно для ссылки на определенные коммиты и при отмене изменений (используйте команду git revert для возврата).

Шаг 10. Получите изменения на GitHub обратно на свой компьютер

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

Чтобы получить самые последние изменения, которые вы или другие пользователи объединили на GitHub, используйте команду git pull origin master (при работе с основной веткой). В большинстве случаев это можно сократить до «git pull».

Здесь показаны все файлы, которые были изменены, и как они изменились.

Теперь мы можем снова использовать команду git log, чтобы увидеть все новые коммиты.

(Возможно, вам потребуется переключить ветки обратно на основную ветвь. Это можно сделать с помощью команды git checkout master.)

Шаг 11: Наслаждайтесь своей мерзкой славой

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

• https://training.github.com/
  Официальные шпаргалки Github по git! Удобно запоминать повседневные команды, которые вы будете использовать.
• https://learngitbranching.js.org/
  Смущены или заинтригованы системой веток git? Это просто означает, что ты человек! Это одна из самых глубоких частей git, но, возможно, и самая мощная.Понимание модели ветвей дает вам суперсилы git, и это руководство дает вам способ изучить ветки git визуальным и интуитивно понятным способом.
• https://git-school.github.io/visualizing-git
  Еще один инструмент для визуального изучения git. Это больше похоже на открытую песочницу, чем на Learngitbranching.js.org
.
• https://github.com/jlord/git-it-electron
  Настольное приложение, которое поможет вам изучить git через проблемы, которые вам нужно решить. Он состоит из нескольких уровней, каждый из которых требует от вас использования команд git для получения правильного ответа.
• https://github.com/Gazler/githug
  Если вам понравился git-it, Githug — это еще один учебник на основе головоломок, разработанный, чтобы дать вам практический способ изучения git.

Я также рекомендую найти время, чтобы поработать с вашей командой над моделированием небольшого группового проекта, как мы это сделали здесь. Попросите вашу команду создать новую папку с названием вашей команды и добавить в нее несколько файлов с текстом. Затем попробуйте отправить эти изменения в это удаленное репо. Таким образом, ваша команда сможет начать вносить изменения в файлы, которые они изначально не создавали, и практиковаться в использовании функции PR.И используйте инструменты git blame и git history на GitHub, чтобы ознакомиться с отслеживанием того, какие изменения были внесены в файл и кто эти изменения внес.

Чем больше вы используете git, тем удобнее вам … работать с ним. (Я не мог устоять.)

* Этот пост был первоначально опубликован в октябре 2015 года Меган Нельсон, в то время старшим инженером-программистом в HubSpot. С тех пор он был обновлен командой продукта HubSpot.

Заинтересованы в работе в производственной группе, которая ценит автономность и прозрачность? Ознакомьтесь с нашими открытыми вакансиями и подайте заявку.

Git Tutorial for Beginners — Crash Course

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

Просто ищете самые важные команды Git? Щелкните здесь, чтобы перейти в конец статьи!

# Git vs Github

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

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

# Репозитории, ветви и коммиты

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

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

Внутри наших филиалов! Ветвь содержит разные версии нашего кода, наш Commits . Каждая фиксация — это снимок определенной версии кода.

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

# Как установить и использовать Git

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

Git работает только в терминале (MacOS) или командной строке (Windows), поэтому он не имеет графического интерфейса пользователя (GUI). Обязательно изучите специальные ресурсы, если эти условия для вас совершенно новы.

Если вы работаете с IDE, вы также можете использовать встроенный терминал. В этом видео / статье я буду использовать код Visual Studio.

Вы предпочитаете видео? Не пропустите видео Full Git Crash Course в верхней части этой страницы!

# Основные команды

Давайте создадим новый проект, папку, которая содержит «index.html »и добавьте в него базовый код:

  
 Здравствуйте 
 Немного текста 
  

Вы новичок в веб-разработке? Обязательно посмотрите наше видео «Как работает Интернет», чтобы легко начать работу!

git init

Давайте напишем нашу первую команду Git. git init превратит наш проект в проект, управляемый Git. Вы должны увидеть в своем терминале информацию о Initialized empty Git Repository , подтверждающую, что Git теперь отслеживает проект.Но почему наш проект пуст?

git status

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

git add

Файлы отслеживания работают либо с git add filename («filename» должно быть именем файла, который вы хотите отслеживать), либо с git add., который будет отслеживать изменения во всех файлах в репозитории. С git status мы видим, что мы добавили новый файл («index.html» в нашем случае) в репозиторий, однако мы не сохранили никаких изменений в коде до этого момента.

git commit

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

# Погружение глубже в ветви и коммиты

Время для краткого обзора, прежде чем мы углубимся:

1) Мы превратили нашу папку проекта в репозиторий Git с помощью git init 2) Мы сказали Git отслеживать любые изменения в файле ìndex.html с помощью git add. 3) Мы сохранили текущую версию нашего кода в коммите с git commit -m "добавлен стартовый код"

Это было просто, не так ли? Но как насчет филиалов? Я уже говорил вам, что мы автоматически создали нашу главную ветвь с нашим первым коммитом, но где мы можем увидеть эту ветвь?

git branch

git branch перечисляет все ветки в нашем репозитории.Хотя мы не добавляли никакого имени, главная ветвь была автоматически создана с нашим первым коммитом:

У нас есть только одна ветка на данный момент, звездочка указывает, что мы также в настоящее время работаем в этой ветке.

Давайте добавим дополнительный код в наш файл index.html:

  
 Здравствуйте 
 Немного текста 
 Другой текст 
  

С git add. и git commit -m "div added" , мы можем добавить этот новый код в качестве второго коммита в нашу ветку.

## git log

При вводе git log в нашем терминале будут отображаться все коммиты внутри нашей ветки:

Каждый коммит содержит уникальный идентификатор, автора, дату и сообщение о фиксации (это -m " Ваше сообщение « часть). «HEAD» просто указывает на последний коммит нашей текущей ветки, подробнее об этом в следующей главе.

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

Но как Git создает эти коммиты? Каждая фиксация не является обновленной копией предыдущей фиксации.После первого коммита Git просто отслеживает изменения для каждого следующего коммита. Итак, с git add. , Git проверяет наши файлы на наличие изменений, затем git commit сохраняет эти изменения в новом коммите.

Отслеживание подобных изменений делает Git быстрым и эффективным, поскольку создание копий снова и снова просто приведет к раздуванию нашей папки Git, чего мы определенно хотим избежать в любом проекте!

# ГОЛОВА

Пора присмотреться к ГОЛОВЕ.

  
 Здравствуйте 
 Немного текста 
 Другой текст 

 Тестирование головы 
  

Я добавил еще один «div» и создал новый коммит ( git add. и git Commit -m "head testing" ), как объяснялось ранее, этот коммит стал HEAD, поскольку это последний коммит в нашей ветке:

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

## git checkout

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

Здесь мы можем использовать идентификатор, который мы ранее рассматривали, с git log :

Давайте проверим вторую фиксацию с именем «добавлен div» с помощью git checkout yourcommitsID (просто скопируйте и вставьте идентификатор фиксации в Часть yourcommitsID).

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

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

Сначала нам нужно вернуться в нашу главную ветку с git checkout master (или просто git master ), теперь мы вернулись к последней фиксации ветки (наш HEAD).

Теперь легко удалить нашу последнюю фиксацию. Скопируйте идентификатор фиксации, к которой вы хотите вернуться (НЕ идентификатор фиксации, которую вы хотите удалить), и используйте git reset --hard ID (идентификатор должен быть идентификатором фиксации).Вот и все, мы сбросили HEAD и удалили все последующие коммиты.

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

# Отмена неустановленных изменений

Давайте еще раз добавим код:

  
 Здравствуйте 
 Немного текста 
 Другой текст 

 Что-то мне не нужно 
  

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

Замечательно, это были основы коммитов, пора переходить к ветвям.

# Работа с ветвями

До этого момента мы работали только в главной ветке. В реальном проекте у вас обычно есть несколько ветвей, например:

• Основная ветка, которая содержит вашу текущую стабильную и работающую версию вашего веб-сайта
• Ветка функции, в которой вы в настоящее время работаете над новой функцией

Конечная цель — объединить обе ветви, как только новая функция будет завершена и готова к запуску.

git checkout -b

git checkout -b создает новую ветку на основе последней фиксации ветки, в которой вы сейчас работаете. Поскольку мы находимся в последней фиксации в основной ветке, которая содержит «index. html », новая созданная ветвь, следовательно, также будет включать этот код и все коммиты внутри этой ветки, поэтому мы в основном копируем всю ветку.

git checkout -b new-feature создаст эту новую ветку с именем «new-feature»:

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

git add. и git commit -m «css added» создаст новый коммит с этими изменениями в нашей ветке «new-feature».

Это также дает две разные ГОЛОВКИ. В ветке «new-feature» коммит, который мы только что создали, называется HEAD, в основной ветке у нас другой HEAD, наш «добавленный div» коммит — второй на скриншоте:

Merging Branch

Back в нашей основной ветке с git master теперь мы можем объединить или объединить две наши ветки с новой функцией git merge .

Это добавит изменения, внесенные в ветку «new-feature», в нашу главную ветвь, и, следовательно, наша последняя фиксация «css added» теперь является HEAD обеих ветвей.

Удаление ветвей Git

Поскольку наша новая функция реализована в главной ветке, мы можем избавиться от ветки «new-feature» с помощью git branch -D new-feature .

# Разрешение конфликтов слияния

Слияние ветвей — отличная функция, но иногда она также может вызывать конфликты.

В настоящее время у нас есть этот код в последней фиксации в нашей основной ветке:

  
 Здравствуйте 
 Немного текста 
 Другой текст 
  

Давайте создадим новую ветку с git checkout -b new-feature и изменим код следующим образом:

  
 До свидания 
 Немного текста 
 Другой текст 
  

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

  
 BYE 
 Немного текста 
 Другой текст 
  

Если мы добавим и зафиксируем это изменение, мы будем работать с одним и тем же кодом в двух разных Ветвях (первый

), так что же произойдет, если мы попытаемся объединить Филиалы сейчас?

git merge, новая функция выдаст нам ошибку: «Автоматическое слияние не удалось; устранять конфликты и фиксировать результат ».

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

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

# Полезные команды Git

Срочно нужно найти команду Git? Вот ваш маленький помощник:

• git init : инициализировать репозиторий Git в текущей папке
• git status : показать текущий статус вашего репозитория Git (статус «рабочего дерева»)
• git add .: отслеживать изменения всех файлов в вашем репозитории
• git commit -m "ваше сообщение" : сохранить обновленный код в новом коммите с именем «ваше сообщение»
• git log : перечислить все коммиты внутри вашей ветки
• git checkout имя-ветки : перейти к последней фиксации ветки
• git checkout commitid Перейти к определенной фиксации ветки (commitid должен быть идентификатором фиксации, которую вы хотите проверить)
• git checkout -.: вернуться к последней фиксации и удалить все неотслеживаемые изменения
• get reset --hard : превратить выбранную фиксацию в новую HEAD
• git branch : перечислить все ветки внутри вашего репозитория
• git checkout - b имя-ветки : создать новую ветку с именем имя-ветки
• git merge имя-ветки : объединить две ветки, имя-ветки — это ветка, которую вы объединяете с веткой, в которой вы сейчас работаете
• ветка git -D имя-ветки : удалить ветку с именем имя-ветки

Основы Git — единственное введение, которое вам когда-либо понадобится!

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

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

Итак, описанные изменения с течением времени, к которым вы позже можете вернуться — просто. Но, допустим, вы хотите работать над своим проектом вместе со своим другом. Поскольку у вас есть только один файл для работы и вы делаете это в разное время, управление такой разработкой может быть немного проблематичным.Не волнуйтесь — и здесь VCS может помочь! Это помогает отслеживать изменения, внесенные в конкретный файл с течением времени конкретными пользователями , чтобы позже вы могли решить, как объединить их в один в процессе, называемом слиянием. Таким образом, VCS теперь хранит данные о конкретном изменении, времени, когда оно было зафиксировано, и о том, какой пользователь это сделал.

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

А теперь вернемся к самому Git. Как я уже упоминал, это одна из самых популярных и широко используемых систем контроля версий. Его популярность, безусловно, является результатом некоторых из его самых важных преимуществ. Во-первых, это распределено , что означает, что у вас фактически нет активного подключения к Интернету, и вы просто запускаете Git на своем локальном компьютере. И это только благодаря архитектуре и производительности . Что, если продолжить наш мыслительный процесс, позволит сделать использование Git относительно простым по сравнению с другими реализациями VCS.

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

  git init имя проекта
cd projectName
  

Приведенная выше команда инициализирует проект Git в каталоге, указанном в projectName (будет создан, если еще не существует).Если вы не укажете никакого имени, репозиторий Git будет создан в текущем каталоге. После всего этого мы идем внутрь!

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

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

  git config --global user.name «Пользователь»
git config --global user.электронная почта "[электронная почта защищена]"
  

С помощью приведенных выше команд мы можем установить наше имя и адрес электронной почты глобально, что означает, что они будут использоваться для любого коммита, который мы сделали с нашей машины. user.name задает имя пользователя (одно для использования в сети), а user.email — его общедоступный адрес электронной почты. С учетом сказанного, команда git config часто используется для установки различных переменных, используемых Git внутри, но здесь (и в большинстве случаев) имя и адрес электронной почты — это все, что нам нужно, чтобы двигаться дальше.

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

  git add.
  

С помощью приведенной выше команды мы добавляем все наши файлы (вы можете указать их целыми каталогами или файл за файлом) в какой-то контейнер, то есть мы обрабатываем наши изменения , чтобы Git заметил, что они были изменены — созданы, обновлены или удалены . Этот шаг часто выполняется автоматически современными редакторами кода, такими как VS Code со встроенной поддержкой Git. Вы должны знать, что наши изменения еще не зафиксированы. На данный момент Git знает только то, что они были созданы.Чтобы на самом деле зафиксировать их, то есть сохранить в нашей истории репозитория Git, нам нужно будет использовать еще одну команду:

  git commit -m "Commit message"
  

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

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

Филиалы

Проблема с несколькими людьми, работающими над одним и тем же проектом, возникает в форме управления изменениями, которые накладываются друг на друга, не нарушая при этом друг друга. У Git есть решение и для этого — оно называется веток !

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

  git branch -c моя-ветка
  

Вы можете управлять своими ветвями с помощью команды git branch с некоторыми дополнительными параметрами. Примеры включают -c , -m , -d , соответственно, обозначающие копирование, перемещение и удаление. Первые две опции, которые заставляют команду принимать два аргумента, по умолчанию используют текущую ветвь. Если по какой-то причине вам нужна совершенно новая ветка, вам не нужно использовать какие-либо дополнительные параметры.

Checkouts

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

  git checkout моя ветка
  

Слияние

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

  git слияние моя ветка
  

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

Клонирование

Наиболее распространенный способ доступа к удаленному репо — его клонирование.Для этого вы можете использовать известную команду git-clone .

  git clone https://github.com/vuejs/vue.git
  

Такая команда автоматически создает все удаленных веток и проверяет основную ветку (чаще всего «master» ).

Remote

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

  git удаленный
  

Без дополнительных подкоманд или опций удаленная команда выведет список всех имен ваших удаленных источников , e.грамм. после клонирования имя единственного доступного пульта дистанционного управления — «origin» .

Если вы хотите добавить данный пульт в какой-либо существующий репозиторий, вместо того, чтобы просто клонировать его, вы можете использовать команду git remote add . Просто передайте короткое имя для вашего нового пульта ДУ, его исходный URL, и все готово!

  git удаленное добавление vue https://github.com/vuejs/vue.git
  

Push & pull

Чтобы получить доступ к данным из удаленных источников, вам нужно сначала получить .Простая команда для этого называется git fetch .

  git fetch
  

В качестве аргумента вы можете передать имя удаленного источника, который вы хотите получить. По умолчанию «origin» .

Используя git fetch , вы получаете изменения и ветки, сделанные другими соавторами. Затем вам придется (скорее всего) объединить его с вашими собственными локальными изменениями, используя git merge . Оказывается, это настолько обычное дело, что Git предоставляет для этого ярлык в виде команды git pull , которая автоматически выбирает удаленную ветку и объединяет ее с вашей текущей локальной веткой.

  git pull
  

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

  мастер git push origin
  

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

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

Rebase

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

  git rebase
  

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

  git статус
  

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

  git журнал
  

При наличии доступа к ранее упомянутому идентификатору фиксации или имени ветки и т. Д.вы можете использовать его с командой git diff для отображения фактической разницы между текущим рабочим деревом и данной сущностью. Это чрезвычайно полезно и используется всеми инструментами Git GUI.

  git diff моя ветка
  

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

  git tag custom-tag
  

Тайники

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

  git stash
  

Самая простая команда выше создает новый тайник, который позже можно увидеть с помощью:

  git stash list
  

Чтобы восстановить заданный тайник (даже поверх различных коммитов), вам нужно использовать команду git stash apply и указать тайник с помощью идентификатора ссылки, всего синтаксиса reflog или каким-либо другим способом (см. Документацию).Для получения информации о ссылке на тайник и его идентификаторе вам потребуется просмотреть вывод команды git stash list .

  git stash применить [электронная почта] {0}
# такой же как
git stash применить 0  

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

Сброс и возврат

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

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

  git сбросить
  

Еще один раз, когда Git окажется действительно полезным, — это когда вам нужно вернуться в прошлое и отменить некоторые коммиты , которые вы сделали ранее. Очевидно, что команда git revert позволяет сделать именно это, просто указав идентификатор фиксации. Затем, при желании, он проведет вас через процесс восстановления конфликтующего содержимого.

  git revert fc95eb54362878829042ac2c6b3a34bd208b2c04
# пример идентификатора фиксации
  

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

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

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

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

Git — невероятно хорошо продуманная и интересная реализация VCS. Это довольно легко понять для новичков , но при этом предоставляет множество функций для продвинутых пользователей pro . С учетом сказанного, даже после довольно полного введения, сделанного в этой статье, в Git по-прежнему доступно бесчисленное множество опций, команд и множество различных товаров. В мире, где проекты становятся все больше и больше, VCS является обязательным требованием. К счастью, Git делает эту необходимость только лучше, приятнее, быстрее, удобнее и общепризнаннее.

Итак, вам понравилась эта статья ? Дайте мне знать, если вы хотите узнать больше о Git в этом блоге в аналогичном форм-факторе или что-то в этом роде, с и реакцией ниже. Также оставьте свои мысли в разделе комментариев ниже. Как всегда, пожалуйста, поделитесь статьей , если вы сочтете ее полезной, и подумайте, что подписался на меня в Twitter , на моей странице в Facebook и подписался на в еженедельном информационном бюллетене ниже. Спасибо за чтение и хорошего дня, !

Основы Git — Руководство для идиота.. Мы постоянно вносим изменения в… | by Rukee Ojigbo

Мы постоянно вносим изменения в файлы как программисты. Вы добавляете новые строки кода, вытаскиваете старые или реорганизуете их. Это сопряжено с риском: в конечном итоге вы можете все испортить и захотите вернуться во времени к точке, где все работало идеально. Что ж, вы, вероятно, могли бы выбрать “ctrl + z” до тех пор, пока это не произойдет. Но зачем тебе убивать себя?

Вот, Гит. Смотри на свет.

Так что же такое Git?

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

Git был изобретен в 2005 году Линусом Торвальдсом. Скорее всего, вы пришли сюда не на уроки истории. Итак, давайте продолжим.

Давайте начнем

Чтобы начать использовать git для контроля версий, на вашем компьютере должен быть установлен git.Чтобы установить git, перейдите по ссылке : https://git-scm.com/downloads

Теперь, когда git установлен. В своем терминале перейдите в папку своего проекта и запустите следующий код.

  git init  

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

Чтобы добавить новый файл … вы можете просто создать его в обычном режиме … или запустить следующий код в своем терминале (для пользователей Mac):

  touch   

Я создал образец индекса .html и файл index.js в качестве образца. Моя папка выглядит так:

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

  git status  

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

Теперь мы должны зафиксировать эти файлы в git … чтобы git мог их отслеживать.

Прежде чем мы продолжим, позвольте мне прояснить некоторые вещи.

В git есть три уровня:

1. Репозиторий Git
2. Промежуточная область (или промежуточный индекс)
3. Рабочий каталог

Репозиторий Git:

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

Промежуточная область:

Промежуточная область подобна посреднику между репозиторием git и вашим рабочим каталогом.

Рабочий каталог:

Ваш рабочий каталог — это обычная папка, над которой вы в настоящее время работаете.

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

Хорошо, давай вернемся. Git говорил нам, что у нас есть неотслеживаемые файлы.

Добавление файлов в репозиторий Git

Чтобы git отслеживал эти файлы, выполните следующие команды на вашем терминале

  git add   

Добавляет соответствующий файл в промежуточную область … вы можете использовать (git add. ), чтобы добавить все файлы.

  git commit -m <добавьте сюда сообщение, относящееся к внесенным вами изменениям>  

Это переносит файл из промежуточной области в репозиторий git…

Теперь, если мы запустим « git status» команда….Мы видим, что отслеживать нечего.

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

  git log  

Мы сделали только одну фиксацию. Вот так выглядит наша история.

Создание веток с помощью Git

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

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

  git checkout -b   

Для просмотра имеющихся у вас веток и определения текущей ветки, в которой вы находитесь. Запустите следующий код:

  git branch  

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

Переключение между ветвями

  git checkout     

Объединение ветвей

Переключитесь на ветку, с которой вы хотите объединиться. Затем:

  git merge     

Чтобы удалить ветку

Скажите, что вам больше не нужна ветка, и вы хочу его удалить.

  git branch --d   

Возвращаясь в прошлое.

Допустим, вы допустили ошибку и хотите вернуться к моменту времени, когда все работало хорошо, выполните «git log» , скопируйте часть «ключ SHA» из конкретной истории, которую вы хотите вернуться к.

Затем выполните следующую команду:

  git checkout     

Сохранение в онлайн-репозиторий

Git также дает вам возможность загружать файлы в удаленный репозиторий (онлайн-хранилище).Таким образом, другие разработчики могут получить к нему доступ, если хотите… или просто сохранить его.

Хотя существует несколько онлайн-платформ для хранения проектов git, github, по-видимому, является наиболее популярным. И что я собираюсь использовать для этой иллюстрации. Сначала вам необходимо иметь учетную запись, если у вас ее нет, вы можете посетить их сайт

Шаг 1:

Создайте новое репо. В правом верхнем углу щелкните значок плюс (+)…. Затем щелкните новый репозиторий

Шаг 2:

Введите имя для вашего репозитория и описание.Затем нажмите создать новый репозиторий (зеленый в нижнем левом углу)

Шаг 3:

Скопируйте следующую строку и вставьте ее в терминал.

В основном это команда:

  git remote add origin   

Чтобы убедиться, что указанная выше команда работает, вы можете просто ввести «git remote» в свой терминал. и вы должны увидеть «происхождение».

Шаг 4:

Поздравляю. Вы только что успешно добавили в свой проект удаленное репо.Теперь давайте разместим наш проект в Интернете.

  git push -u origin master  

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

  git push  

О git нужно знать больше, но я надеюсь, что это даст вам общее представление. Спасибо за прочтение.

Основы Git | Проект Odin

Введение

В этом уроке мы рассмотрим общие команды Git, используемые для управления вашими проектами и для загрузки вашей работы на GitHub.Мы называем эти команды базовым рабочим процессом Git . Когда вы используете Git, это команды, которые вы будете использовать в 70-80% случаев, поэтому, если вы сможете их выполнить, вы будете более чем на полпути к освоению Git!

Результаты обучения

К концу этого урока вы должны уметь делать следующее:

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

Назначение

Примечание. С 1 октября 2020 года во всех новых репозиториях Git будет создана ветка по умолчанию с именем «main» вместо «master».

1. Посмотрите это видео Кори Шафера, чтобы получить отличный обзор некоторых основных команд Git.

Шпаргалка

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

• Команды, относящиеся к удаленному репозиторию:
  • git clone [email protected]: ИМЯ-ПОЛЬЗОВАТЕЛЯ / ИМЯ-РЕПОЗИТОРИЯ.git или же git clone https://github.com/user-name/repository-name.git
  • git push origin main
• Команды, относящиеся к рабочему процессу:
  • git add.
  • git commit -m «Сообщение, описывающее, что вы сделали, чтобы сделать этот снимок другим»
• Команды, относящиеся к проверке статуса или истории журнала

Базовый синтаксис Git — программа | действие | пункт назначения .

Например,

• git add. читается как git | добавить | . , где точка представляет все в текущем каталоге;
• git commit -m "сообщение" читается как git | commit -m | «сообщение» ; и
• git status читается как git | статус | (нет пункта назначения) .

Заключение

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

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

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

Дополнительные ресурсы

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

Проверка знаний

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

  git clone git: //git.code.sf.net/p/gretl/git gretl-git
 

  git clone ssh: // ИМЯ ПОЛЬЗОВАТЕЛЯ @ git.code.sf.net/p/gretl/git gretl-git
 

  git config --global user.name "Ваше имя"
  git config --global user.email "ваше имя @ вашсервер.ext "
 

  мерзавец тянуть
 

  git commit <имена файлов>
 

  git commit -a
 

  git push
 

  git checkout.
 

git reset - мягкая ГОЛОВКА ~
git reset --hard HEAD ~
 

git diff
 

git fetch origin
git diff HEAD origin / master
 

git diff origin / master
 

git ветка newbranch
git checkout newbranch
 

git push -u origin newbranch
 

мастер проверки git
 

мастер проверки git
git merge newbranch
 

git branch -d somebranch
 

git push origin - удалить ветвь