при следующем добавлении git add client (когда уже на другую ветку переключился) ничего не происходит
Он находит физическую копию или же у него есть инструкция, по которой он возвращает файл в нужное состояние с нужным содержимым при помощи хэша?
простое хранилище ключ-значение
. Подробности: раз, два. Является ли нормальной практикой для девелопера создать ветку feature1 от не последнего коммита мастера, то бишь не от "g"
и потом смерджить feature1 с коммитом X2 затирая изменения f и g?
git merge --strategy=ours
-- в результате мёржа изменения сделанные в ветке которая мёржится будут потеряны. Попробовал git rebase -i HEAD~5
но если в открывшемся списке напротив "коммит 4" ставлю флаг "s"
то у меня объединяются почему-то "фикс 4-го коммита" и "коммит 1"
squash
объединяет коммит на котором он стоит с предыдущим в этом списке. git worktree
внутри нет истории, только текстовая ссылка на каталог .git. Поэтому если всю эту конструкцию скопировать в другое место файловой системы и попытаться использовать там, то могут быть неожиданные эффекты, поскольку worktree будет ссылаться по абсолютному пути на оригинал, а не на копию. GIT_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).
Ок. Возник конфликт. Но почему?
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'"
Мне бы каким-то магическим образом вычислить все изменения, которые нужно сделать в ветке 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
могу я впихнуть например коммит D между коммитами А и B? чтобы получилось так:
git rebase
. Сложность впихивания напрямую зависит от того, насколько много общих строчек изменяют D, B и C. Если они полностью независимы, git rebase
сделает всё сам, если нет -- прийдётся разрешать конфликты. если сравнить commit прилетевшим с удаленного репозитория с этим новым commit, то отличий между ними нет.
o--A
`--B
o--A--B--M1--E
\ / \
-C----D---M2--F
o--A--B
`--B
o--A--M1
/
...-B----C