Давайте разберемся по пунктам.
Commit
git commit действительно нужен для фиксации изменений.
Давайте подумаем как решить Ваши проблемы:
Хочу откатиться на предыдущие коммиты, последующие все равно остаются, получается бардак.
можно сгладить. Конкретно эту проблему можем решить коммандой git reset.
Выполнение git reset "приводит" состояние репозитория к указанному коммиту, при этом удаляя всех предыдущие коммиты. Например:
У нас есть репозиторий со следующим состоянием:
C1 -- C2 -- C3 -- C4(HEAD).
Мы понимаем, что последние два коммита - полный бред, их нужно удалить, не оставляя их при этом в репозитории. Решение - git reset. После выполнения git reset --hard C2 Получим следующий вид репозитория:
C1 -- C2(HEAD)
При этом мы потеряем все изменения в коммитах C3 & C4.
Если есть часть изменений, которую надо откатить, но сделаны и другие изменения, то эти другие утеряются
Но что если нам нужно их сохранить, но убрать из репозитория? Решение - git reset --soft C2. Получим тот же вид репозитория:
C1 -- C2(HEAD)
Но, при этом у нас останутся наши изменения из C3 & C4 в индексе (в том виде, как будто бы вы их только что добавили командой git add -A)
Есть еще один вариант решения этой проблемы - git revert. Эта команда не удаляет изменения из git repository, а просто создает "отменяющий" коммит - после которого, в Вашем репозитории просто добавиться коммит с изменениями из указанного, в котором Вы можете сделать необходимые изменения. Например после применения комманды git revert C2 репозиторий будет иметь следующий вид:
C1 -- C2 -- C3 -- C4 -- RC2(HEAD)
Вот Вам отличные, на мой взгляд ответы со stackoverflow, объяснующие работу с отменой изменений:
Как вернуться (откатиться) к более раннему коммиту?
Откатить уже опубликованный коммит и опубликовать новый, не вызывая мержа у других
Но для меня не понятно, когда его использовать.
Используйте git commit когда хотите зафиксировать какую-то законченую часть Ваших изменений.
Например, у Вас есть большая задача А, которую Вы можете (желательно) разбить на мелкий подзадачи (сделать декомпозицию задачи). В итоге получите:
A:
--A1
--A2
--A3
----A3.1
----A3.2
--A4
После выполнения каждой подзадачи - делаете commit, фиксируя изменения. В итоге, в случае, если Вы получите какую-то ошибку на определенном этапе - Вам будет легко откатиться на какой-либо этап.
(git commit message convention)
Если большое количество коммитов в разрезе задачи Вас смущает - можете использовать git squash. Тогда после выполнения всей задачи - в основную рабочую ветку будет отправлен один большой коммит.
Branch
Branch, насколько я понимаю, нужен как раз в случае, если есть какие-то изменения, которые надо откатить, и те, которые не надо.
Вариантов использования веток масса, это - только один из них. Ниже я опишу еще один, который много где используют.
Путем манипуляций с ветками я могу создавать нужную комбинацию того, что мне нужно оставить.
Можете, но на мой взгляд - это не самый удачный вариант.
Каковы основные случаи использования branch?
Как я уже говорил выше - вариантов использований веток много. Вот один из них, который принят много где.
Пускай у нас есть репозиторий с ветками:
MASTER: C1 -- C2 -- C3(HEAD)
|
DEVELOP: C1 -- C2 -- C3 -- C4(HEAD)
Каждая новая задача (баг, новый функционал ака фича, не важно) - вы создаете новую ветку (принято делать это от максимально стабильной, рабочей ветки - master) git checkout master; git checkout -b new_feature_branch:
MASTER: C1 -- C2 -- C3(HEAD)
|
DEVELOP: C1 -- C2 -- C3 -- C4(HEAD)
|
NEW FEATURE: C1 -- C2 -- C3 -- FC4 -- FC5(HEAD)
, где FC4-FC5 - коммиты в Вашей новой ветке.
После завершения работы над задачей - делаете pull request в DEVELOP:
MASTER: C1 -- C2 -- C3(HEAD)
|
DEVELOP: C1 -- C2 -- C3 -- C4(HEAD) <---------|
|
NEW FEATURE: C1 -- C2 -- C3 -- FC4 -- FC5(HEAD) --|
на котором тестируете Вашу работу, после чего делаете pull request DEVELOP в MASTER.
MASTER: C1 -- C2 -- C3(HEAD) <---------------|
|
DEVELOP: C1 -- C2 -- C3 -- C4(HEAD) ----------|
|
NEW FEATURE: C1 -- C2 -- C3 -- FC4 -- FC5(HEAD)
Таким образом вы легко можете смотреть на историю изменений Вашего функционала и в случай чего - отменять изменения, сделанные в Вашей "фиче".
Более высокоуровневое решение этой работы - git flow.
Tags
Как в общую концепцию вписываются теги?
Здесь не совсем понятно, что Вы подразумеваете под "общей концепцией", поэтому дать ответ на этот вопрос не смогу.
Какого их основное назначение?
Они используются для фиксации каких-либо важных моментов в истории Вашего репозитория. С другой стороны, их часто используют для версионирования.
Push
У меня все работает, я уверен, что это важная веха - сохраняю на сервер?
Не обязательно.
Когда я должен использовать push?
Зависит от ситуации. Например, если Вы работаете с кем-то и ему понадобились Ваши изменения - git push - он уже у себя сделает git pull и получит Ваш код.
Или Вы работаете на другой машине, например, на работе, но хотите еще поработать позже дома - git push, а дома уже забираете свои изменения и работаете дальше.
Каковы основные случаи использования branch?— это зависит исключительно от того, как у вас организована работа с репозиториями (по-английски workflow). Несколько примеров подобной организации с иллюстрациями приведены в ответе к вопросу «В чём состоит отличие между различными workflow?». – Arhadthedev Sep 03 '18 at 15:21