Многих пользователей, впервые столкнувшихся с Git, пугает сложность этой системы. Поэтому они начинают искать самоучитель или учебник по Git, чтобы облегчить свои проблемы. На самом деле, Git-система известна своей сложностью, но ее прелесть в том, что не нужно сразу изучать все об этой системе. Для того чтобы начать с ней работать, будет достаточно изучить основные команды, а потом постепенно «наращивать» свои знания о Git.
Git — это система управления версиями программы. Фактически Git — это набор специальных утилит, которые осуществляют контроль за файлами разрабатываемой программы. Не нужно путать Git и GitHub. Обе эти площадки выполняют похожие задачи, но Git инсталлируется и используется на вашем компьютере, а GitHub — это веб-площадка и «облачный» Git. К Git у вас есть доступ только с компьютера, где вы развернули эту систему, а к GitHub у вас будет доступ с любого устройства.
Git-системы необходимы для осуществления контроля за изменениями в вашем программном коде.
Допустим, вы внесли изменения, которые вас не удовлетворили. При помощи Git-системы вы сможете «откатить» проект до заданной точки и продолжить его изменять. Git и GitHub — не единственные системы контроля версий. Есть и другие представители, например:
SVN,
Mercurial,
Perforce,
CVS,
Bitkeeper,
и др.
Git-учебник
Git-учебник — это инструкция по тому, как начать пользоваться Git-системами. Первые шаги с Git мы опишем в данной статье. Для более глубокого изучения этой системы в конце статьи вы найдете список полезных учебных материалов, где будет полноценный Git-учебник, Git-самоучитель, онлайн-тесты и многое другое.
Чтобы начать пользоваться Git, для начала нужно установить специальные утилиты на свой компьютер.
Установка Git на компьютер
Инсталлировать Git на свое устройство несложно:
Установка на Linux. На Линукс-системах легче всего установить Git через терминал. Для этого в окне терминала нужно ввести: «sudo apt-get install git».
Установка на Windows. Нужно скачать программу «Git for Windows», которая устанавливается как обычная программа в этой операционной системе.
Установка на MacOS. Простой путь установки — использовать терминал. Для этого нужно вписать команду: «brew install git».
Если установить Git описанным выше способом, тогда дальнейшее взаимодействие с Git-системой будет проходить только через терминал. Основные команды для взаимодействия с Git через терминал мы опишем чуть ниже. Те, кому трудно дается работа с командами терминала, могут воспользоваться Git-клиентом с графическим интерфейсом — GitHub Desktop, который доступен для каждой известной операционной системы.
Git-учебник: основные команды для работы с Git-клиентом
После инсталляции Git на устройстве им можно начинать пользоваться. Если вы выбрали клиента с графическим интерфейсом, тогда вам будет немного полегче. Для тех, кто решил управлять Git-клиентом через терминал, будут полезными описанные ниже основные команды.
Чтобы настроить ваше имя пользователя и подключить к Git email, нужно воспользоваться следующими командами:
Git будет хранить файлы вашего проекта на жестком диске вашего компьютера. Когда вы используете облачный Git типа GitHub, тогда файлы хранятся на серверах этого ресурса, а не на вашем компьютере. Папка, где хранятся файлы проекта, называется «репозиторий». Обычно на компьютере создают папку с Git-проектами, где будут храниться репозитории. Допустим, вы создали на рабочем столе папку «git_project». Теперь, чтобы в ней создать новый репозиторий, необходимо воспользоваться следующими командами, вписав их в терминал:
Репозиторий создан, но он пока пустой. Поэтому создайте любой файл, например first.txt, и сохраните его в git_project.
Теперь самое время познакомиться с одной значимой командой в Git — status. При помощи этой команды можно узнать статус вашего репозитория, то есть отслеживается ли он Git-клиентом или нет. Если вы сейчас впишите эту команду, тогда получите следующее:
$ git status
On branch master
Initial commit
Untracked files:
(use «git add …» to include in what will be committed)
first.txt
Здесь сказано, что документ first.txt пока не отслеживается Git-клиентом. Чтобы Git стал его отслеживать, этот документ необходимо представить. Представление файлов в Git делается при помощи команды «add». То есть у нас это будет так:
$ git add first.txt
либо $ git add -A
Первая команда представляет конкретный документ, а вторая команда представляет все файлы, которые располагаются в директории.
Общее представление документов удобно, если вы создаете новый репозиторий и в нем сразу создаете несколько документов для своего будущего проекта.
Еще одним важным действием при работе с Git-клиентом является фиксация изменений в проекте или создание коммита, если говорить на программистском языке. В нашем случае мы добавили документ first.txt в репозиторий, но не зафиксировали это изменение. Чтобы создать коммит, необходимо вписать в терминале следующую команду:
Команда для сохранения изменений выглядит так «$ git commit -m», а все остальное — это комментарий к коммиту. В комментариях принято описывать, какие изменения были внесены и фиксируются в проекте. Подобный комментарий помогает быстро ориентироваться в коммитах, чтобы понимать, когда и что было сделано. Частоту создания коммитов вы выбираете самостоятельно либо по договоренности с командой.
Материалы для обучения: Git-учебник и Git-самоучитель
Как начать работу с Git — мы описали.
Чтобы изучить Git-клиент более подробно, нужно изучить следующие материалы:
Git-учебник «Pro Git»;
Git-самоучитель «Волшебство Git»;
интерактивный курс «GitHowTo»;
онлайн-тестирование по знанию Git на веб-ресурсе gitexercises.fracz.com;
видео-курс «Git для начинающих» от devcolibri.com;
курс «Введение в Git» от hexlet.io;
и др.
Заключение
Минус локального Git-клиента в том, что все файлы проекта находятся на вашем компьютере, а это значит, что ими довольно сложно поделиться с друзьями, а также работать совместно над одним проектом. Такая проблема локального Git решается при помощи слияния с облачным Git, например с GitHub.
Любой Git-учебник или курс подскажет, как это можно сделать.
Шпаргалка по Git от GitHub
Установка Git
GitHub предоставляет оконное приложение с графическим интерфейсом для выполнения основных операций с репозиторием, и
консольную версию Git с автоматическими обновлениями для расширенных сценариев работы.
GitHub Desktop
desktop.github.com
Дистрибутивы Git для систем Linux и POSIX доступны на официальном сайте Git SCM.
Git для всех платформ
git-scm.com
Первоначальная настройка
Настройка информации о пользователе для всех локальных репозиториев
$ git config --global user.name "[имя]"
Устанавливает имя, которое будет отображаться в поле автора у выполняемых вами коммитов
$ git config --global user.email "[адрес электронной почты]"
Устанавливает адрес электронной почты, который будет отображаться в информации о выполняемых вами коммитах
Создание репозитория
Создание нового репозитория или получение его по существующему URL-адресу
$ git init [название проекта]
Создаёт новый локальный репозиторий с заданным именем
$ git clone [url-адрес]
Скачивает репозиторий вместе со всей его историей изменений
Внесение изменений
Просмотр изменений и создание коммитов (фиксация изменений)
$ git status
Перечисляет все новые или изменённые файлы, которые нуждаются в фиксации
$ git diff
Показывает различия по внесённым изменениям в ещё не проиндексированных файлах
$ git add [файл]
Индексирует указанный файл для последующего коммита
$ git diff --staged
Показывает различия между проиндексированной и последней зафиксированной версиями файлов
$ git reset [файл]
Отменяет индексацию указанного файла, при этом сохраняет его содержимое
$ git commit -m "[сообщение с описанием]"
Фиксирует проиндексированные изменения и сохраняет их в историю версий
Коллективная работа
Именованные серии коммитов и соединение результатов работы
$ git branch
Список именованных веток коммитов с указанием выбранной ветки
$ git branch [имя ветки]
Создаёт новую ветку
$ git switch -c [имя ветки]
Переключается на выбранную ветку и обновляет рабочую директорию до её состояния
$ git merge [имя ветки]
Вносит изменения указанной ветки в текущую ветку
$ git branch -d [имя ветки]
Удаляет выбранную ветку
Операции с файлами
Перемещение и удаление версий файлов репозитория
$ git rm [файл]
Удаляет конкретный файл из рабочей директории и индексирует его удаление
$ git rm --cached [файл]
Убирает конкретный файл из контроля версий, но физически оставляет его на своём месте
$ git mv [оригинальный файл] [новое имя]
Перемещает и переименовывает указанный файл, сразу индексируя его для последующего коммита
Игнорирование некоторых файлов
Исключение временных и вторичных файлов и директорий
*. log
build/
temp-*
Git будет игнорировать файлы и директории, перечисленные в файле .gitignore с помощью wildcard синтаксиса
Сохранение и восстановление незавершённых изменений
$ git stash
Временно сохраняет все незафиксированные изменения отслеживаемых файлов
$ git stash pop
Восстанавливает состояние ранее сохранённых версий файлов
$ git stash list
Выводит список всех временных сохранений
$ git stash drop
Сбрасывает последние временно сохранённыe изменения
Просмотр истории
Просмотр и изучение истории изменений файлов проекта
$ git log
История коммитов для текущей ветки
$ git log --follow [файл]
История изменений конкретного файла, включая его переименование
$ git diff [первая ветка]. ..[вторая ветка]
Показывает разницу между содержанием коммитов двух веток
$ git show [коммит]
Выводит информацию и показывает изменения в выбранном коммите
Откат коммитов
Удаление ошибок и корректировка созданной истории
$ git reset [коммит]
Отменяет все коммиты после заданного, оставляя все изменения в рабочей директории
$ git reset --hard [коммит]
Сбрасывает всю историю вместе с состоянием рабочей директории до указанного коммита.
Синхронизация с удалённым репозиторием
Регистрация удалённого репозитория и обмен изменениями
$ git fetch [удалённый репозиторий]
Скачивает всю историю из удалённого репозитория
$ git merge [удалённый репозиторий]/[ветка]
Вносит изменения из ветки удалённого репозитория в текущую ветку локального репозитория
$ git push [удалённый репозиторий] [ветка]
Загружает все изменения локальной ветки в удалённый репозиторий
$ git pull
Загружает историю из удалённого репозитория и объединяет её с локальной. pull = fetch + merge
Git — документация gittutorial
НАЗВАНИЕ
gittutorial — введение в Git
внести в него изменения и поделиться изменениями с другими разработчиками.
Если вы в первую очередь заинтересованы в использовании Git для загрузки проекта,
например, чтобы протестировать последнюю версию, вы можете начать с
первые две главы Руководства пользователя Git.
Во-первых, обратите внимание, что вы можете получить документацию для такой команды, как git log --graph с:
$ man git-log
или:
$ git help log
С последним вы можете использовать средство ручного просмотра по вашему выбору; видеть
git-help[1] для получения дополнительной информации.
Рекомендуется представиться Git своим именем и
общедоступный адрес электронной почты перед выполнением каких-либо операций. Простейший
способ сделать это:
Предположим, у вас есть tar-архив project.tar.gz с вашей первоначальной работой. Ты
можно поместить его под контроль версий Git следующим образом.
$ tar xzf проект.tar.gz
$ компакт-диск проект
$ git init
Git ответит
Инициализирован пустой репозиторий Git в .git/
Теперь вы инициализировали рабочий каталог — вы можете заметить новый
созданный каталог с именем «.git».
Затем скажите Git сделать снимок содержимого всех файлов в
текущий каталог (обратите внимание на . ), с git add :
$ git add .
Этот моментальный снимок теперь хранится во временной промежуточной области, которую Git вызывает
«индекс». Вы можете постоянно хранить содержимое указателя в
репозиторий с git commit :
$ git commit
Это предложит вам сообщение фиксации. Теперь вы сохранили первый
версия вашего проекта в Git.
Внесение изменений
Изменить некоторые файлы, затем добавить их обновленное содержимое в индекс:
$ git добавить файл1 файл2 файл3
Теперь вы готовы к фиксации. Вы можете видеть, что должно быть совершено
используя git diff с параметром —cached:
$ git diff --cached
(без —cached git diff покажет вам любые изменения, которые
вы сделали, но еще не добавили в индекс.) Вы также можете получить краткую
сводка ситуации с git status :
$ git status
На мастере ветки
Изменения, которые необходимо зафиксировать:
Ваша ветка обновлена до «origin/master».
(используйте "git restore --staged ...", чтобы отменить постановку)
изменено: файл1
изменено: файл2
изменено: файл3
Если вам нужно сделать какие-либо дополнительные настройки, сделайте это сейчас, а затем добавьте
вновь измененный контент в index. Наконец, зафиксируйте свои изменения с помощью:
$ git commit
Это снова предложит вам сообщение с описанием изменения, а затем
записать новую версию проекта.
В качестве альтернативы, вместо предварительного запуска git add , вы можете использовать
$ git commit -a
, который автоматически заметит любые измененные (но не новые) файлы, добавьте
их в индекс и зафиксировать, все за один шаг.
Примечание к сообщениям фиксации: хотя это и не обязательно, рекомендуется
начинайте сообщение коммита с одного короткого (менее 50 символов)
строка, обобщающая изменение, за которой следует пустая строка, а затем еще
тщательное описание. Текст до первой пустой строки в коммите
сообщение рассматривается как заголовок коммита, и этот заголовок используется
по всему Гит. Например, git-format-patch[1] превращает
зафиксировать в электронной почте, и он использует заголовок в строке темы и
остальная часть фиксации в теле.
Git отслеживает содержимое, а не файлы
Многие системы контроля версий предоставляют команду add , которая сообщает
система, чтобы начать отслеживать изменения в новом файле. Команда Git добавить делает что-то более простое и мощное: git add используется как для новых
и недавно измененные файлы, и в обоих случаях делается снимок
заданные файлы и этапы, содержащиеся в индексе, готовые к включению в
следующий коммит.
Просмотр истории проекта
В любой момент вы можете просмотреть историю ваших изменений, используя
$ git log
Если вы также хотите видеть полные различия на каждом шаге, используйте
$ git log -p
Часто обзор изменений полезно, чтобы почувствовать
каждый шаг
$ git log --stat --summary
Управление ветвями
Один репозиторий Git может поддерживать несколько ветвей
разработка. Чтобы создать новую ветку с именем «экспериментальная», используйте
$ git ветка экспериментальная 9.0019
Если вы сейчас запустите
$ git branch
, вы получите список всех существующих веток:
Experimental
* master
«Экспериментальная» ветвь — это та, которую вы только что создали, а
Ветка «master» — это ветка по умолчанию, которая была создана для вас.
автоматически. Звездочка отмечает ветку, в которой вы сейчас находитесь;
введите
$ git switch Experimental
, чтобы переключиться на экспериментальную ветку. Теперь отредактируйте файл, зафиксируйте
изменить и вернуться к основной ветке:
Убедитесь, что сделанное вами изменение больше не видно, так как оно было
сделано на экспериментальной ветке, и вы вернулись на основную ветку.
Вы можете внести другое изменение в основную ветку:
(редактировать файл)
$ git commit -a
на данный момент две ветки разошлись с разными изменениями
сделано в каждом. Чтобы объединить изменения, сделанные в экспериментальном файле, с основным, запустите
$ git merge Experiment
Если изменения не конфликтуют, все готово. Если есть конфликты,
в проблемных файлах останутся маркеры, указывающие на конфликт;
$ git diff
покажет это. После того, как вы отредактировали файлы, чтобы решить проблему
конфликты,
$ git commit -a
зафиксирует результат слияния. Наконец,
$ gitk
покажет красивое графическое представление результирующей истории.
На этом этапе вы можете удалить экспериментальную ветку с
$ git branch -d Experiment
Эта команда гарантирует, что изменения в экспериментальной ветке
уже в текущей ветке.
Если развивать на ветке бред-идею, то пожалеть всегда можно
удалить ветку с
$ git branch -D Crazy-idea
Ветки дешевы и просты, так что это хороший способ попробовать что-нибудь
вне.
Использование Git для совместной работы
Предположим, Алиса начала новый проект с репозиторием Git в
/home/alice/project, и тот Боб, у которого есть домашний каталог на
такая же машина, хочет внести свой вклад.
Боб начинает с:
bob$ git clone /home/alice/project myrepo
Это создает новый каталог «myrepo», содержащий клон Алисы
репозиторий. Клон наравне с оригиналом
проект, обладающий собственной копией оригинальной истории проекта.
Затем Боб вносит некоторые изменения и фиксирует их:
(редактирование файлов)
bob$ git commit -a
(при необходимости повторить)
Когда он будет готов, он скажет Алисе извлечь изменения из репозитория. в /home/bob/myrepo. Она делает это с:
alice$ cd /home/alice/project
alice$ git pull /home/bob/myrepo master
Это объединяет изменения из ветки «master» Боба в ветку Алисы.
текущая ветка. Если Алиса за это время внесла свои изменения,
тогда ей может потребоваться вручную исправить любые конфликты.
Таким образом, команда "pull" выполняет две операции: извлекает изменения
из удаленной ветки, а затем объединяет их в текущую ветку.
Обратите внимание, что обычно Алиса хотела бы, чтобы ее локальные изменения были зафиксированы до
инициируя эту «тягу». Если работа Боба противоречит тому, что Алиса делала после
их истории разветвляются, Алиса будет использовать свое рабочее дерево и индекс для
разрешать конфликты, а существующие локальные изменения будут мешать
процесс разрешения конфликтов (Git по-прежнему будет выполнять выборку, но
отказаться от слияния — Алисе придется избавиться от своих локальных изменений в
каким-то образом и снова потяните, когда это произойдет).
Алиса может посмотреть, что сделал Боб, без предварительного слияния, используя «выборку»
команда; это позволяет Алисе проверить, что сделал Боб, используя специальный
символ "FETCH_HEAD", чтобы определить, есть ли у него что-нибудь стоящее
потянув, вот так:
Эта операция безопасна, даже если Алиса имеет незафиксированные локальные изменения.
Обозначение диапазона «HEAD..FETCH_HEAD» означает «показать все, что доступно
из FETCH_HEAD, но исключите все, что доступно из HEAD".
Алиса уже знает все, что приводит к ее текущему состоянию (ГОЛОВУ),
и просматривает то, что у Боба есть в его состоянии (FETCH_HEAD), чего у нее нет.
видел с этой командой.
Если Алиса хочет представить себе, что делал Боб с тех пор, как их истории разветвились
она может выполнить следующую команду:
$ gitk HEAD..FETCH_HEAD
Здесь используется то же обозначение диапазона с двумя точками, которое мы видели ранее с git log .
Алиса может захотеть посмотреть, что они оба сделали с момента разветвления.
Она может использовать форму с тремя точками вместо формы с двумя точками:
$ gitk HEAD...FETCH_HEAD
исключить все, что достижимо из них обоих».
Обратите внимание, что эти обозначения диапазона можно использовать как с gitk,
и "журнал git".
После проверки того, что сделал Боб, если нет ничего срочного, Алиса может
решить продолжить работу, не дёргая Боба. Если история Боба
есть что-то, что Алисе нужно немедленно, Алиса может выбрать
сначала спрячьте ее незавершенную работу, сделайте «вытягивание», а затем, наконец, расчехлите
ее незавершенная работа поверх полученной истории.
Когда вы работаете в небольшой тесно сплоченной группе, это не
непривычно взаимодействовать с одним и тем же хранилищем снова и снова
снова. По определению удаленный репозиторий , вы можете сделать
это проще:
alice$ git remote add bob /home/bob/myrepo
С этим Алиса может выполнить первую часть операции «вытягивания»
в одиночку, используя команду git fetch , не объединяя их со своей
ветка, используя:
alice$ git fetch bob
В отличие от полной формы, когда Алиса получает от Боба, используя
удаленный репозиторий, настроенный с помощью git remote , что было
fetched хранится в ветке удаленного отслеживания, в данном случае боб/мастер . Итак, после этого:
alice$ git log -p master..bob/master
показывает список всех изменений, которые Боб сделал с тех пор, как он отделился от
Основная ветвь Алисы.
Изучив эти изменения, Алиса
может объединить изменения в свою основную ветку:
alice$ git merge bob/master
Это слияние также может быть выполнено путем извлечения из ее собственного удаленного отслеживания
ветка , например:
alice$ git pull . пульты/боб/мастер
Обратите внимание, что git pull всегда объединяется с текущей веткой,
независимо от того, что еще указано в командной строке.
Позже Боб может обновить свой репозиторий последними изменениями Алисы, используя
bob$ git pull
Обратите внимание, что ему не нужно указывать путь к репозиторию Алисы;
когда Боб клонировал репозиторий Алисы, Git сохранил ее местоположение.
репозиторий в конфигурации репозитория, и это местоположение
используется для получения:
В качестве альтернативы Git имеет собственный протокол или может использовать http;
подробности см. в git-pull[1].
Git также можно использовать в режиме, подобном CVS, с центральным репозиторием
в которые различные пользователи вносят изменения; см. git-push[1] и
gitcvs-миграция[7].
Изучение истории
История Git представлена в виде серии взаимосвязанных коммитов. Мы
уже видели, что команда git log может перечислить эти коммиты. Обратите внимание, что в первой строке каждой записи журнала git также указывается имя
зафиксировать:
$ журнал git
зафиксировать c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Автор: Junio C Hamano
Дата: вторник, 16 мая, 17:18:22 2006 -07:00
merge-base: Уточнить комментарии к постобработке.
Мы можем дать это имя git show , чтобы увидеть подробности об этом
совершить.
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Но есть и другие способы ссылаться на коммиты. Вы можете использовать любой начальный
часть имени, достаточно длинная, чтобы однозначно идентифицировать фиксацию: 92 # показать второго родителя HEAD
Вы также можете дать своим коммитам имена; после запуска
$ git tag v2.5 1b2e1d63ff
вы можете обратиться к 1b2e1d63ff по имени «v2.5». Если вы собираетесь
поделиться этим именем с другими людьми (например, чтобы идентифицировать выпуск
версия), вы должны создать объект «тег» и, возможно, подписать его; видеть
git-tag[1] для подробностей.
Будьте осторожны с этой последней командой: помимо потери любых изменений
в рабочем каталоге, он также удалит все последующие коммиты из
эта ветка. Если эта ветвь является единственной ветвью, содержащей те
совершает, они будут потеряны. Кроме того, не используйте git reset на
общедоступная ветка, из которой берутся другие разработчики, так как она
заставить ненужные слияния на других разработчиков, чтобы очистить историю.
Если вам нужно отменить внесенные вами изменения, используйте git revert .
вместо.
Команда git grep может искать строки в любой версии вашего
проект, поэтому
$ git grep "hello" v2.5
ищет все вхождения «hello» в v2.5.
Если вы не укажете имя коммита, git grep будет искать любой из
файлы, которыми он управляет в вашем текущем каталоге. Итак,
$ git grep "hello"
— это быстрый способ поиска только тех файлов, которые отслеживаются Git.
Многие команды Git также принимают наборы коммитов, которые можно указать
несколькими способами. Вот несколько примеров с git log :
$ git log v2.5..v2.6 # коммиты между версиями 2.5 и 2.6
$ git log v2.5.. # фиксирует, начиная с версии 2.5
$ git log --since="2 days ago" # коммиты за последние 2 недели
$ git log v2.5.. Makefile # фиксирует, начиная с версии 2.5, которые изменяют
# Makefile
Вы также можете указать git log «диапазон» коммитов, где первый не
обязательно предок второго; например, если кончики
ветви «стабильная» и «хозяин» расходились от общего
совершить какое-то время назад, то
$ git log stable..master
перечислит коммиты, сделанные в ветке master, но не в ветке
стабильная ветка, а
$ git log master..stable
покажет список коммитов, сделанных в стабильной ветке, но не
основная ветвь.
Команда git log имеет недостаток: она должна представлять коммиты в
список. Когда в истории есть линии развития, которые расходятся и
затем снова объединены, порядок, в котором git log представляет
эти коммиты бессмысленны.
Большинство проектов с несколькими участниками (например, ядро Linux,
или сам Git) имеют частые слияния, а gitk лучше справляется с
визуализация их истории. Например,
$ gitk --since="2 days ago" drivers/
позволяет просматривать любые коммиты за последние 2 недели коммитов.
который изменил файлы в каталоге «драйверы». (Примечание: вы можете
настройте шрифты gitk, удерживая нажатой клавишу управления, одновременно нажимая
«-» или «+».)
Наконец, большинство команд, принимающих имена файлов, позволяют
предшествовать любому имени файла фиксацией, чтобы указать конкретную версию
файла:
$ git diff v2.5:Makefile HEAD:Makefile.in
Вы также можете использовать git show для просмотра любого такого файла:
$ git show v2.5:Makefile
Следующие шаги
достаточно для выполнения базовой распределенной ревизии
контроль над вашими проектами. Однако для полного понимания глубины
и сила Git вам нужно понять две простые идеи, на которых
базируется:
База данных объектов — довольно элегантная система, используемая для
хранить историю вашего проекта — файлы, каталоги и
совершает.
Индексный файл представляет собой кэш состояния дерева каталогов,
используется для создания коммитов, проверки рабочих каталогов и
держите различные деревья, участвующие в слиянии.
Вторая часть этого руководства объясняет объект
базу данных, индексный файл и некоторые другие мелочи, которые вам понадобятся.
нужно максимально использовать Git. Вы можете найти его на gittutorial-2[7].
Если вы не хотите продолжать с этим сразу, несколько других
отступления, которые могут быть интересны в этом месте:
git-format-patch[1], git-am[1]: они конвертируют
серии коммитов git в патчи, отправленные по электронной почте, и наоборот,
полезно для таких проектов, как ядро Linux, которые сильно зависят
на патчах, отправленных по электронной почте.
git-bisect[1]: когда в вашем
проект, один из способов отследить ошибку — выполнить поиск по
историю, чтобы найти точный коммит, который виноват. Git пополам
может помочь вам выполнить бинарный поиск для этой фиксации. Это
достаточно умен, чтобы выполнять поиск, близкий к оптимальному, даже в
случай сложной нелинейной истории с большим количеством слившихся ветвей.
gitworkflows[7]: дает обзор рекомендуемых
рабочие процессы.
giteveryday[7]: Git на каждый день с примерно 20 командами.
Изучите основы Git с помощью этого учебного пособия на космическую тематику.
Краткое описание миссии
Ваша миссия состоит в том, чтобы изучить основы Git, пройдя обучение и отследив все космические станции вашей команды. Команды, описанные в этом руководстве:
Как наш новый администратор космической станции Bitbucket, вы должны быть организованы. Когда вы создаете файлы для своей космической станции, вам нужно хранить их в одном месте и делиться ими с товарищами по команде, где бы они ни находились. В случае с Bitbucket это означает добавление всего в репозиторий. Давайте создадим его!
Шаг 1. Создайте репозиторий
Первоначально репозиторий, который вы создаете в Bitbucket, будет пустым без какого-либо кода. Это нормально, потому что вы скоро начнете добавлять в него некоторые файлы. Этот репозиторий Bitbucket будет центральным репозиторием для ваших файлов, а это означает, что другие могут получить доступ к этому репозиторию, если вы дадите им разрешение. После создания репозитория вы скопируете версию в свою локальную систему — таким образом вы сможете обновить ее из одного репозитория, а затем перенести эти изменения в другой.
Чтобы создать репозиторий, выполните следующие действия:
В Bitbucket щелкните значок + на глобальной боковой панели и выберите Репозиторий .
Bitbucket отображает страницу Создать новый репозиторий . Потратьте некоторое время, чтобы просмотреть содержимое диалогового окна. За исключением репозитория типа , все, что вы вводите на этой странице, вы можете позже изменить.
Введите BitbucketStationLocations для поля Имя . Bitbucket использует это имя в URL-адресе репозитория. Например, если у пользователя the_best есть репозиторий с именем awesome_repo , URL-адрес этого репозитория будет https://bitbucket.org/the_best/awesome_repo .
Для уровня доступа оставьте флажок Это частный репозиторий отмеченным. Частный репозиторий виден только вам и тем, кому вы даете доступ. Если этот флажок не установлен, ваш репозиторий будет виден всем.
Выберите Git для репозитория типа . Имейте в виду, что вы не можете изменить тип репозитория после того, как нажмете Создать репозиторий .
Нажмите Создать репозиторий . Bitbucket создает ваш репозиторий и отображает страницу Обзор .
Шаг 2. Изучите новый репозиторий
Найдите время, чтобы изучить только что созданный репозиторий. Вы должны быть на репозитории Обзор Страница:
Нажмите + на глобальной боковой панели для общих действий с репозиторием. Нажимайте элементы на боковой панели навигации, чтобы увидеть, что скрывается за каждым из них, включая «Настройки» для обновления сведений о репозитории и других настроек. Чтобы просмотреть ярлыки, доступные для навигации по этим элементам, нажмите клавишу ? Клавиша на клавиатуре.
Когда вы щелкнете параметр Commits на боковой панели, вы обнаружите, что у вас нет коммитов, потому что вы не создали никакого контента для своего репозитория. Ваш репозиторий является частным, и вы никого не приглашали в репозиторий, поэтому единственный человек, который прямо сейчас может создавать или редактировать содержимое репозитория, — это вы, владелец репозитория.
Скопируйте репозиторий Git и добавьте файлы
Теперь, когда у вас есть место для добавления и совместного использования файлов космической станции, вам нужен способ получить к ним доступ из вашей локальной системы. Чтобы настроить это, вы хотите скопировать репозиторий Bitbucket в свою систему. Git называет копирование репозитория «клонированием». Когда вы клонируете репозиторий, вы создаете соединение между сервером Bitbucket (который Git знает как источник) и вашей локальной системой.
Шаг 1. Клонируйте репозиторий в локальную систему
Откройте браузер и окно терминала с рабочего стола. После открытия окна терминала выполните следующие действия:
Перейдите в свой домашний (~) каталог
$ cd ~
По мере того, как вы будете больше использовать Bitbucket, вы, вероятно, будете работать с несколькими репозиториями. По этой причине рекомендуется создать каталог, содержащий все эти репозитории.
Создайте каталог для ваших репозиториев.
$ mkdir repos
В терминале обновите каталог, в котором вы хотите работать, до нового каталога репозиториев.
$ cd ~/repos
Из Bitbucket перейдите в репозиторий BitbucketStationLocations .
Нажмите значок + на глобальной боковой панели и выберите Клонировать этот репозиторий .
Bitbucket отображает всплывающее диалоговое окно клонирования. По умолчанию диалоговое окно клонирования устанавливает протокол на 9.0493 HTTPS или SSH , в зависимости от ваших настроек. Для целей этого руководства не меняйте протокол по умолчанию.
Скопируйте выделенную команду клонирования.
В окне терминала вставьте команду, скопированную из Bitbucket, и нажмите Return .
Введите свой пароль Bitbucket, когда терминал запросит его. Если вы создали учетную запись, связавшись с Google, используйте свой пароль для этой учетной записи.
Пароль для 1 'https://emmap @bitbucket.org': такого файла или каталога нет
Затем вернитесь к шагу 4 и повторите процесс клонирования. Теперь агент bash должен запросить у вас пароль. Вы должны сделать это только один раз.
На этом этапе окно вашего терминала должно выглядеть примерно так: bitbucketstationlocations'... Пароль предупреждение: похоже, вы клонировали пустой репозиторий.
Перечислите содержимое вашего каталога репозиториев, и вы должны увидеть в нем каталог bitbucketstationlocations .
Поздравляем! Вы клонировали свой репозиторий в локальную систему.
Шаг 2. Добавьте файл в локальный репозиторий и поместите его на Bitbucket
Теперь, когда репозиторий находится в вашей локальной системе, пора приступать к работе. Вы хотите начать отслеживать все местоположения ваших космических станций. Для этого давайте создадим файл со всеми вашими местоположениями.
Перейдите в окно терминала и перейдите на верхний уровень локального репозитория.
$ cd ~/repos/bitbucketstationlocations/
Введите следующую строку в окно терминала, чтобы создать новый файл с содержимым.
$ echo "Земля Луна" >> locations.txt
Если командная строка ничего не возвращает, значит, вы создали файл правильно!
Получите статус вашего локального репозитория. 9Команда 0015 git status сообщает вам о том, как продвигается ваш проект по сравнению с вашим репозиторием Bitbucket.
В этот момент Git знает, что вы создали новый файл, и вы увидите что-то вроде этого:
$ git status On branch main Initial commit Untracked files: (используйте < "git ad d) file>...", чтобы включить в то, что будет зафиксировано) locations.txt ничего не добавлено для фиксации, но присутствуют неотслеживаемые файлы (используйте "git add" для отслеживания)
Файл не отслеживается, что означает, что Git видит файл, не являющийся частью предыдущей фиксации. Вывод состояния также показывает вам следующий шаг: добавление файла.
Скажите Git отслеживать ваш новый файл location.txt с помощью команды git add . Так же, как и при создании файла, команда git add ничего не возвращает при правильном вводе.
$ git add location.txt
Команда git add перемещает изменения из рабочего каталога в промежуточную область Git. Промежуточная область — это место, где вы подготавливаете моментальный снимок набора изменений перед их фиксацией в официальной истории.
Проверьте состояние файла.
$ git статус На ветке main Первоначальная фиксация Изменения, которые должны зафиксироваться: (используйте "git rm --cached ...", чтобы отменить этап) новый файл: location.txt
Теперь вы можете видеть, что новый файл добавлен (подготовлен), и вы можете зафиксировать его, когда будете готовы. Команда git status отображает состояние рабочего каталога и промежуточного снимка.
Введите команду git commit с сообщением фиксации, как показано в следующей строке. -m указывает, что следует сообщение фиксации.
Snapshot проекта git фиксирует его историю и фиксирует историю. В сочетании с git add этот процесс определяет базовый рабочий процесс для всех пользователей Git.
До этого момента все, что вы делали, было в вашей локальной системе и невидимо для вашего репозитория Bitbucket, пока вы не отправите эти изменения.
Узнайте больше о Git и удаленных репозиториях
Способность Git взаимодействовать с удаленными репозиториями (в вашем случае Bitbucket является удаленным репозиторием) является основой любого рабочего процесса совместной работы на основе Git.
Модель совместной работы Git предоставляет каждому разработчику собственную копию репозитория с собственной локальной историей и структурой ветвей. Пользователям обычно нужно поделиться серией коммитов, а не одним набором изменений. Вместо фиксации набора изменений из рабочей копии в центральный репозиторий Git позволяет вам совместно использовать целые ветки между репозиториями.
Вы управляете соединениями с другими репозиториями и публикуете локальную историю, «отталкивая» ветки в другие репозитории. Вы видите, что внесли другие, «вытягивая» ветки в свой локальный репозиторий.
Вернитесь в окно локального терминала и отправьте зафиксированные изменения в Bitbucket, используя git push origin main . Эта команда указывает, что вы отправляете данные в основную ветку (ветвь на Bitbucket) в источнике (на сервере Bitbucket).
Вы должны увидеть что-то похожее на следующий ответ:
$ git push origin main Подсчет объектов: 3, выполнено. Запись объектов: 100% (3/3), 253 байта | 0 байт/с, готово. Всего 3 (дельта 0), повторно использовано 0 (дельта 0) К https://[email protected]/emmap1/bitbucketstationlocations.git * [новая ветка] основная -> основная от происхождения.
Ваши коммиты теперь находятся в удаленном репозитории (источник).
Перейдите в свой репозиторий BitbucketStationLocations на Bitbucket.
Если вы нажмете Фиксирует на боковой панели, вы увидите один коммит в своем репозитории. Bitbucket объединяет все, что вы только что сделали, в этот коммит и показывает его вам. Вы можете видеть, что в столбце «Автор» указано значение, которое вы использовали при настройке глобального файла Git ( ~/.gitconfig) . Если нажать Источник на боковой панели вы увидите, что в вашем репозитории есть один исходный файл, файл locations.txt , который вы только что добавили.
Помните, как выглядел репозиторий, когда вы впервые его создали? Наверное, сейчас это выглядит немного иначе.
Извлечь изменения из вашего репозитория Git в облаке Bitbucket
Далее в вашем списке действий администратора космической станции вам нужен файл с более подробной информацией о вашем местоположении. Поскольку на данный момент у вас не так много местоположений, вы собираетесь добавить их прямо из Bitbucket.
Шаг 1. Создайте файл в Bitbucket
Чтобы добавить новый файл расположений, выполните следующие действия:
В репозитории BitbucketStationLocations щелкните Источник , чтобы открыть исходный каталог. Обратите внимание, что у вас есть только один файл, location.txt , в вашем каталоге.
A. Исходная страница: Щелкните ссылку, чтобы открыть эту страницу. B. Выбор ветки: Выберите ветку, которую хотите просмотреть. C. Кнопка «Дополнительные параметры»: Нажмите, чтобы открыть меню с дополнительными параметрами, такими как «Добавить файл». D. Область исходного файла: Просмотр каталога файлов в Bitbucket.
На странице Источник нажмите кнопку Дополнительные параметры в правом верхнем углу и выберите Добавить файл в меню. Кнопка Дополнительные параметры появляется только после того, как вы добавили хотя бы один файл в репозиторий.
Откроется страница для создания нового файла, как показано на следующем рисунке.
A. Ветка с новым файлом: Измените, если хотите добавить файл в другую ветку. B. Область нового файла: Добавьте сюда содержимое для нового файла.
Введите stationlocations в поле имени файла .
Выберите HTML из списка Режим синтаксиса .
Добавьте в текстовое поле следующий HTML-код:
У Bitbucket есть следующие космические станции:
9.0678
Земная Луна
Штаб-квартира
Нажмите Подтвердить . Появится поле Commit message с сообщением: stationlocations created online with Bitbucket.
Нажмите Подтвердить под полем сообщения.
Теперь у вас есть новый файл в Bitbucket! Вы попадаете на страницу с подробной информацией о коммите, где вы можете увидеть изменения, которые вы только что сделали:
Если вы хотите просмотреть список коммитов, которые вы уже сделали, нажмите Фиксирует на боковой панели.
Шаг 2. Получение изменений из удаленного репозитория
Теперь нам нужно добавить этот новый файл в ваш локальный репозиторий. Этот процесс довольно прямолинеен, по сути, это просто обратный толчок, который вы использовали для загрузки файла location.txt в Bitbucket.
Чтобы загрузить файл в локальный репозиторий, выполните следующие действия:
Откройте окно терминала и перейдите на верхний уровень локального репозитория.
$ cd ~/repos/bitbucketstationlocations/
Введите команду git pull --all , чтобы получить все изменения из Bitbucket. (В более сложных ветвящихся рабочих процессах извлечение и объединение всех изменений может оказаться нецелесообразным.) Введите свой пароль Bitbucket, когда его попросят. Ваш терминал должен выглядеть примерно так:
$ git pull --all Извлечение источника remote: Подсчет объектов: 3, готово. удаленный: Сжатие объектов: 100 % (3/3), готово. удаленный: всего 3 (дельта 0), повторно использовано 0 (дельта 0) распаковка объектов: 100% (3/3), выполнено. Из https://bitbucket.org/emmap1/bitbucketstationlocations fe5a280..fcbeeb0 main -> origin/main 5 ++++++++++++++ 1 файл изменен, 5 вставок (+) создать режим 100644 stationlocations
Команда git pull объединяет файл из удаленного репозитория (Bitbucket). в ваш локальный репозиторий с помощью одной команды.
Перейдите в папку репозитория в локальной системе, и вы увидите только что добавленный файл.
Фантастика! Добавив два файла о местоположении вашей космической станции, вы выполнили базовый рабочий процесс Git (клонирование, добавление, фиксация, отправка и извлечение) между Bitbucket и вашей локальной системой.
Используйте ветку Git для слияния файла
Работа администратором космической станции сопряжена с определенными обязанностями. Иногда вам нужно держать информацию под замком, особенно при нанесении на карту новых мест в Солнечной системе. Ветки обучения позволят вам обновлять свои файлы и делиться информацией только тогда, когда вы будете готовы.
Ветки наиболее эффективны, когда вы работаете в команде. Вы можете работать над своей частью проекта из своей собственной ветки, получать обновления из Bitbucket, а затем объединять всю свою работу с основной веткой, когда она будет готова. Наша документация включает в себя дополнительные объяснения того, почему вы хотите использовать ветки.
Ветвь представляет собой независимую линию развития вашего репозитория. Думайте об этом как о совершенно новом рабочем каталоге, промежуточной области и истории проекта. Прежде чем создавать какие-либо новые ветки, вы автоматически начинаете с основной ветки. В качестве наглядного примера на этой диаграмме показаны основная ветвь и другая ветвь с обновлением для исправления ошибок.
Шаг 1. Создайте ветку и внесите изменения
Создайте ветку, в которую вы можете добавить планы на будущее для космической станции, которые вы не готовы зафиксировать. Когда вы будете готовы сообщить об этих планах всем, вы можете объединить изменения в свой репозиторий Bitbucket, а затем удалить ненужную ветку.
Важно понимать, что ветки — это просто указатели на коммиты. Когда вы создаете ветку, все, что нужно сделать Git, — это создать новый указатель — он не создает целый новый набор файлов или папок. Прежде чем вы начнете, ваш репозиторий выглядит так:
Чтобы создать ветку, выполните следующие действия:
Перейдите в окно терминала и перейдите на верхний уровень локального репозитория, используя следующую команду:
cd ~/repos/bitbucketstationlocations/ ветку из окна терминала.
$ git branch future-plans
Эта команда создает ветку, но не переключает вас на нее, поэтому ваш репозиторий выглядит примерно так:
История репозитория остается неизменной. Все, что вы получаете, это новый указатель на текущую ветку. Чтобы начать работу над новой веткой, вам нужно проверить ветку, которую вы хотите использовать.
Проверьте новую ветку, которую вы только что создали, чтобы начать ее использовать.
$ git checkout future-plans Переключено на ветку 'future-plans'
Команда git checkout работает рука об руку с ветка git . Поскольку вы создаете ветку для работы над чем-то новым, каждый раз, когда вы создаете новую ветку (с git branch ), вы хотите проверить ее (с git checkout ), если вы собираетесь использовать это. Теперь, когда вы проверили новую ветку, ваш рабочий процесс Git выглядит примерно так:
Найдите папку bitbucketstationlocations в вашей локальной системе и откройте ее. Вы заметите, что в результате новой ветки в каталоге нет лишних файлов или папок.
Откройте файл stationlocations с помощью текстового редактора.
Внесите изменения в файл, добавив местоположение другой станции:
У Bitbucket есть следующие космические станции:
Земная Луна
Штаб-квартира
Марс
Отдел отдыха
Сохраните и закройте файл.
Введите git status в окне терминала. Вы увидите что-то вроде этого:
$ git status Будущие планы ветки Изменения, не подготовленные для фиксации: (используйте "git add ...", чтобы обновить то, что будет зафиксировано) (используйте "git checkout — ..." для отмены изменений в рабочем каталоге) изменено: stationlocations никаких изменений не добавлено в коммит (используйте "git add" и/или "git commit -a")
Обратите внимание на строку On Branch Future-Plans ? Если вы ввели git status ранее, строка была на ветке main , потому что у вас была только одна main ветвь . Прежде чем вносить или фиксировать изменение, всегда проверяйте эту строку, чтобы убедиться, что ветка, в которую вы хотите добавить изменение, извлечена.
Подготовьте файл.
$ git добавить станции
Введите команду git commit в окне терминала, как показано ниже:
$ git commit stationlocations -m 'внесение изменений в ветку' [future-plans e3b7732] внесение изменений в ветку 1 файл изменен, 4 вставки (+)
После этой последней фиксации ваш репозиторий выглядит примерно так:
0015 основная ветвь.
Шаг 2. Объедините вашу ветку: быстрое слияние
Ваша космическая станция растет, и пришло время для церемонии открытия вашей марсианской локации. Теперь, когда ваши планы на будущее становятся реальностью, вы можете объединить свою ветку future-plans с основной веткой в вашей локальной системе.
Поскольку вы создали только одну ветвь и внесли одно изменение, используйте для слияния метод быстрой перемотки ветвей. Вы можете выполнить ускоренное слияние, потому что у вас есть линейный путь от текущей вершины ветки к целевой ветке. Вместо «фактического» слияния веток все, что Git должен сделать для интеграции истории, — это переместить (то есть «перемотать вперед») текущую ветку вверх к целевой ветке. Это эффективно объединяет истории, поскольку все коммиты, доступные из целевой ветки, теперь доступны через текущую.
Этот рабочий процесс ветки является обычным для недолговечных тематических веток с небольшими изменениями и не так распространен для долговременных функций.
Чтобы выполнить ускоренное слияние, выполните следующие действия:
Перейдите в окно терминала и перейдите на верхний уровень локального репозитория.
$ cd ~/repos/bitbucketstationlocations/
Введите команду git status , чтобы убедиться, что все ваши изменения зафиксированы, и узнать, какую ветку вы извлекли.
$ git статус На ветке будущие планы ничего не коммитить, рабочая директория чистая
Переключиться на основную ветку .
$ git checkout main Переключено на ветку 'main' Ваша ветка обновлена с 'origin/main'.
Объединить изменения из ветки future-plans в основную ветку . Это будет выглядеть примерно так:
Когда вы удаляете планов на будущее , вы по-прежнему можете получить доступ к ветке из основной с помощью идентификатора коммита. Например, если вы хотите отменить изменения, добавленные из future-plans , используйте только что полученный идентификатор фиксации, чтобы вернуться к этой ветке.
Введите git status , чтобы увидеть результаты слияния, которые показывают, что ваш локальный репозиторий на один опережает удаленный репозиторий. Это будет выглядеть примерно так:
$ git status На основной ветке Ваша ветка опережает origin/main на 1 коммит. (используйте "git push", чтобы опубликовать свои локальные коммиты) ничего не нужно коммитить, рабочий каталог чист
Вот что вы уже сделали: ветка
Зафиксировала изменение в новой ветке
Интегрировала это изменение обратно в основную ветку
Удалила ветку, которую вы больше не используете.
Затем нам нужно отправить всю эту работу обратно в Bitbucket, ваш удаленный репозиторий.
Шаг 3. Отправьте изменения в Bitbucket
Вы хотите, чтобы все могли видеть местонахождение новой космической станции. Для этого вы можете передать текущее состояние вашего локального репозитория в Bitbucket.
На этой диаграмме показано, что происходит, когда в локальном репозитории есть изменения, которых нет в центральном репозитории, и вы отправляете эти изменения в Bitbucket.
Вот как отправить изменения в удаленный репозиторий:
В каталоге репозитория в окне терминала введите git push origin main , чтобы отправить изменения. В результате получится что-то вроде этого:
$ git push origin main Подсчет объектов: 3, готово. Дельта-сжатие с использованием до 8 потоков. Сжатие объектов: 100% (3/3), выполнено. Запись объектов: 100% (3/3), 401 байт | 0 байт/с, готово. Всего 3 (дельта 0), повторно использовано 0 (дельта 0) To https://emmap1@bitbucket. org/emmap1/bitbucketstationlocations.git fcbeeb0..e3b7732 main -> main
Щелкните страницу Обзор репозитория Bitbucket и обратите внимание, что вы можете увидеть свой push в Недавняя активность поток.
Щелкните Commits , и вы увидите фиксацию, сделанную вами в вашей локальной системе. Обратите внимание, что изменение сохраняет тот же идентификатор фиксации, что и в вашей локальной системе.
Вы также можете видеть, что строка слева от списка коммитов имеет прямой путь и не показывает ответвлений. Это потому, что ветка future-plans никогда не взаимодействовала с удаленным репозиторием, а только с изменениями, которые мы создали и зафиксировали.
Нажмите Ветви и обратите внимание, что на странице также нет записи о ветке.
Щелкните Source , а затем щелкните файл stationlocations .
..[вторая ветка]
pull = fetch + merge
Вы можете видеть, что должно быть совершено
используя git diff с параметром —cached:
Поэтому создайте любой файл, например first.txt, и сохраните его в git_project.
log
build/
temp-*
email 
Теперь отредактируйте файл, зафиксируйте
изменить и вернуться к основной ветке:
в /home/bob/myrepo. Она делает это с:
Итак, после этого:
origin.url
/дом/алиса/проект 
Обратите внимание, что в первой строке каждой записи журнала git также указывается имя
зафиксировать:
Вот несколько примеров с git log :
Это
достаточно умен, чтобы выполнять поиск, близкий к оптимальному, даже в
случай сложной нелинейной истории с большим количеством слившихся ветвей.
Когда вы создаете файлы для своей космической станции, вам нужно хранить их в одном месте и делиться ими с товарищами по команде, где бы они ни находились. В случае с Bitbucket это означает добавление всего в репозиторий. Давайте создадим его!
Имейте в виду, что вы не можете изменить тип репозитория после того, как нажмете Создать репозиторий .
Ваш репозиторий является частным, и вы никого не приглашали в репозиторий, поэтому единственный человек, который прямо сейчас может создавать или редактировать содержимое репозитория, — это вы, владелец репозитория.
По этой причине рекомендуется создать каталог, содержащий все эти репозитории.
Промежуточная область — это место, где вы подготавливаете моментальный снимок набора изменений перед их фиксацией в официальной истории.
txt 
Поскольку на данный момент у вас не так много местоположений, вы собираетесь добавить их прямо из Bitbucket.
Кнопка Дополнительные параметры появляется только после того, как вы добавили хотя бы один файл в репозиторий.
(В более сложных ветвящихся рабочих процессах извлечение и объединение всех изменений может оказаться нецелесообразным.) Введите свой пароль Bitbucket, когда его попросят. Ваш терминал должен выглядеть примерно так:
Думайте об этом как о совершенно новом рабочем каталоге, промежуточной области и истории проекта. Прежде чем создавать какие-либо новые ветки, вы автоматически начинаете с основной ветки. В качестве наглядного примера на этой диаграмме показаны основная ветвь и другая ветвь с обновлением для исправления ошибок.
Вы заметите, что в результате новой ветки в каталоге нет лишних файлов или папок.
Прежде чем вносить или фиксировать изменение, всегда проверяйте эту строку, чтобы убедиться, что ветка, в которую вы хотите добавить изменение, извлечена.
org/emmap1/bitbucketstationlocations.git 