Это старая версия документа!
Git как таковой opensource-софт, вся работа выполняется непосредственно в нем, системы типа github / gitlab это общедоступные хранилища, в которых можно размещать репозитории для внешнего хранения, софт так или иначе работает прежде всего с локальным репозиторием и уже отдельным действием отправляет данные на внешку.
master главная ветка по умолчанию, создается первым коммитом
# Установка apt git install # Инициализация проекта cd /'project' && git init # Добавление файлов к проекту git add . (file1 file2 ...) # Фиксация изменений (-m коммент, -a применить ко всем либо к указанным файлам) git commit -m "Text comment" -a (or changed-file1) # Добавить удаленный репозиторий git remote add <name> <site>.git # Отправка на удаленный репозиторий git push <name> [master]
Авторизация
Непонятная ситуация с авторизацией, вроде ввели новый способ по токенам, по крайней мере в винде только через него получилось, в линуксе по ssh ключу удалось.. (используется id_rsa.pub)
Постоянная конфигурация хранится в файле «~/.bash_profile» (в винде по крайней мере)
Для хранения токенов можно использовать:
Минус в том что хранится в открытом виде, есть варианты store/cache, второй хранит 15 минут и только в памяти
git remote [-v] git remote add <name> <url> git remote remove/rename <name> git remote show <name> git push <name> [branch] # pull делает еще и merge сразу git fetch <name>
Слияние выполняется из той ветки в которую нужно добавить указанную (переходим в мастер и указываем ветку которую хотим в него добавить)
Слияние происходит в точке ответвления, если после ответвления, в источнике, данном месте были изменения, это вызывает конфликт слияния, решать который нужно вручную
Rebase в целом тоже самое что и слияние, но работает иначе, слияние совмещает последние коммиты веток, а перебазирование вставляет последний коммит в точку ответвления и применяет последовательно всю историю изменений, получается, тем самым делая его обновленной копией последнего коммита в мастере (в которую сливается)
Дока
git branch [-v] # Слитые [не слитые] ветки git branch --merged [--no-merged] [name] # Удалить (удалится только слитая ветка) git branch -d <name> git branch --all # Переключение веток и загрузка их в рабочий каталог git checkout <существующая ветка> git checkout -b <новая ветка> # История коммитов git log <имя ветки> <--all> git log --oneline --decorate --graph --all
# Удалить последний коммит (сдвинуть указатель на шаг назад) # Удаленный репозиторий может не принять такой прикол, для пуша добавляем --force git reset --hard HEAD~1 [либо хэш-код] # Слияние с предыдущим коммитом git commit --amend # Разница между текущим состоянием и указанным коммитом git diff <id-commit>
Коммит это слепок, содержит blob (большой бинарный) объект, и хеш сумму каждого файла, в т.ч. дерево каталогов.
Каждый коммит содержит ссылку на предыдущий так формируется цепочка.
Ветка это ничто иное как условный указатель на последний коммит, который будет указан родителем следующему. Master абсолютно обычная ветка, просто умолчательная и по наитию используется как основная
HEAD это указатель на текущую, локальную ветку, используемую сейчас, увидеть ее можно в команде git log
При переходе между ветками, заменяется все содержимое рабочего каталога, файлы автоматически подменяются
В файле просто перечисляются файлы/папки или их шаблоны, которые нужно игнорировать для загрузки, может располагаться в корне
Общее
Есть 4 основных элемента: Рабочий каталог, Промежуточная область, Локальный репозиторий, Удаленный репозиторий
Установка
Нормальный клиент здесь- https://gitforwindows.org/
После установки делаем подпись, в «git bash» пишем:
$ git config --global user.name "YourName" $ git config --global user.mail "YourMail" $ git config --global -- list
Доступ SSH
Затем настраиваем сертификат, для без парольного доступа.
git bash:
# Генерация ключевой пары (можно: -t rsa -b 4096 -C) $ ssh-keygen -t ed25519 -C "YourEMail"
Вводим имя файла, парольную фразу можно не вводить, чтобы не вводить ее при каждом обращении в git
После завершения, файлы будут в домашней директории пользователя, помещаем их в «~/.ssh»
закрытый ключ переименовываем в «id_rsa» (тут неясный момент!)
Содержимое открытого ключа («.pub») копируем при создании ключа в лк git'a, там нужно добавить ключ, с содержанием этого открытого ключа
Так же нужно добавить созданных ключ агенту авторизации
$ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/id_ed25519
После пишем: «$ ssh -T git@github.com» (можно добавить -vT, для расширенного вывода), для принятия сертификата, в ответе должна фигурировать строка типа: «Hi «YourName»! You've successfully authenticated, but GitHub does not provide shell access», если так, тогда все норм
Траблы с тортилой
При установке стоило совершить один неверный шаг и выбрать тортилу как транспорт, п*зда, от нее нет спасения, работать она не работает, с таким подходом во всяком случае, и сменить никак не удавалось долгое время, в итоге заменил переменную окружения GIT_SSH, установил путь к стандартной утилите («C:\Program Files\Git\usr\bin\ssh.exe») и заработало.
Использование
Репозитории создаются и далее привязаны к конкретным каталогам, для работы с репозиторием нужно перейти в его каталог.
Инициализация репозитория
Переходим в созданный каталог: «$ git init«
Добавление файлов
Добавление в промежуточную область: «$ git add .«
Точка добавит все, можно указать конкретные, либо маску
Просмотр состояния: «git status»
Фиксация изменений
Фиксация изменений в файлах: «$ git commit -m «text-comment»«
Отмена фиксации: «$ git reset HEAD~1«
Удаленный источник
Добавление: «$ git remote add origin <repo-url>«
Список доступных: «$ git remote -v«
Дополнительно
# Изменения в файлах: $ git diff # История фиксаций: $ git diff- ???? # Мержинг если есть конфликты коммитов $ git merge --allow-unrelated-histories