ebaysher, ты написал git reset --hard HEAD
Это бессмысленная команда перемещения указателя ветки на HEAD, который уже указывает туда же.
Надо сказать на сколько коммитов перемещать назад HEAD~число
Но у тебя коммит единственный и до него нет ничего, поэтому перемещать некуда.
Единственный выход — изменить сам коммит. Фактически удалить и создать на его месте другой.
Просто удалить не получится.
Ну задача так сформулирована, что master нам не нужен.
Забыл написать что придётся попросить коллег удалить у себя мастер и скачать заново исправленный.
Git это и есть система контроля локальных версий. Хранит он всё в сжатом виде и вытаскивает нужное не разжимая всё. Распределённость там бонусом идёт.
Тебя попросили изобрести велосипед?
anna_makeenko, беспризорные коммиты со временем удалятся после сборки мусора. Этот процесс периодически запускается на сервере. Но если нужно срочно, то вот что советуют в справке:
Contact GitHub Support, asking them to remove cached views and references to the sensitive data in pull requests on GitHub.
Вам собственно зачем хочется их удалить? Секретные данные попали в коммиты? ))
alex4answ, ты написал две команды через &, значит обе команды выполняются последовательно в одной ветке. Не вижу тут переключения на другую ветку.
Если ты выполняешь это в мастере, то во первых без разницы в каком режиме работает pull, там в любом случае будет fast-forward. Во вторых, вторых вторая команда становится бессмысленной. Зачем сливать мастер с самим собой?
Если ты в тематической ветке, то первая часть команды бессмысленна, так как ничего не произойдёт. А вторая команда зависит от того, чего ты хочешь увидеть. Можно создать коммит слияния (git merge master --no-fast-forward) чтобы гарантировать последующее сливание тематической ветки в мастер без конфликтов, либо перестроить твою тематическую ветку на вершине мастера (git rebase master). Всё зависит от ваших рабочих процессов в команде. Мне больше нравится второй вариант, так как в первом будет уже сложно переписать твои готовые коммиты.
Если ты работаешь в тематической ветке один, то git pull --rebase вообще бесполезен и ничего не сделает, как и обычный git pull, который 'эквивалентен git fetch & git merge
Но подозреваю, что ты имел в виду замену второй операции git merge master на git rebase master?
Иван Кулаков, есть ситуации когда пароли светить нельзя, но файл с настройками в проекте нужен. Как быть?
Создаём два файла local.properties
local.properties.TEMPLATE
В первом храним наши настоящие пароли, во втором храним заглушку.
Первый файл сразу заносим в .gitignore и он не попадёт в репозиторий.
В коде самого проекта берём пароли из первого файла, а если его нет, то создаём новый на основе *.TEMPLATE
Мы сможем прописать в local.properties наши секретные данные и работать.
А если коллеги клонируют себе проект с GitHub, то они впишут туда свои данные локально.
Получим что файл с паролями есть, но сами пароли не светятся в репозитории.
DevMan, но нам нужно чтобы файла не было в локальной копии.
Править .gitignore бесполезно после того, как файл уже отслеживается. git rm --cached readme.md не удалит файл из локальной рабочей копии.
Какой смысл тогда?
А если удалить файл руками, то git status всё равно это увидит и попросит закоммитить, не смотря на наличие файла в .gitignore
Потом мы отправим наши правки на GitHub и readme.md удалится и оттуда с главной страницы.
Поэтому я говорю, что сработает только метод с отдельной веткой, в котором файл удалён.
Хотя конечно до сих пор не ясно зачем человеку понадобилось удалять файл.
На самом деле Git не так сложен как о нём говорят, а подружиться помогут сотни статей для начинающих и не только. В том числе тут на Хабре есть хорошие материалы. А вот тот же Mercurial мне показался сложнее в понимании.
Ещё много обучающих роликов на Ютубе.
Советую вот этот плейлист https://www.youtube.com/watch?v=rJTQzEQcdk4&list=P...
Довольно наглядно.
то там вообще нет такого файла или папки. Удали всё руками просто в проводнике.
И потом коммит.
Ты точно уверен что надо удалить коммит? Вариант с исправлением кода на нужный не подходит?