при следующем добавлении 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могу я впихнуть например коммит D между коммитами А и B? чтобы получилось так:
git rebase. Сложность впихивания напрямую зависит от того, насколько много общих строчек изменяют D, B и C. Если они полностью независимы, git rebase сделает всё сам, если нет -- прийдётся разрешать конфликты.
если сравнить commit прилетевшим с удаленного репозитория с этим новым commit, то отличий между ними нет.
o--A
`--Bo--A--B--M1--E
\ / \
-C----D---M2--Fo--A--B
`--Bo--A--M1
/
...-B----C