в Data science

git конспект

Вот отсюда https://ru.hexlet.io/courses/intro_to_git/lessons/intro/theory_unit

sudo apt install git
git config —global user.name «Sergei Makarov»
git config —global user.email «s.makarov@petrovich.ru»

mkdir example
cd example/
cat .git/config

touch README.md # Создаем файл
echo ‘# Hi’ > README.md # Меняем содержимое

# Первая git add подготавливает измененный или добавленный файл к коммиту. Без её выполнения сделать коммит не получится.
git add README.md # Так гит увидит новый файл

#А вот команда git commit непосредственно фиксирует изменения в репозитории
git commit -m ‘init project’ # Коммит с сообщением ‘init project’

#История коммитов
git log

# И просмотр изменений
git show 97d07816c757f3d548bddeb9acd5eddb824b3f3b

Если перед коммитов сделать git status

On branch master
Your branch is up-to-date with ‘origin/master’.
Changes to be committed: # Изменения попадающие в следующий коммит

new file: .editorconfig
modified: Dockerfile

Changes not staged for commit: # Изменения которые не попадут в коммит

modified: docker-compose.yml
deleted: rebar.lock

Untracked files: # Неотслеживаемые файлы

Procfile
Untracked – это новый файл, который не был добавлен для отслеживания командой git add. Все остальные файлы являются tracked.

С непривычки такое поведение может показаться странным. Почему бы сразу не давать возможность коммитить, без необходимости добавлять файл в отслеживаемые?
На самом деле такое поведение очень важно. Как вы убедитесь в своей практике, множество инструментов генерирует свои файлы (например, редакторы, операционная система, пакетные менеджеры), а запуск программ порождает файлы с логами и другие артефакты. И если бы git commit автоматически включал все новые файлы, в репозиторий после коммитов постоянно попадали бы ненужные данные.

Про tracked файлы

С unmodified все просто. Если файл в рабочей копии точно такой же как и в репозитории, то считается что его не модифицировали. Любой файл после коммита переходит в состояние unmodified.
Modified тоже интуитивно понятен. Как только мы изменили любой файл, он автоматически становится modified.
Но в коммит попадут только staged файлы, это те к кторым мы применили git add

git reset path/to/file переводит файл из состояния staged в modified
git checkout path/to/file переводит файл из состояния modified в unmodified, то есть по сути эта команда сбрасывает изменения.

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

git branch показывает в какой ветке работаю

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

example$ git init
example$ cd /tmp
git clone ~/example

Давайте теперь посмотрим главное — то, как отправлять изменения:
example$ echo ‘# Hello’ > README.md
example$ git commit -am ‘replace readme’
example$ git push

Написать Комментарий

Комментарии