PayPal конечно гнилая контора. В любой момент могут отобрать твои деньги заявив что ты какой-то подозрительный.
Но сейчас сайт работает. Попробуй почистить куки и кеш. Либо зайди с другого компьютера.
Николай Угольников, а зачем тебе делать Pull Request? Ты понимаешь что вообще это такое?
Обычно это предложение правок из своего форка в основной проект, куда у тебя нет прав на запись.
А ты откуда и куда хочешь отправить изменения? Дай хоть ссылку на репозиторий.
Ivan Bogachev, мне как раз режет глаз смешение стилей, когда автоматические сообщения в императиве, а остальные в прошедшем времени. Уж лучше когда единообразно. Так и лаконичней получается и грамотнее. Тем более редко когда коммиты идут сразу в мастер, они почти всегда что-то предлагают изменить, а не констатируют что уже изменено в проекте.
Автоматические сообщения даже локализации не поддаются, и уж тем более невозможно поменять их грамматику. Или есть способ поправить шаблоны?
Ответ на вопрос уже есть в сообщении, которое ты процитировал.
branch tip is behind its remote
Твоя ветка, которую ты пыташься отправить, отстаёт от связанной вышестоящей ветки. Проще говоря, в ветке на гитхабе есть коммиты, которых пока нет у тебя в локальной копии ветки.
Далее по тексту тебе намекают как решить проблему. Следует сначала загрузить обновления с внешней ветки и влить их в твою ветку. Например через git pull Только после этого push сможет корректно отправить твои коммиты.
Но если расхождение веток возникло по другой причине, например ты делал rebase локально, тогда тебе конечно не нужно сохранять коммиты на гитхабе, а нужно заменить их своей новой веткой просто указав дополнительный параметр команды push --force
Лучше использовать неопределённую форму глаголов, по аналогии с англоязычными примерами. Добавить, исправить, удалить…
В сообщениях Git-коммитов предпочтительней повелительное наклонение. Даже стандартные сообщения коммитов слияния начинаются со слова merge (слить), а не merged (слито)
Павел, если не получится, то настрой по-старинке — через SSH. Там правда придётся ключи создать и закинуть в профиль на гитхабе. Зато работает из коробки и внешнее хранилище паролей уже не требуется.
Самый простой способ обновления:
git pull --rebase
Ваш коммит с изменённым файлом будет вставать каждый раз поверх обновлённого main.
В случае конфликта — разрешаете его и потом
git add ваш файл
git rebase --continue
Никакие дополнительные ветки не нужны.
Это если вы ничего не утаили в вопросе.
С форком например, а не клоном, последовательность операций слегка другая.
Павел, уже посмотрел какой хелпер дома выставлен по умолчанию?
А вообще лучше сразу в графическом клиенте работать, например SmartGit.
Там проблем с авторизацией точно не будет.
Копай в сторону credential helper. Какой сейчас настроен дома? Какой был выбран при установке?
Команда git config credential.helper выведет текущую настройку. Сравни с тем что на работе.
Имени нет, но схема рабочая.
Тогда твой алгоритм правильный. Возможно есть слегка непонимание того, что именно происходит. Рекомендую пройтись по плейлисту по ссылке на ютубе. Особенно про ветки.
Не бойся коммитить в свою ветку, ничего страшного не произойдёт. Ты же всегда потом сможешь причесать коммиты перед слиянием в мастер и отправкой наверх.
Перебазировать свою тематическую ветку на актуальный мастер это тоже нормальная практика. Сам так делаю.
И ты не обязан работать в одной ветке. Можешь отпочковать себе хоть сколько веток под эксперименты с кодом.
3. git checkout -b fast
(Создаю fast. Именно так надо, с '-b'?)
Ты объединил две операции в одну, поэтому тут важен ключ указывающий что ветку нужно ещё и создать перед переключением на неё.
по факту твоя команда делает две вещи
git branch fast — создать
git checkout fast — переключиться
без предварительного создания (или без -b) некуда будет переключиться.
Но сейчас сайт работает. Попробуй почистить куки и кеш. Либо зайди с другого компьютера.