В svn было довольно удобно ориентироваться на последовательные номера редакций.
git describe, в котором присутствует ближайшая метка (или выбранная метка, если делать git describe --match 'mask'), количество коммитов после этой метки и хеш последнего коммита. Например, в одном и том же дереве linux я вижу:$ git describe
xtensa-6.8-rc2-esp32-spi-8-gb25ff15921c2
$ git describe --match 'v*'
v6.8-rc2-52-gb25ff15921c2
$ git describe --match 'v?.?'
v6.7-13495-gb25ff15921c2git worktree remove C:/Projects/web_test), после чего повтори команду удаления ветки.
при следующем добавлении git add client (когда уже на другую ветку переключился) ничего не происходит
Он находит физическую копию или же у него есть инструкция, по которой он возвращает файл в нужное состояние с нужным содержимым при помощи хэша?
простое хранилище ключ-значение. Подробности: раз, два.
Является ли нормальной практикой для девелопера создать ветку feature1 от не последнего коммита мастера, то бишь не от "g"
и потом смерджить feature1 с коммитом X2 затирая изменения f и g?
git merge --strategy=ours -- в результате мёржа изменения сделанные в ветке которая мёржится будут потеряны.
изменения в файле "C" нужно вернуть к изначальному состоянию
Как это сделать?
git checkout HEAD~1 "C"git commit или git commit --amend, в зависимости от того, нужно ли закоммитить отмену изменений С отдельно или убрать изменения С из предыдущего коммита.
Попробовал git rebase -i HEAD~5
но если в открывшемся списке напротив "коммит 4" ставлю флаг "s"
то у меня объединяются почему-то "фикс 4-го коммита" и "коммит 1"
squash объединяет коммит на котором он стоит с предыдущим в этом списке.
git worktree внутри нет истории, только текстовая ссылка на каталог .git. Поэтому если всю эту конструкцию скопировать в другое место файловой системы и попытаться использовать там, то могут быть неожиданные эффекты, поскольку worktree будет ссылаться по абсолютному пути на оригинал, а не на копию.
git revert умеет работать с диапазонами версий и продолжать/отменять процесс в случае конфликтов.
git remote add new <url_new_repo>
git push new +masterGIT_EDITOR
This environment variable overrides $EDITOR and $VISUAL.
It is used by several Git commands when, on interactive mode,
an editor is to be launched.
See also git-var(1) and the core.editor option in git-config(1).You have unstaged changes.
или есть команда специальная в гите?
git commit называется.
Ок. Возник конфликт. Но почему?
1. Это я неправильно понимаю как должна работать эта команда или здесь что-то пошло не так?
3. Если cherry-pick работает также как merge, то может лучше тогда делать для копирования squash?
Прошу помочь с оптимизацией данного скрипта.
#!/bin/bash
fille="$1"
cmd=
while read -r line; do
source=$(echo "$line" | awk 'BEGIN { FS = "," } { print $1} ');
target=$(echo "$line" | awk 'BEGIN { FS = "," } { print $2} ');
cmd="${cmd}s,$source,$target,g;"
done < "$file"
git filter-branch -f --msg-filter "sed -e '$cmd'"git rebase --skip. Если это не так, надо разбираться что именно произошло.
Мне бы каким-то магическим образом вычислить все изменения, которые нужно сделать в ветке 2, чтобы получить ровно такое же состояние, какое сейчас в ветке 1. И сделать новый коммит в ветку 2, чтобы получить состояние как в ветке 1.
$ git checkout branch2 # перейти к ветке branch2
$ git reset --hard branch1 # скопировать в неё историю и текущее состояние ветки branch1
$ git reset --soft HEAD@{1} # восстановить историю ветки branch2, но не трогать текущее состояние
$ git commit -m 'magic commit' # закоммитить текущее состояние (равное разности branch2 -> branch1) в branch2