git

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 clean -i -d

• -d - чтоб заглядывал в неотслеживаемые каталоги.
• как вариант, можно использовать -n для того, чтоб посмотреть, что будет вычищено, и -f - чтоб таки сделать это.)
• в –help можно прочитать ещё потенциально полезного. Например, -X позволяет убрать файлы, которые git игнорирует.

git revert <хеш_коммита>

Создаёт новый коммит, который делает изменения, обратные изменениям в нежелательном коммите.

git commit -a --amend --no-edit

Довнести все изменения, сообщение коммита не менять

Или

git reset --soft 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.

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

https://git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9F%D0%B5%D1%80%D0%B2%D0%BE%D0%BD%D0%B0%D1%87%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-Git

Если в разных репозиториях нужно коммиты от разных 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 об источнике этого значения. Git выведет имя файла, из которого значение для настройки было взято:

$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig	false

В кавычках, разумеется, строка

git log -S '7b28ff06-ab13-4070-8dc2-fcbc9fe2f0b0'

• this looks for differences that introduce or remove an instance of <string>. It usually means "revisions where you added or removed line with 'Foo'".

• the –pickaxe-regex option allows you to use extended POSIX regex instead of searching for a string. Example (from git log): git log -S"frotz\(nitfol" –pickaxe-regex

  С регэкспом

git log -G<regexp> --branches --al

https://stackoverflow.com/questions/2928584/how-to-grep-search-committed-code-in-the-git-history

И без учёта регистра

git log -S foobar -i --oneline

or

git log --regexp-ignore-case -Sfoobar

or

git log -i -Sfoobar

Note that with 1.x git versions this option will not work with a regexps, only with a fixed string. It works with regexps only since git 2.0 and commit 218c45a, git 2.0, May 2014.

https://stackoverflow.com/questions/25384842/case-insensitive-git-pickaxe-search

Не удаляет пробелы, используемые в качестве отступов. Добавляет заключительный перенос строки в конце файла, если его нет.

git log -1 --pretty="format:%ci" /path/to/repo/anyfile.any

-1 restricts it to the very last time the file changed

%ci is just one of the date formats you can choose from others here at https://git-scm.com/docs/pretty-formats

https://stackoverflow.com/questions/22497597/get-the-last-modification-date-of-a-file-in-git-repo

error: src refspec <branchname> соответствует более чем одному
error: не удалось отправить некоторые ссылки в «<репозиторий>»

или

error: src refspec <branchname> matches more than one
error: failed to push some refs to '<repository>'

Гит не может понять, что конкретно я от него хочу. Что именно отправить-то надо. Вероятнее всего, почему-то образовался тег, совпадающий с именем ветки. Можно подробнее указать ветку (refs/heads/<branchname>), можно удалить тег.

Удалить тег:

git tag -d <tag>

Переименовать тег не судьба вообще. :)

Если хочется полно обратиться к тегу, это refs/tags/<tag>.

Полностью команда push - это

git push [options] <repository> <refspec>

, где refspec - это

<source>:<destination>

Обычно это ветки, но могут быть и теги. И теоретически можно завести ещё пространство имён под refs, но я пока понятия не имею, зачем это могло бы быть нужно.

Вместо git push –force лучше делать git push –force-with-lease.

В чем разница? При совместной работе git push –force может просто выкинет чужой коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда как git push –force-with-lease запрещает переписывание ветки, если там есть новые чужие коммиты.

–[no-]force-with-lease, –force-with-lease=<refname>, –force-with-lease=<refname>:<expect>

Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.

This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise.

Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with their commit, and blindly pushing with –force will lose their work.

This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a "lease" on the ref without explicitly locking it, and the remote ref is updated only if the "lease" is still valid.

• –force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
• –force-with-lease=<refname>, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.
• –force-with-lease=<refname>:<expect> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value <expect> (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used). If <expect> is the empty string, then the named ref must not already exist.

Note that all forms other than –force-with-lease=<refname>:<expect> that specifies the expected current value of the ref explicitly are still experimental and their semantics may change as we gain experience with this feature.

• "–no-force-with-lease" will cancel all the previous –force-with-lease on the command line.

A general note on safety: supplying this option without an expected value, i.e. as –force-with-lease or –force-with-lease=<refname> interacts very badly with anything that implicitly runs git fetch on the remote to be pushed to in the background, e.g. git fetch origin on your repository in a cronjob.

The protection it offers over –force is ensuring that subsequent changes your work wasn’t based on aren’t clobbered, but this is trivially defeated if some background process is updating refs in the background. We don’t have anything except the remote tracking info to go by as a heuristic for refs you’re expected to have seen & are willing to clobber.

If your editor or some other system is running git fetch in the background for you a way to mitigate this is to simply set up another remote:

git remote add origin-push $(git config remote.origin.url) git fetch origin-push

Now when the background process runs git fetch origin the references on origin-push won’t be updated, and thus commands like:

git push –force-with-lease origin-push

Will fail unless you manually run git fetch origin-push. This method is of course entirely defeated by something that runs git fetch –all, in that case you’d need to either disable it or do something more tedious like:

git fetch # update 'master' from remote git tag base master # mark our base point git rebase -i master # rewrite some commits git push –force-with-lease=master:base master:master

I.e. create a base tag for versions of the upstream code that you’ve seen and are willing to overwrite, then rewrite history, and finally force push changes to master if the remote version is still at base, regardless of what your local remotes/origin/master has been updated to in the background.

Alternatively, specifying –force-if-includes as an ancillary option along with –force-with-lease[=<refname>] (i.e., without saying what exact commit the ref on the remote side must be pointing at, or which refs on the remote side are being protected) at the time of "push" will verify if updates from the remote-tracking refs that may have been implicitly updated in the background are integrated locally before allowing a forced update.

После клонирования хранилища команды git push или git pull автоматически отправляют и получают его по первоначальному адресу. Потому что настройки, заданные при создании клона.

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

Так что git часто можно использовать почти без аргументов. Но не всегда

Например

git remote add origin git@gitlab.com:agnessa/emacs-config.git

«git@gitlab.com:agnessa/emacs-config.git» - очевидимо, конкретный удалённый реп.

You can choose to provide the name of a remote which you had previously configured using git-remote, git-config or even by a manual edit to the $GIT_DIR/config file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:

[remote "<name>"]
        url = <URL>
        pushurl = <pushurl>
        push = <refspec>
        fetch = <refspec>

The <pushurl> is used for pushes only. It is optional and defaults to <URL>. Pushing to a remote affects all defined pushurls or all defined urls if no pushurls are defined. Fetch, however, will only fetch from the first defined url if multiple urls are defined.

Так вот, если этих пушурлов будет несколько в одном таком remote, то git push remote будет пушить по всем. Если remote – origin, так просто git push будет пушить по всем.

Источник – man git-push. Упоминание, что так бывает – в емаксочатике. :)

Если нужно задать конкретный ключ, это в ~/.ssh/config, потому что этим рулит ssh (об этом же тут: ключ для конкретного сервиса). Или core.sshCommand в .gitconfig.

И дальше как обычно:

git clone ssh:user@host:port/path

Опция --bare делает репозиторий, в котором некуда делать checkout. Поэтому то, что в обычном случае живет в подкаталоге .git, оказывается сразу в основном каталоге. У меня в таком виде живут большинство репозиториев на vps. Потому что они мне нужны для синхронизации с разных устройств, а не для непосредственной работы с файлами.

Это получаются shallow репозитории, типа, «поверхностные, пустые, мелководные, неглубокие». Опций по выбиранию, что надо и не надо, вообще много. Но мне пригождалось только depth.

–depth <depth>

Глубина задана числом коммитов. Мне иногда надо копию актуального состояния + возможность обновлять при изменении, так это оно.

Create a shallow clone with a history truncated to the specified number of commits. Implies –single-branch unless –no-single-branch is given to fetch the histories near the tips of all branches. If you want to clone submodules shallowly, also pass –shallow-submodules.

–shallow-since=<date>

Глубина задана указанием момента. Всё, что после. Именно это мне не было надо, но так-то симпатичное.

Create a shallow clone with a history after the specified time.

Если нужно сколько-то конкретных файлов, можно посмотреть на git archive.

http://vcs-home.branchable.com/ - vcsh - способ хранить в git конфиги домашней папки так, что можно два соседних файла держать в разных репозиториях.

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'
# optionally push your files to a remote
vcsh vim remote add origin <remote>
vcsh vim push -u origin master
# from now on you can push additional commits like this
vcsh vim push

If all that looks a lot like standard git, that's no coincidence; it's a design feature. [2015-03-08 Вс 20:57]

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.

• https://bup.github.io/ [2015-03-03 Вт 09:50], 2022-07-29
• https://github.com/bup/bup. На сейчас (2022-07-29) 0.32.
• http://git-annex.branchable.com/special_remotes/bup/

В целом поняла, что это тема для управления файлами через git и в том числе, когда сами файлы недоступны. Но пока моя голова не есть это мочь :)

• https://git-annex.branchable.com/
• https://git-annex.branchable.com/sync/