Как запушить коммит на гитхаб
Перейти к содержимому

Как запушить коммит на гитхаб

  • автор:

Как добавить коммит в Git

Добавить коммит в Git можно следующим образом. Для этого необходимо выполнить 2 команды. Первая команда git add -A добавляет все измененные файлы в индекс. А вторая команда создает коммит.

git add -A git commit -m "Commit message."

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

git add goodfile.cpp goodfile.h git commit -m "Commit message."

Создание коммита одной командой

Можно создать коммит одно командой, но только для отслеживаемых файлов. В данном случае в индекс добавляются все изменения файлов, но только тех файлов, которые уже когда-либо были добавлены в Git репозиторий — отслеживаемые файлы (Tracked files). То есть новые неотслеживаемые файлы (Untracked files) данной командой игнорируются.

git commit -a -m "Commit message."

Отправка изменений на удаленный репозиторий

Когда вы создали один или несколько коммитов в своем локальном репозитории, вам, скорее всего, нужно будет отправить все свои изменения на удаленный репозиторий. Для этого используется команда git push . Например, отправим на удаленный репозиторий origin все наши изменения в ветке master:

git push origin master

Смотрите также:

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

Первый коммит в Github

Руководство по созданию первого коммита в свой репозиторий на Github

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

  • Github нужен для взаимодействия между разработчиками при совместной работе над проектами (может использоваться в течении всего жизненного цикла ПО).
  • Работа в Github организуется посредством предоставления определенного доступа через интернет каждому из членов команды к рабочим директориям проекта, истории изменений, а также к задачам и документации проекта, с возможностью изменять файлы и отслеживать историю их редактирования.

Основы

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

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

GitHub — это сервис для проектов, использующих Git.

Создать коммит (commit) значит зафиксировать изменения любых файлов, входящих в репозиторий.

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

Репозиторий бывает:

  • локальный (расположен непосредственно в памяти компьютера разработчика, в нем происходит разработка и фиксация изменений, после чего можно отправить на удалённый репозиторий)
  • удалённый (находится на сервере, может быть приватным – доступным ограниченному числу лиц, и публичным – open source)
  • система контроля доступа
  • багтрекинг (отслеживание истории действий над файлами и, при необходимости, переход на более ранние версии)
  • возможность управлять задачами и справками для проектов

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

Установка Git

Для Linux:

1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git

Для macOS:

1. Воспользуемся homebrew
2. Вводим в терминале: brew install git

Для Windows, (для macOS и Linux — альтернатива):

1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.

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

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

1. Открываем Bash

Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.

2. Настроим имя пользователя и адрес электронной почты:

git config --global user.name "Name" git config --global user.email email@mail.ru

(где Name – логин пользователя, email@mail.ru — почта)

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

tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.

find – удаление файлов со специфичным суффиксом.

3. Переходим в папку с проектом Users/Public/Project:

cd Users/Public/Project/

4. Создадим локальный репозиторий в папке с проектом:

git init

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

Initialized empty Git repository in Users/Public/Project/

Добавление файлов в локальный репозиторий

1. Теперь создадим любой файл в нашей директории, например, first.txt

2. Добавим его в систему управления версиями:

git add first.txt

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

git add –A
git add --all

4. Проверить текущее состояние:

git status

Можно отменить добавление файла командой:

git rm –-cached first.txt

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

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

1. Введем команду:

git commit -m "comment"

Ключ –m означает создание пользователем описания этого коммита.

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

git clean -df

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

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

1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).

2. Нажимаем кнопочку «+» и вводим название репозитория.

3. Выбираем тип Public (Private доступен только в платной версии).

4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).

5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).

git remote add origin git@github.com:nikname/project.git

Результат можно увидеть с помощью команды:

git remote -v

Если все правильно сделано, то увидим:

origin git@github.com:nikname/project.git (fetch) origin git@github.com:nikname/project.git (push)

Для отмены регистрации удаленного репозитария, введите:

git remote rm origin

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

git push -u github master

-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push

Полезные ресурсы
  • Более подробно про Git можно прочитать в книге Скотта Чакона и Бена Штрауба — Pro Git
  • За помощью с работой в Github переходим на сайт.

Отправка фиксаций в удаленный репозиторий

Используйте git push для отправки фиксаций в локальной ветви в удаленный репозиторий.

About git push

The git push command takes two arguments:

  • A remote name, for example, origin
  • A branch name, for example, main
git push REMOTE-NAME BRANCH-NAME 

As an example, you usually run git push origin main to push your local changes to your online repository.

Renaming branches

To rename a branch, you’d use the same git push command, but you would add one more argument: the name of the new branch. For example:

git push REMOTE-NAME LOCAL-BRANCH-NAME:REMOTE-BRANCH-NAME 

This pushes the LOCAL-BRANCH-NAME to your REMOTE-NAME , but it is renamed to REMOTE-BRANCH-NAME .

Dealing with «non-fast-forward» errors

If your local copy of a repository is out of sync with, or «behind,» the upstream repository you’re pushing to, you’ll get a message saying non-fast-forward updates were rejected . This means that you must retrieve, or «fetch,» the upstream changes, before you are able to push your local changes.

For more information on this error, see «Dealing with non-fast-forward errors.»

Pushing tags

By default, and without additional parameters, git push sends all matching branches that have the same names as remote branches.

To push a single tag, you can issue the same command as pushing a branch:

git push REMOTE-NAME TAG-NAME 

To push all your tags, you can type the command:

git push REMOTE-NAME --tags 

Deleting a remote branch or tag

The syntax to delete a branch is a bit arcane at first glance:

git push REMOTE-NAME :BRANCH-NAME 

Note that there is a space before the colon. The command resembles the same steps you’d take to rename a branch. However, here, you’re telling Git to push nothing into BRANCH-NAME on REMOTE-NAME . Because of this, git push deletes the branch on the remote repository.

Remotes and forks

You might already know that you can «fork» repositories on GitHub.

When you clone a repository you own, you provide it with a remote URL that tells Git where to fetch and push updates. If you want to collaborate with the original repository, you’d add a new remote URL, typically called upstream , to your local Git clone:

git remote add upstream THEIR_REMOTE_URL 

Now, you can fetch updates and branches from their fork:

git fetch upstream # Grab the upstream remote's branches > remote: Counting objects: 75, done. > remote: Compressing objects: 100% (53/53), done. > remote: Total 62 (delta 27), reused 44 (delta 9) > Unpacking objects: 100% (62/62), done. > From https://github.com/OCTOCAT/REPO >  * [new branch] main -> upstream/main 

When you’re done making local changes, you can push your local branch to GitHub and initiate a pull request.

For more information on working with forks, see «Syncing a fork».

Further reading

  • The «Remotes» chapter from the «Pro Git» book
  • git remote main page
  • «Git cheatsheet»
  • «Git workflows»
  • «Git Handbook»
  • «Troubleshooting the 2 GB push limit»

GitHub: работа с ветками и коммитами

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

Ветка (branch) — это история коммитов. Давайте сначала разберемся, что это такое.

Коммит (commit) — это информация об измененных файлах. Коммит состоит из автора коммита, измененных файлов, HEAD и времени. Для примеров мы будем использовать репозиторий и сделаем первый коммит, который отправим на сервер. Он нужен для того, чтобы разграничивать задачки. Так будет понятно, какой код в истории относится к той или иной задаче, чтобы потом мы могли быстро понять суть.

Например, у нас задача — сделать блок формы. Для этого мы сделаем нужные изменения в файле index.html & style.css, и даже через месяц сможем при помощи истории изменений просмотреть измененные куски кода именно для этого блока.

При помощи команды git log в консоли мы можем отслеживать историю коммитов в ветке.

На самом GitHub мы можем увидеть последний коммит в файле и последний коммит в ветке. Всю историю мы можем просмотреть, кликнув по кнопке n commits, где n — количество запущенных на сервер коммитов. У нас в ветке пока что один коммит, поэтому на ссылке надпись 1 commit.

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

Если вы кликните по сообщению в коммите, в нашем случае это add first commit, то попадёте в список всех изменённых файлов.

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

В нашем примере мы изменим содержание страницы index.html и добавим стили в style.css.

Изменения, не включенные в коммит, мы можем просмотреть при помощи команды git status.

Чтобы добавить файлы в коммит, мы будем использовать git add. Здесь мы можем указать нужные нам файлы для коммита, например, index.html. Если после этого мы сделаем git status, то эти файлики подсветятся зелёным — это означает, что мы можем добавить их к коммиту.

Но не всегда удобно вручную вбивать все изменённые файлы. В GitHub мы можем воспользоваться командой git add . — точка означает, что в коммит добавятся все изменённые файлы.

Теперь мы можем создать наш коммит при помощи команды git commit -m ‘текст коммита’. В тексте обычно рассказывается в паре слов о том, что было сделано — например, «добавили стили для index.html». Название коммитов пишут на русском или английском языке — зависит от того, как вы договоритесь с командной. После того, как вы создадите коммит, он появится у вас в истории.

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

У нас в коммите в сообщении есть опечатка, мы можем поменять подпись к последнему коммиту при помощи команды git commit —amend.

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

Теперь поговорим про ветки (branch). Ветка — это история изменений. Сейчас у в репозитории одна ветка main, в которой хранится стабильная версия. Как правило, новые задачи делаются в новых ветках, а потом вливаются в main после ревью кода.

Посмотрим, как выглядит наша ветка с двумя коммитами в графике.

Представим, что у нас есть задача — сделать форму на главной странице. Для этого создадим новую ветку git checkout -b form-index (ключ -b означает, что мы создаем новую ветку).

Ветки можно просматривать при помощи команды git branch.

История наших коммитов пока одинаковая — что у main, что у form-index. git checkout main без ключа -b означает, что мы переключаемся на уже существующую ветку.

Пробежимся git log и сравним наши ветки.

Тем не менее, если мы зайдем на GitHub, то обнаружим, что у нас там только одна ветка — main. Так происходит, потому что ветка form-index существует пока только на нашем компьютере, то есть локально.

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

Если посмотрим на историю коммитов в form, то увидим, что она отличается от main на один коммит.

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

Давайте создадим ветку form-index-fix и посмотрим на историю коммитов в ней.

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

Если ветка потеряла свою актуальность, мы можем её удалить локально при помощи команды git branch -D название ветки. Здесь важно отметить, что вы не можете удалить ветку, если вы сейчас в ней — обязательно нужно переключить её.

Если ветку нужно удалить на сервере, то сделать это можно при помощи интерфейса GitHub — нет рекомендаций, когда нужно удалять удалённые ветки.

Команды для консоли

  • git log — история коммитов.
  • git status— измененные файлы (показывает добавлены в коммит или нет).
  • git add file — добавить файл в коммит.
  • git add . — добавить все изменённые файлы в коммит.
  • git commit — m ‘text’ — добавить подпись коммитов.
  • git commit —amend— изменения сообщение последнего коммита.
  • git branch — посмотреть ветки.
  • git branch -v — просмотре веток с последним в ней коммитом.
  • git branch -d название ветки — удалить ветку.
  • git checkout название ветки — переключиться в ветку.
  • git checkout -b название ветки — создать новую ветку и сразу в неё переключиться.
  • git push сервер ветка – залить изменения на сервер в указанную ветку.
  • git push -f— залить изменения на сервер в режиме force, то есть с возможностью переписать уже имеющиеся коммиты на сервере. Будьте очень аккуратны с этой командой, а лучше минимизируйте её использование, ведь вы будете переписывать серверные файлы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *