Git stage что это

Правила работы с git

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

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

GitHub — это один из популярных хостингов git-репозиториев.

Основные команды для работы с git

Для работы с git можно использовать GUI-приложения (в т.ч. интерфейсы для работы с git в Visual Studio и WebStorm), но в большинстве случаев, с git работают из консоли (эмулятор терминала).

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

Клонирование существующего репозитория

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

# Клонирование репозитория осуществляется командой git clone [URL]. git clone https://github.com/Flexberry/ember-flexberry.git 

Ветвление

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

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

Сделать новую ветку и переключится сразу на нее, можно выполнив команду git checkout -b .

Note: При создании веток соблюдайте правила их именования. Если ветка для добававления новой функциональность, то ее название должно иметь вид: feature— . Если ветка для исправлений, то fix— .

# Переключиться на ветку от которой надо наследоватся (обычно это основная ветка master или develop) git checkout develop # Получить последнии изменения для текущей ветки. git pull # Создать новую ветку. git checkout -b

Слить ветку в текущую, можно командой: git merge .

Запись изменений в репозииторий

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

Добавить изменения в staging area — git add или git add * если надо включить все изменения.

Удалить изменения из staging area — git checkout — или git checkout — * если надо удалить все изменения.

Просмотреть содержимое рабочей директории и staging area — git status

Зафиксировать(сохранить) подготовленные изменения в локальном репозитории — git commit -m «Комментарий к коммиту»

Note: Создавая коммит, надо использовать принятый в команде стандарт Conventional Commits.

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

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

Получить последние изменения, сделанные в ветке, с удаленного репозитория — git pull

Отправить зафиксированные изменения из локального репозитория в удаленный — git push origin

Полезные ссылки

• Простая шпаргалка по git
• Очень хороший туториал (практика)
• Принципы работы с git на реальном проекте
• Дополнительный материал: книга ProGIT

Зачем нужна staging area (index) в GIT?

Начал разбираться с git, попробовал писать команды, коммиты и т.д. Оценил некоторые интересные вещи. Но я так и не понял, почему я должен использовать staging area и stash? Для чего они были задуманы и как это делает жизнь разработчиков лучше? Каков для вас типичный ежедневный цикл работы с git?

Отслеживать
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
задан 13 окт 2012 в 8:29
AlexeyVorobyev AlexeyVorobyev
413 2 2 золотых знака 8 8 серебряных знаков 28 28 бронзовых знаков

stash, насколько я знаю, нужен для кэширования сделанных изменений, когда их нельзя залить на мастер сразу. Откуда такой граватар? Я тоже такой хочу.

13 окт 2012 в 11:32

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Индекс (staging area)

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

У меня типичный ежедневный цикл — 20-25 коммитов. Работаю в Netbeans

Команда git stash

Команда git stash нужна в основном тогда, когда Вам нужно временно спрятать текущие изменения.

Цитата: Часто возникает такая ситуация, что пока вы работаете над частью своего проекта, всё находится в беспорядочном состоянии, а вам нужно переключить ветки, чтобы немного поработать над чем-то другим. Проблема в том, что вы не хотите делать коммит с наполовину доделанной работой, только для того, чтобы позже можно было вернуться в это же состояние. Ответ на эту проблему — команда git stash.

Git для начинающих. Часть 5. Создание репозитория и первый коммит

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

• Создание репозитория git
• Создание первого коммита

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

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

> mkdir repo

Теперь перейдем в этот каталог.

>cd repo

Создадим в нем пустой git репозиторий.

> git init

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

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

> git log fatal: your current branch 'master' does not have any commits yet

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

> git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track) 

Создадим в нашем каталоге пустой файл.

> touch README.md

Теперь, если мы выполним команду git status , то увидим, что в нашем каталоге появился один неотслеживаемый файл: README.md .

> git status On branch master Initial commit Untracked files: (use "git add . " to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)

Добавим, созданный файл в stage . Stage (или cache ) – это хранилище для файлов с изменениями, информация о которых попадет в единый коммит. Stage является элементом архитектуры трех деревьев, на базе которой построен git , более подробно смотрите здесь. Для добавления файла README.md в stage необходимо воспользоваться командой git add .

> git add README.md

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

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

> git status On branch master Initial commit Changes to be committed: (use "git rm --cached . " to unstage) new file: README.md

Как видно, в stage был добавлен один файл с именем README.md и теперь представленный набор изменений готов к отправке в репозиторий – т.е. к коммиту. Сделаем это.

> git commit -m "[create repository]" [master (root-commit) 500067c] [create repository] 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md

Проверим статус каталога.

> git status On branch master nothing to commit, working tree clean

Как видно с момента последнего коммита никаких изменений в рабочем каталоге не производилось.

Теперь взглянем на список коммитов.

> git log commit 500067cc0b80643d38e2a24e9e0699031ada6be3 Author: Writer Date: Mon Feb 12 22:51:14 2018 +0500 [create repository]

Из приведенной информации видно, что был отправлен один коммит, который имеет ID : 500067cc0b80643d38e2a24e9e0699031ada6be3, более подробно об идентификаторах будет рассказано в следующих уроках. Автор данного коммита Writer , он (коммит) был создан Mon Feb 12 22:51:14 2018 +0500, с сообщением: [create repository] . Это довольно подробная информация, когда коммитов станет много, такой формат вывода будет не очень удобным, сокращенный вариант выглядит так.

> git log --oneline 500067c [create repository]

Подведем небольшое резюме вышесказанному.

Создание пустого репозитория.

> git init

Добавление файлов в stage .

> git add filename

> git commit -m “message”

Просмотр статуса каталога.

> git status

Просмотр коммитов в репозитории.

> git log

Просмотр коммитов в репозитории с сокращенным выводом информации.

> git log --oneline

Отличный курс по git делают ребята из GeekBrains , найдите в разделе “Курсы” курс “Git. Быстрый старт” , он бесплатный!

Раздел: Git Git для начинающих Метки: Git, Git для начинающих, Уроки по Git

Git для начинающих. Часть 5. Создание репозитория и первый коммит : 4 комментария

1. SGate 06.03.2019 Так все хорошо в этом курсе, все четко ясно до тех пор пока не было сказано ввести команду touch README.md потому что сразу получил ошибку “touch” является внутренней или внешней командой и т.д. Система Windows 10

1. writer 16.03.2019 Да, эта команда доступна только в Linux (по умолчанию). В Windows необходимо установить специальный пакет (cygwin) или, если это Windows 10, то можно прямо Ubuntu установить как приложение.
   Самый простой способ заменить эту команду в Windows 10 будет использование echo:
   echo “” > README.md
   В Linux эта команда должна выполниться без проблем)))

Зачем нужна stage area в Git?

Зачем нужно перед созданием commit помещать файлы в stage area? То есть понятно, что новые файлы нужно добавлять с помощью add, но зачем нужно добавлять файлы, уже находящиеся под контролем? Зачем была принята такая концепция? Ведь по сути получается, что stage area — это репозиторий в репозитории. Вначале мы добавляем файлы в stage, потом комитим их все в локальный репозиторий, потом делаем push в удаленный репозиторий. Зачем этот лишний шаг в виде stage?

• Вопрос задан более трёх лет назад
• 16333 просмотра

1 комментарий

Оценить 1 комментарий

С английским дружите?
Решения вопроса 1

Думаю, ответ немного банален — чтобы можно было выбирать, какие файлы включать в коммит.

Из практики — чаще всего случается git commit -am «. «, уже до автоматизма дошло. Т.е. смотрю статус, если есть новые — добавляю, и затем коммит с флагом -a. Но это у меня. Т.к. в моем случае git по большей мере нужен для коммандной работы — сам контроль версий не особо использую. Если нужно балансировать между версиями — используются бранчи.

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

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

Ответ написан более трёх лет назад
Нравится 3 6 комментариев

Не просто какие файлы включить в коммит — а какие изменения включить в коммит.

Например можно из 100 измененных строк в файле выборочно закомитить 10 и еще и отредактировать их в процессе. Использую очень часто.

Ни разу не пользовался. Интересно, как именно происходит работа с таким подходом — какая команда, как используются бранчи, по какому принципу происходит деплой (если речь о вебе, конечно же).