git
Основная используемая система управления версиями. Сейчас я ещё больше уверена, что текстопишущим людям что-то такое практически необходимо, даже если они об этом не знают и всего такого боятся. Как обычно в этом садике - случайные заметки, тыренное. В надежде на упорядочивание со временем.
(вторая используемая иногда - fossil)
- https://docops.wave909.dev/#0 - инструкция для тех, кто «простые пользователи» винды, но не совсем в ужасе от компов :) Видео уютненького вебинара об этом же. если не открывается предыдущий.
- gitignore
- flashbake
- git в emacs
- https://habr.com/ru/post/161009/ - там обсуждают практики сложной жизни 2012 года.
- https://habr.com/ru/post/342116/ https://habr.com/ru/post/201922/ (Изменение коммитов в Git)
- https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%98%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8
- https://www.atlassian.com/ru/git/tutorials/rewriting-history
--full-history
- чтоб не терять всякие условно-неактуальные подробности истории- merge.renamelimit - иногда имеет смысл менять величину, возможно?
- https://git-scm.com/book/ru/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D1%81-%D1%83%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D0%BC%D0%B8
Мелкие памятки себе
Только один файл из другой ветки
git checkout master -- path/name.ext
или
git restore --source master -- path/name.ext
https://stackoverflow.com/questions/2364147/how-to-get-just-one-file-from-another-branch - там есть ещё варианты.
Коммит не в ту ветку, что делать?!
git reset HEAD~ --soft # вернулись к предыдущему коммиту, но не удаляем изменения git add . # изменения застейджили git stash # сохранили застейдженное в stash git checkout имя-верной-ветки # переключились куда надо git stash pop # извлекли сохранённое из stash
На этом месте могут образоваться конфликты слияния, которые надо решить до следующего шага. Не совсем автоматическая процедура.
git add . # застейджили уже здесь git commit -m "описание коммита" # закоммитили на нужное место
Сбросить изменения к последнему закоммиченному
git reset --hard HEAD
В отдельном файле:
git checkout путь/имяфайла
Срочно подправить ошибку, замеченную до пуша
git commit -a --amend --no-edit
Довнести все изменения, сообщение коммита не менять
detached head
If you want to delete your changes associated with the detached HEAD You only need to checkout the branch you were on, e.g.
git checkout master
Next time you have changed a file and want to restore it to the state it is in the index, don't delete the file first, just do
git checkout -- path/to/foo
This will restore the file foo to the state it is in the index.
If you want to keep your changes associated with the detached HEAD
git branch tmp # this will save your changes in a new branch called tmp. Очевидимо, вместо tmp можно любое другое название git checkout master
If you would like to incorporate the changes you made into master, run git merge tmp
from the master branch. You should be on the master branch after running git checkout master
.
Добавить удалённый (remote) репозиторий уже существующему локальному
Например
git remote add origin git@gitlab.com:agnessa/emacs-config.git
«git@gitlab.com:agnessa/emacs-config.git» - очевидимо, конкретный удалённый реп.
Про удалённые (deleted) файлы
https://stackoverflow.com/questions/6017987/how-can-i-list-all-the-deleted-files-in-a-git-repository
git log --diff-filter=D --summary
Краше
git log --all --pretty=format: --name-only --diff-filter=D | sort -u
This will get you a list of all files that were deleted in all branches, sorted by their path:
git log --diff-filter=D --summary | grep "delete mode 100" | cut -c 21- | sort > deleted.txt
Локальные настройки имени и адреса
Если в разных репозиториях нужно коммиты от разных Name+email.
git config --local user.name "Name" git config --local user.email email@mysite.ru
Или залезть в .git/config репозитория и написать
[user] email = name@mysite.ru name = Name
Проверка настроек
Если хотите проверить используемую конфигурацию, можно использовать команду git config –list, чтобы показать все настройки, которые Git найдёт:
$ git config --list user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto
Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из /etc/gitconfig
и ~/.gitconfig
). В таком случае Git использует последнее значение для каждого ключа.
Также вы можете проверить значение конкретного ключа, выполнив git config <key>:
$ git config user.name John Doe
Так как Git читает значение настроек из нескольких файлов, возможна ситуация когда Git использует не то значение что вы ожидали. В таком случае вы можете спросить Git об origin этого значения. Git выведет имя файла, из которого значение для настройки было взято последним:
$ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false
Настройка ключа для конкретного сервиса
Пишется в ~/.ssh/config
.
Host shortname HostName that.address.name User username IdentityFile ~/.ssh/key_for_service PreferredAuthentications publickey IdentitiesOnly yes
Посмотреть историю изменений одного файла
git log -p -- path/filename.txt
git reset –soft HEAD
this is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset".
Если коротко и по нашенски, то если что-то забыл закоммитить, то юзай выше указанное и коммить заново. По идее, в этой же ситуации можно amend - но это редактировать уже сделанное.
"git stripspace" - может убирать комментарии и ненужные пробелы
will do it for you and have 2 bonuses: it does not remove the indentation spaces (hehe, small bug in your Ruby code) and it adds an EOL at the EOF if needed.
репозиторий отказал в соединении по ключу
Недавно всё ещё работало, и вдруг внезапно отказывает в соединении.
При запросе ssh -vT git@example.server.name
получается много всего вроде бы ок, в конце:
debug1: send_pubkey_test: no mutual signature algorithm
debug1: No more authentication methods to try.
git@example.server.name: Permission denied (publickey).
Вероятно, обновили ssh на версию, которая перестала по умолчанию признавать некоторый тип ключей. По нынешним временам это ssh-rsa. Так что надо включить их поддержку в конфиге или в конкретной команде:
PubkeyAcceptedKeyTypes +ssh-rsa
ssh -o 'PubkeyAcceptedKeyTypes +ssh-rsa' example.server.name
И всё станет ок. По крайней мере, можно воспользоваться этим, чтобы загрузить более надёжный ключ. ssh
Куда писать инфу - почему не только и не столько в описание коммита
Написать тест, который будет контролировать появление новых подобных ошибок в проекте… При настроенном CI - это мощнейший инструмент для будущих участников проекта.
Если у вас появляется желание написать целую историю в сообщении к коммиту, вам следует подумать, как можно предоставить эту историю другим путем - тесты или документация намного лучше.
https://www.nikialeksey.com/2019/10/26/long-commit-message.html
Special GitLab References
GFM recognized special references.
You can easily reference e.g. an issue, a commit, a team member or even the whole team within a project.
GFM will turn that reference into a link so you can navigate between them easily.
GFM will recognize the following:
@foo : for specific team members or groups @all : for the whole team #123 : for issues !123 : for merge requests $123 : for snippets 1234567 : for commits [file](path/to/file) : for file references
GFM also recognizes references to commits, issues, and merge requests in other projects:
namespace/project#123 : for issues namespace/project!123 : for merge requests namespace/project@1234567 : for commits
%vcsh (для хранения конфигов)
While it may appear that there's an overwhelming amount of documentation and while the explanation of the concepts behind vcsh needs to touch a few gory details of git internals, getting started with vcsh is extremely simple.
Let's say you want to version control your vim configuration:
vcsh init vim vcsh vim add ~/.vimrc ~/.vim vcsh vim commit -m 'Initial commit of my Vim configuration'
vcsh vim remote add origin <remote> vcsh vim push -u origin master
vcsh vim push
If all that looks a lot like standard git, that's no coincidence; it's a design feature.
Stash
Если кто-то еще не пользуется git stash, советую обратить на эту команду пристальное внимание. Более чем удобно, занимаясь одним делом, «отложить» текущую работу в сторону и отвлечься, скажем, на срочное исправление бага, даже если он находится в другом бранче. После исправления и коммита можно преспокойно вернуться к начатому.
i. hack-hack-hack ii. git stash iii. fix-fix-fix iv. git commit -a -m 'bugfix #31337' v. git stash pop
Те же, кто знает про git stash, посмотрите на последнюю строку — её отличие от apply в том, что откладываемые результаты не остаются во временном хранилище (посмотрите git stash list после нескольких примений stash!)
Если изменение было фактически законченным, можно оформить коммит не отходят от кассы — git stash save 'commit msg'
%Интерактивное добавление файла в индекс с выбором отдельных чанков (частный случай -i)
git add -p #
Проверка «здоровья» репозитория и удаление из него мусора.
git fsck ( 1 ) git count-objects ( 2 ) git gc ( 3 )
( 1 ) Даже запуская без –full, вы легко и надёжно проверяете «здоровье» репозитория. ( 2 ) Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория. ( 3 ) переупаковка локальных репозиториев и другие виды повседневныз задач.
%bup
Very efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Current release is 0.26, and the development branch is master. Please post patches to the mailing list for discussion (see below).
Настройки при клонировании
После клонирования хранилища команды git push или git pull автоматически отправляют и получают его по первоначальному адресу. Каким образом Git это делает? Секрет кроется в настройках, заданных при создании клона. Давайте взглянем:
git config --list
Опция remote.origin.url задает исходный адрес; origin — имя первоначального хранилища. Как и имя ветки master, это соглашение. Мы можем изменить или удалить это сокращённое имя, но как правило, нет причин для этого.
Если оригинальное хранилище переехало, можно обновить его адрес командой
git config remote.origin.url git://новый.url/proj.git
Опция branch.master.merge задает удаленную ветку по умолчанию для git pull. В ходе первоначального клонирования она устанавливается на текущую ветку исходного хранилища, так что даже если HEAD исходного хранилища впоследствии переместится на другую ветку, pull будет верно следовать изначальной ветке.
Этот параметр обращается только к хранилищу, которое мы изначально клонировали и которое записано в параметре branch.master.remote. При выполнении pull из других хранилищ мы должны указать нужную ветку:
git pull git://пример.com/other.git master
Это объясняет, почему некоторых из наших предыдущих примеров push и pull не имели аргументов.
%git clone ssh:user@host:port/path
git fsck –full
This shows you all the objects that aren’t pointed to by another object. One of your commits should be in this list, and you can get the SHA1 hash!
.git/config для i2p
-
You have local tunnels set up as per the guide for pull.git.repo.i2p on port 9450 and push.git.repo.i2p on port 9451 You are linking the local Git repository to the hosted repository test.git. If the hosted repository is a fork, replace "test.git" with "base/fork.git" etc.
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git://127.0.0.1:9450/test.git pushurl = ssh://username@127.0.0.1:9451/srv/git/test.git fetch = +refs/heads/*:refs/remotes/origin/*