На самом деле так делать не надо. Особенно если предполагается, что над проектом будет работать более одного человека.
Просто не надо пушить туда треш, а amend, rebase и прочее стоит делать только пока оно не улетело в публичную репу.
После force push все, кто успел выкачать ветку с тем «фантомным» коммитом (он, кстати, из репозитория просто так никуда не денется) продолжат свою историю именно от него, а не от твоей forced push ветки. И опять будет слияние этих двух веток, «неправильной» и «правильной».

--==SS==--, Да я-то понял это. Я про случай, когда я один на один со своим репозиторием.

В целом, я уже понял что надо очень жёстко следить за тем, что у тебя есть, перед тем как пушить.

Ryuzaki_rnd, как-то так, да. Свою историю переписывать можно, но только пока она не стала достоянием общественности через git push.

Кстати, rejected будет и если там просто были чужие коммиты. Но это решается слиянием. В простейшем случае оно произойдёт автоматически при git pull (который по факту git fetch + git merge). Хотя некоторым (например, мне) нравится делать rebase своих коммитов поверх, чтобы история оставалась линейной. В этом есть некоторые подводные камни, но в целом вполне ок.

--==SS==--, git pull (который по факту git fetch + git merge)

Ну, в мануалах пишут, что всё же есть различия. И что лучше использовать fetch + merge, чем pull.)
Лично по своему опыту - мне pull не нравится тем, что делает дикую кашу из веток и т.д.
С другой стороны, с моим перфекционизмом и страстью "вылизывать" код, у меня коммит ~ релиз.))) Может не по всему проекту, но хотя бы по модулям.
И получается, что вместо того как оно должно быть с гитом, у меня один коммит = один маленький релиз.
Ибо, опять же, мне дико не нравится макароны из веток.))) Хотя я и понимаю почему оно является нормальным и естественным.
В итоге получается линейная структура.) Ну и тестовый реп, куда изначально заливаю, чтобы посмотреть, проверить всё - вдруг очепятался где-то.
А когда уже всё точно нормально - тогда и в основной запушить можно.)


чтобы история оставалась линейной

Ну вот да, без макарон наглядней и удобней ориентироваться.)

Ryuzaki_rnd,
лучше использовать fetch + merge, чем pull.)
Нет. git pull это git fetch + git merge FETCH_HEAD. Об этом прямо сказано в мане. Флаги тоже поддерживаются. А --rebase превращает его соответственно в git fetch + git rebase FETCH_HEAD. И это всё можно настроить поведением по умолчанию через конфиг.

pull не нравится тем, что делает дикую кашу из веток и т.д.
Поскольку pull всёго-лишь шорткат, то, видимо, речь о том, как по умолчанию ведёт себя git merge. Ну, при работе с ветками от отдельного коммита с merge'м всё равно не удастся избавиться. А для работы в одной ветке можно прописать себе, например, git config branch.autosetuprebase always. И спокойно пуллить одной командой.

тестовый реп, куда изначально заливаю, чтобы посмотреть, проверить всё
А чем локальный репозиторий не устроил? Мне кажется, надо просто привыкнуть, что git это не CVS или SVN и здесь не надо бояться делать коммит, создавать ветки и т.д. Бояться надо только пушить. git log, git show, git diff — в помощь. Впрочем, мне это обычно удобнее в IDE делать.

без макарон наглядней и удобней ориентироваться.
И всё же это зависит от, скажем так, рабочего процесса. Кто-то даже на небольших проектах фигачит по git flow.

А чем локальный репозиторий не устроил?

Ну, вот пример - очепятался я в комментарии. Заметил это только когда на гитхабе перечитал всё.
Тут либо внести правки и запушить снова, либо через --amend и форсированный пуш.
И то и другое добавит лишний коммит. И, что важнее, первый коммит перепишется только при форсированном пуше (тут мы получим фантомный коммит в счётчике коммитов). А при "втором" коммите, описание на гитхабе будет как в первом было. Не знаю почему гитхаб так работает, но вот так.

То бишь, мне важно как оно выглядит. Так что залил - посмотрел, если ок всё и я нигде не очепятался и с файлом всё в порядке, то можно пушить в основной.

С файлом, кстати, на забавный момент нарвался - если конец файла на последней строке и она не пустая (допустим, закрывающая скобка стоит и после неё конец файла), то в листинге на гитхабе это будет стрёмной красной пометкой отображаться. Почему-то ему важно, чтобы конец файла был на отдельной строке в гордом одиночестве. Если так - то листинг весь зелёненький и опрятный.)))

В общем, тут чисто мои визуально-стилистические заморочки.
Если совсем в крайности податься, то банально переносы строк в комментарии поправить бывает можно, для лучшей читабельности.

Просто на локали я ж вижу максимум в редакторе, как оно и чего (про консоль вообще молчу), а на гитхабе я уже вижу как оно "в деле" выглядит.
Потому и заморочка с тестовым репом. Ну и в целом, читать там удобнее, чем в консоли/редакторе.

Это что ж за консоль и редактор такие, что просмотрщик на гитхабе удобнее?
Ещё, кстати, есть gitk.

Почему-то ему важно, чтобы конец файла был на отдельной строке в гордом одиночестве
Это связано с разным подходом к тому, что такое строка и конец строки.
Первый подход заключается в том, что есть специальный символ, разделяющий строки.
Второй подход предполагает, что строка это что-то, что заканчивается символом конца строки.
В *nix традиционно принят второй подход. Поэтому, например, если сделать cat файла, в конце которого нет \n, то приглашение командной строки появится на той же строчке, где закончился вывод файла, а не на следующей, как это было бы, например, в Windows с командой type.
По этой же причине требование заканчивать файл концом строки можно встретить в различных кодинг-стандартах.

И, что важнее, первый коммит перепишется только при форсированном пуше
Вообще в любом случае переписать историю в удалённой репе можно только через forced push. Никаких других вариантов.

тут мы получим фантомный коммит в счётчике коммитов
Откровенно говоря, он не такой уж фантомный и останется в репозитории. И в локальном и в удалённом. Зная его хеш его всегда можно вытащить. По крайней мере, пока не отработает сборщик мусора и только если на этот момент он не будет снова связан с историей какой-либо ветки (или тега).

--==SS==--, Откровенно говоря, он не такой уж фантомный и останется в репозитории. И в локальном и в удалённом.

Эм... видимо я чего-то не понимаю.
1) Делаю пуш.
2) Через --amend правлю коммит.
3) Через log всё также виже 1 коммит.
4) Форсированно пушу.
5) На гитхабе вижу "2 commits", но если ткнуть по этой фразе, то в списке коммитов вижу только один. + Приписочка сверху о форсированном пуше.


Это связано с разным подходом к тому, что такое строка и конец строки.

А, ок. С этим ясно.


Это что ж за консоль и редактор такие, что просмотрщик на гитхабе удобнее?

Ну... консолька - стандартная, которая с гитом идёт, git-bash.exe.
Редактор edit plus, он мне удобней для работы - много чего настраивается под себя, в том числе и автозавершения.

Я про то, что многострочный комментарий в консоли просто несимпатично выглядит.

С редактором иначе - у меня выставлен шрифт и размер с которыми мне удобно работать длительное время.
Но в плане "почитать" удобнее то, что на гитхабе - компактней там всё.)