Начало работы с Git: инициализация и клонирование репозиториев
Узнайте, когда использовать git init или git clone, а затем проверьте удаленные репозитории, ветки, идентификацию и игнорируемые файлы перед первым коммитом.
Начало работы с Git: инициализация и клонирование репозиториев
Инициализация и клонирование репозиториев — это два основных способа начать работу с Git. Вы либо превращаете существующую папку в репозиторий Git, либо копируете существующий репозиторий, чтобы работать с его файлами и историей.
Эти команды выглядят просто, но выбор, сделанный в начале, влияет на удаленные репозитории, ветки, игнорируемые файлы и командные рабочие процессы. Чистая настройка предотвращает путаницу в будущем.
Что содержит репозиторий Git
Репозиторий Git — это папка проекта со скрытым каталогом .git внутри. Этот каталог .git хранит историю коммитов, ссылки на ветки, информацию об удаленных репозиториях, конфигурацию и внутреннюю базу объектов Git.
Обычно вы не редактируете файлы .git вручную. Вы используете команды Git, и Git обновляет эти внутренние данные за вас.
Чтобы проверить, является ли папка уже репозиторием, выполните:
git status
Если Git говорит, что папка не является репозиторием, вы можете инициализировать его. Если он показывает ветку, измененные файлы или чистое рабочее дерево, Git уже отслеживает эту папку.
Полезно понимать три общие области:
- Рабочее дерево: файлы, которые вы видите и можете редактировать.
- Область подготовки: изменения, выбранные для следующего коммита.
- История репозитория: коммиты, которые Git уже записал.
Когда вы инициализируете или клонируете репозиторий, Git настраивает эти части, чтобы вы могли начать делать коммиты.
Инициализация нового репозитория
Используйте git init, когда у вас есть локальная папка проекта, которая еще не отслеживается Git.
Создайте папку и инициализируйте ее:
mkdir my-app
cd my-app
git init
Git создает скрытый каталог .git. Теперь вы можете добавлять файлы и делать первый коммит:
echo "# My App" > README.md
git add README.md
git commit -m "Add README"
Если ваша ветка по умолчанию должна называться main, вы можете установить это глобально перед созданием новых репозиториев:
git config --global init.defaultBranch main
Или переименовать текущую ветку после инициализации:
git branch -M main
Для реального проекта создайте .gitignore перед первым большим коммитом. Это предотвращает попадание папок зависимостей, результатов сборки, логов и локальных секретов в историю:
node_modules/
dist/
.env
*.log
Как только файл закоммичен, добавление его в .gitignore позже не удаляет его из истории. Вот почему ранние правила игнорирования важны.
Если вы планируете опубликовать репозиторий на хостинговом сервисе, сначала создайте там пустой удаленный репозиторий, затем подключите его:
git remote add origin [email protected]:example/my-app.git
git push -u origin main
Опция -u устанавливает отслеживание вышестоящей ветки. После этого простые git push и git pull знают, какую удаленную ветку использовать.
Клонирование существующего репозитория
Используйте git clone, когда репозиторий уже существует где-то еще. Клонирование копирует файлы проекта, историю и конфигурацию удаленного репозитория.
Основная команда:
git clone [email protected]:example/my-app.git
Git создает папку с именем репозитория. Чтобы выбрать другое имя локальной папки, добавьте его в конце:
git clone [email protected]:example/my-app.git worktree-app
После клонирования перейдите в папку и проверьте ее:
cd worktree-app
git status
git remote -v
git branch
По умолчанию удаленный репозиторий обычно называется origin. Это имя условное, не магическое. Оно указывает на URL, который Git будет использовать для получения и отправки изменений.
Вы можете увидеть URL-адреса клонирования HTTPS или SSH. HTTPS прост в начале, особенно для публичных репозиториев. SSH распространен для повседневной разработки, поскольку использует ключи и избегает повторных запросов пароля при правильной настройке.
Для большого репозитория вы можете использовать поверхностное клонирование:
git clone --depth 1 https://example.com/repo.git
Это загружает только недавнюю историю. Это полезно для задач CI или быстрой проверки, но может ограничить команды, которым нужны старые коммиты, теги или полная история. Для обычной разработки обычно лучше полное клонирование.
Если репозиторий использует подмодули, клонируйте с:
git clone --recurse-submodules [email protected]:example/platform.git
Или инициализируйте их после клонирования:
git submodule update --init --recursive
Подмодули добавляют еще один уровень управления репозиторием, поэтому прочитайте документацию по настройке проекта перед внесением изменений.
Общие первые проверки после настройки
После инициализации или клонирования выполните несколько проверок, прежде чем начать кодировать. Они помогают выявить неправильную конфигурацию на раннем этапе.
Проверьте свою идентификацию:
git config user.name
git config user.email
Если это рабочий репозиторий, убедитесь, что адрес электронной почты соответствует вашей учетной записи компании. Вы можете установить его локально:
git config --local user.email "[email protected]"
Проверьте удаленные репозитории:
git remote -v
Убедитесь, что URL-адреса fetch и push указывают на ожидаемый репозиторий. Случайная отправка в форк или личное зеркало может отнять время.
Проверьте текущую ветку:
git branch --show-current
Если вы клонировали репозиторий, прочитайте README или руководство по внесению вклада перед созданием ветки. Многие команды ожидают имена веток, такие как feature/ticket-123-short-description или fix/login-timeout.
Перед первым коммитом проверьте игнорируемые файлы:
git status --ignored
Это быстрый способ убедиться, что артефакты сборки и локальные секретные файлы не будут закоммичены.
Когда обращаться за помощью
Обратитесь к коллеге или сопровождающему репозитория за помощью, если вы не уверены, какой URL удаленного репозитория использовать, следует ли клонировать форк или основной репозиторий, или как должны обрабатываться подмодули.
Вам также следует остановиться, если вы инициализировали Git в неправильном каталоге. Например, выполнение git init в вашей домашней папке может заставить Git видеть тысячи несвязанных файлов. Не начинайте удалять вещи случайно. Подтвердите, где был создан .git, и удалите только ошибочные метаданные репозитория, если вы уверены, что они не содержат нужной истории.
Начало работы с Git в основном связано с чистыми привычками. Используйте git init для новых локальных проектов, git clone для существующих репозиториев и проверяйте свою ветку, удаленный репозиторий, идентификацию и игнорируемые файлы, прежде чем приступить к серьезной работе.