jcmvbkbc

могу я впихнуть например коммит 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

Ни одна ветка не является потомком другой: С растёт из B, а не из M1, M1 растёт из B а не из C. Поэтому в будущем опять потребуется мёрж при объединении в любую сторону.

git init
git add .
git commit
git remote add <remote-name> <url>
git fetch <remote-name>
git diff <remote-name>/<remote-branch>

git rebase -i <идентификатор коммита>

комментарий к коммиту 1 я считаю неправильно информативным и хочу его переименовать.

-- отметить коммит как r (reword) в списке rebase.

как удалить коммиты 3 и 4, чтобы они изчезли в том числе из "git log --all", у меня по сути было 3 изменения в проекте, коммиты с 3 по 5 по сути являются шагами одного изменения и хранить в истории коммиты 3 и 4 никакой надобности нет.

Это не "удалить", это "объединить с другими коммитами".
-- отметить все идущие подряд коммиты которые надо объединить, кроме первого, как s (squash) в списке rebase.

Как скопировать файлы его ветки HW09 в свою HW09 так, чтобы master и другие ветки не были затронуты?

Если в локальном репозитории есть ветка HW09, то так:

git fetch <URL чужого репозитория> HW09
git checkout HW09
git reset --hard FETCH_HEAD

если нет, то так:

git fetch <URL чужого репозитория> HW09
git checkout -b HW09 FETCH_HEAD

что делает команда git pull --rebase?

Делает pull, а потом делает rebase локальной истории на то что было получено через pull.
Т.е. если в удалённом репозитории было
A--B--C
в локальном репозитории к этому было добавлено
A--B--C--d--e
а в удалённом
A--B--C--D--E
то после git pull --rebase локальная история станет такой:
A--B--C--D--E--d'--e'
где d' и e' -- это перебазированные поверх E локальные d и e.

git rebase -i --root если нужно внести изменения в первый коммит.

Можно ли не копировать на флэшку весь проект, чтобы перенести его из дома на работу, а просто скопировать папку .git?

Можно, если все нужные файлы закоммичены.
Скопируешь .git в нужное место и напишешь git reset --hard чтобы восстановить рабочий каталог.

Для начала -- добавить remote в репозиторий на другом компе:
git remote add <имя remote> <URL>
Если история на github совпадает с локальной историей, просто короче, то можно сразу пушить:
git push <имя remote> <имя ветки>
Если нет -- надо выкачивать и мёржить:

git fetch <имя remote> <имя ветки>
git merge <имя remote>/<имя ветки>
<магия разрешения конфликтов>

после чего можно пушить обратно.

Подскажите пожалуйста, где git хранит логин и пароль от данного url клонирования?

Так прямо в remote и хранит. Набери git remote -v и полюбуйся. Или загляни в .git/config.

Вот он же тебе пишет возможный вариант решения:

You can set the 'receive.denyCurrentBranch' configuration variable
to 'ignore' or 'warn' in the remote repository to allow pushing into
its current branch

Зайди на свой удалённый сервер и в этот репозиторий в .git/config добавь

[receive]
denyCurrentBranch = ignore

А если соберёшься работать с вычекнутой веткой на удалённом сервере -- не забудь сделать git reset --hard перед началом, чтобы синхронизировать рабочий каталог.

Есть ветка и три коммита в ней AAA-BBB-CCC...
Далее были сделаны правки, но их надо применить к коммиту BBB

git commit -a -m fixes
git rebase -i AAA

перенести fixes после BBB, заменить pick перед fixes на fix.

Всё то же самое, но автоматически:

git commit -a --fixup BBB
git rebase --autosquash AAA

Обычно в хорошем описании можно выделить две части. Одна описывает зачем это изменение нужно: в чём была проблема/чего не хватало/что работало не так. Вторая описывает решение и документирует, почему именно это решение было выбрано.
И это правило работает в обе стороны: если невозможно описать зачем было сделано изменение или почему оно именно такое -- это скорее всего плохое изменение.

1 вариант: Добавляет элемент block__element3 блоку block;
2 вариант: Добавляет текст с описанием блоку block;

Оба в равной мере бесполезны, как и сам этот коммит, судя по всему.

Есть ли возможность узнать информацию по ветке на удалённом сервере без fetch?

Ограниченная. См. git ls-remote.

как из консоли узнать имя последнего коммита в ветке на сервере?

Можно узнать хеш:

$ git ls-remote origin refs/heads/master
2595646791c319cadfdbf271563aac97d0843dc7        refs/heads/master

есть 2 ветки dev и feature-3. я слил ветку dev с feature-3 и запушил dev ветку на remote.
Можно ли ветку feature-3?

Если первая половина выглядела так:

$ git checkout dev
$ git merge --no-ff feature-3
$ git push remote HEAD

либо git merge feature-3 на втором шаге, и мёрж при этом не был фаст-форвардом, то вторую половину можно сделать так:

$ git checkout dev
$ git pull remote dev
$ git checkout HEAD^2 -b feature-3

Идея в том, что <id-мёржа>^<N> -- это голова ветки № N участвовавшей в этом мёрже.

Если мёрж был фаст-форвардом, то dev и feature-3 -- это одно и то же.