Как сделать коммит с сообщением

Добавил пользователь Дмитрий К.
Обновлено: 05.10.2024

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

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

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

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

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

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

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

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

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

3. Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

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

3. Исправление коммита

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

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

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

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Будучи новичком, я, как и все, искал на StackOverflow полезные Git-команды. Я просто копировал и вставлял их, не задаваясь вопросом, что и как они делают.

Спустя несколько лет эта роль досталась мне. Поэтому в этой статье я все-таки расскажу о ряде git-команд, которые могут пригодиться даже мидлам.

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

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

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

Часто используемые команды

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

Если вы используете GitHub и отправляете код в репозиторий GitHub, который хранится в Сети, вы используете удаленный репозиторий. Имя, установленное по умолчанию для этого удаленного репозитория, называется origin (источник), он же alias (псевдоним). Если вы скопировали проект из GitHub, у него уже есть источник. Вы можете просмотреть этот источник с помощью команды git remote -v. Она выдаст вам URL-адрес удаленного репозитория.

Если вы инициализировали свой репозиторий Git и хотите связать его с репозиторием на GitHub, вам придется создать его на GitHub, скопировать предоставленный URL-адрес и использовать команду git remote add origin , где — ссылка на репозиторий GitHub. Оттуда вы можете добавлять, коммитить и пушить в удаленный репозиторий.

Допустим, вы скопировали чей-то удаленный репозиторий и хотите изменить его владельца на свою учетку GitHub. Схема такая же, как с git remote add origin, с одним дополнением: используйте set-url, чтобы изменить удаленный репозиторий.

Самый распространенный способ скопировать репозиторий — через git clone с указанием URL.

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

Команда git branch перечислит все ветки на вашем компьютере. Если вы хотите создать новую ветку, можете использовать команду git branch , где — имя ветки (например, master).

Команда git checkout переключит на существующую ветку. Поэтому чтобы создать новую ветку и сразу же переключиться на нее, можете использовать команду git checkout -b . Обычно эту команду используют, чтобы не писать отдельно git branch, а отдельно git checkout.

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

Если вы работаете еще с кем-то, может случиться так, что репозиторий обновили на GitHub, но у вас изменения не появились. В этом случае используйте git pull origin
, чтобы получить последние изменения указанной удаленной ветки.

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

Команды для продвинутых

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

Команда git logo позволяет увидеть историю коммитов. Она-то и поможет, если вам нужно просмотреть историю и изменить старые коммиты.

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

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

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

Допустим, у вас есть 4 коммита в вашей локальной истории (не запушенные на GitHub), и выглядят они неряшливо. Вы можете использовать rebase, чтобы объединить все эти коммиты в один.

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

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

- добавить кнопку;
- написать тесты для оформления заказа.

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

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

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

Subscribe to Блог ASKMENTOR

Get the latest posts delivered right to your inbox

7 мест, где можно найти ментора

Вам когда-нибудь приходило в голову искать наставника в фитнес-клубе? Вы удивитесь, где может тусоваться нужный человек

С чего начать обучение в программировании?

Если вы хотите научиться программированию, но не знаете, с чего начать — вы попали по адресу

Git — распределённая система контроля версий. Git — позволяет сохранять все изменения, внесённые в файлы, хранящиеся в репозитории.

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

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Ключ к пониманию

Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

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

Простейший цикл работ

Редактирование, добавление, удаление файлов (собственно, работа).
Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
Коммит (фиксация изменений).
Возврат к шагу 1 или отход ко сну.

Указатели

HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
Теги — простые указатели на коммиты. Не перемещаются.

Настройки

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

Если вы в Windows:

Указание не отслеживаемых файлов

Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.

Длинный вывод в консоли: Vim

Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .

Vim (некоторые команды)

Нажатия кнопок

ESC — переход в командный режим i — переход в режим редактирования текста ZQ (зажат Shift, поочередное нажатие) — выход без сохранения ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

Нажатия кнопок

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

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

Зачем вообще нужны системы контроля версий?

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

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

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

Начинаем использовать Git

Установка

Здесь вы найдете детальную инструкцию по установке Git на любую операционную систему.

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

Создание локального репозитория

Создайте отдельную папку для вашего проекта. Давайте для примера назовем ее simple-git-demo .

Зайдите в нее и добавьте локальный git-репозиторий с помощью следующих команд:

Немного кода

Создайте новый файл demo.txt в папке проекта и запишите в него что-нибудь:

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

Работа с кодом и сохранение изменений

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

Добавление в рабочую область (staging)

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

Можно добавить сразу несколько:

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

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

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

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

Git status и git log

Теперь изменим demo.txt :

Статус

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

Мы увидим, что demo.txt изменен, но еще не находится в рабочей области. Давайте добавим его:

и зафиксируем изменения:

Ветки

До сих пор мы не создали ни одной ветки в Git. По умолчанию все коммиты попадают в ветку master.

Что такое ветка?

Зачем нужно создавать несколько веток?

Разные ветки позволяют параллельно разрабатывать разную функциональность.

Изначально commit 1 и commit 2 выполнялись в ветке master. После второй фиксации создается новая ветка под названием test, и commit 3 и commit 4 добавляются в нее.

В то же время в ветку master тоже добавляются commit 3 и commit 4. То есть в разных ветках параллельно создаются коммиты. Сейчас тестовая ветка не связана с главной, но их можно объединить с помощью git merge . Этот вопрос будет рассмотрен позднее, а пока повторим схему с картинки.

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

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

Вот теперь мы находимся на ветке test .

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

Сделайте коммиты в новой ветке

Добавьте изменения в рабочую область и зафиксируйте их:

После этого коммита тестовая ветка опережает главную: она включает две ранее сделанные фиксации и одну новую.

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

Слияние

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

Сначала вернитесь в ветку master:

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

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

Запустите git log и вы увидите, что в мастер-ветке теперь также 3 коммита.

Удаленный Репозиторий

GitHub

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

После регистрации нажмите на кнопку Начать проект, чтобы создать новый репозиторий. Дайте ему имя git-blog-demo и нажмите кнопку Создать репозиторий.

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

Чтобы указать вашему локальному репозиторию на удаленный, используйте следующую команду (вместе [repository url] введите адрес своего репозитория без квадратных скобок):

Git push

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

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

Дополнительные команды

Git pull

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

Git clone

Используется для клонирования существующего удаленного репозитория на ваш компьютер.

Поздравления

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

Читайте также: