git rebase --onto <куда> <начало ветки> <конец ветки>First let’s assume your topic is based on branch next.
For example, a feature developed in topic depends on some functionality
which is found in next.
o---o---o---o---o master
\
o---o---o---o---o next
\
o---o---o topic
We want to make topic forked from branch master;
for example, because the functionality on which topic depends
was merged into the more stable master branch.
We want our tree to look like this:
o---o---o---o---o master
| \
| o'--o'--o' topic
\
o---o---o---o---o next
We can get this using the following command:
git rebase --onto master next topic
git fetch origin - получить все веткиgit fetch origin other_branch_name - или получить только ветку other_branch_namegit checkout other_branch_name - переключиться на ветку other_branch_name 
git config core.hooksPath .githooks
Он находит физическую копию или же у него есть инструкция, по которой он возвращает файл в нужное состояние с нужным содержимым при помощи хэша?
простое хранилище ключ-значение. Подробности: раз, два.
Является ли нормальной практикой для девелопера создать ветку feature1 от не последнего коммита мастера, то бишь не от "g"
и потом смерджить feature1 с коммитом X2 затирая изменения f и g?
git merge --strategy=ours -- в результате мёржа изменения сделанные в ветке которая мёржится будут потеряны.