Error failed to push some refs to перевод

в Git ошибка: не удалось подтолкнуть некоторые ссылки на | Codengineering - это блог о программировании со множеством ответов и решений самых разных проблем


по какой-то причине, я не могу нажать сейчас, в то время как я мог бы сделать это вчера.
Может быть, я перепутал с конфигурациями или что-то в этом роде.

вот что происходит:

когда я использую git push origin master

gitbashscr

Как выглядит мой рабочий каталог и удаленный репозиторий:

enter image description here


3575  


17  

17 ответов:

если репозиторий GitHub видел новые коммиты, которые были нажаты на него, пока вы работали локально, я бы посоветовал использовать:

git pull --rebase
git push

полный синтаксис:

git pull --rebase origin master
git push origin master

таким образом, вы бы переиграть (--rebase часть) ваши локальные коммиты поверх вновь обновляется!—6—> (или origin/yourBranch:git pull origin yourBranch).

посмотреть более полный пример в Глава 6 потяните с rebase на Git Pocket Book.

я бы рекомендую:

git push -u origin master

это установит связь отслеживания между вашей локальной главной ветвью и ее восходящей ветвью.
После этого любой будущий толчок для этой ветви можно сделать с помощью простого:

git push

в разделе «зачем мне нужно явно нажимать новую ветку?».


так как ОП уже сбросить и переделать его фиксацию на origin/master:

git reset --mixed origin/master
git add .
git commit -m "This is a new commit for what I originally planned to be amended"
git push origin master

нет необходимости pull --rebase.

Примечание: git reset --mixed origin/master также может быть написано git reset origin/master С --mixed опция по умолчанию при использовании git reset.

кто-нибудь попробовать:

git push -f origin master

Это должно решить проблему.

EDIT: на основе комментария @Mehdi ниже мне нужно уточнить кое-что о —force pushing. Команда git выше работает безопасно только для первой фиксации. Если ранее уже были коммиты, запросы на вытягивание или ветви, это сбрасывает все это и устанавливает его с нуля. Если это так, обратитесь к подробному ответу @VonC для лучшего решения.

Если вы только что использовали git init и добавили свои файлы с git add . или что-то подобное и добавили вашу удаленную ветку может быть, что вы просто не совершили (git commit -m 'commit message') что-нибудь локально нажать на пульт… У меня просто была эта ошибка, и это была моя проблема.

У меня была такая же проблема. Я получал эту проблему, потому что я не сделал никакого коммита, даже начального коммита, и все же я пытался нажать.

Как только я сделал git commit -m "your msg" и тогда все работало нормально.

Я нахожу решение этой проблемы в справке github.

вы можете увидеть его из: работа с ошибками без быстрой перемотки вперед

Он говорит:

вы можете исправить это путем извлечения и объединения изменений, внесенных в удаленной ветви с изменениями, которые вы сделали локально:

$ git fetch origin
# Fetches updates made to an online repository
$ git merge origin branch
# Merges updates made online with your local work

или вы можете просто использовать git pull для выполнения обеих команд сразу:

$ git pull origin branch
# Grabs online updates and merges them with your local work

Если вы используете gerrit, это может быть вызвано неправильным изменением-id в фиксации. Попробуйте удалить Change-Id и посмотреть, что произойдет.

переименуйте свою ветку, а затем нажмите, например:

git branch -m new-name
git push -u new-name

это сработало для меня.

Не забудьте зафиксировать свои изменения, прежде чем нажимать на репо Github. Это может решить вашу проблему.

перед нажатием вы должны добавить и зафиксировать изменения или сделать git push -f origin master

Не фиксация начальных изменений перед нажатием также вызывает проблему

Не уверен, что это применимо, но исправление для меня состояло в том, чтобы совершить что-то локально после git init. Затем я перешел к удаленному использованию —set-upstream …

1) git init

2) git remote add origin https://gitlab.com/crew-chief-systems/bot

3) git remote-v (для проверки текущего репозитория)

4) git add-A (добавить все файлы)

5) git commit-m ‘Added my project’

6) git pull —rebase origin master

7) git push origin master

Ну, если ни один из вышеперечисленных ответов не работает, и если вы что-то перепутали с ssh-add в последнее время. Попробуй

ssh-add -D

в моем случае эта ошибка произошла из-за того, что в нашей версии GitLab происходило некоторое обслуживание.

вы также можете исправить это, отредактировав файл конфигурации git вашего проекта:

где это?

.git / config

добавьте следующие строки в конце, если это не так.

[branch "master"]
remote = origin
merge = refs/heads/master

проблема

в моем случае закрытие редактора (visual studio code) решило проблему.

ошибка git: не удалось нажать некоторые ссылки также приходит, когда имя локального репозитория совпадает с соответствующим именем удаленного репозитория. Убедитесь, что вы работаете над правильной парой репозиториев, прежде чем извлекать изменения в удаленный репозиторий. Если вы пишете неправильно и хотите удалить локальный репозиторий, выполните следующие действия

удаление локального РЕПО из windows
1. del /F /S /Q / A .мерзавец
2. команда rmdir. мерзавец
3. Исправьте имя локальной папки (XXXX02 — >XXXX20) или если оно это вновь созданный РЕПО удалить его и воссоздать РЕПО (XXXX02 имя РЕПО изменилось на XXXX20).
4. git init
5. Повторное сопоставление с удаленным РЕПО, если оно не сопоставлено.
6. git remote add origin https://github.com/ / XXXX20.git
7. git push — U origin master

В предыдущей статье мы прошли базовые команды Git, которые применяются в повседневной работе. В этой публикации продолжим изучение данного инструмента, рассмотрев типичные ошибки при его использовании, а также способы их исправления.

Данная статья не ставит перед собой цель быть энциклопедией решений на все случаи жизни. Было бы неверным давать ответы на вопросы, которые на данном этапе изучения Git просто не могут возникнуть. Любая информация должна соответствовать вашему текущему уровню.

1. Самое простое решение многих проблем

Вы «натворили делов» со своим репозиторием, и вам кажется, что все сломалось и ничего не работает. В качестве максимально быстрого решения этой проблемы можно удалить локальный репозиторий (скрытую папку .git в корне вашего проекта) и репозиторий на GitHub, а затем выполнить git init. При этом ваши файлы удалять не нужно.

Когда я изучал Git, то десятки раз создавал и удалял свои репозитории, сталкиваясь с неразрешимыми для меня на тот момент проблемами.

Этот вариант имеет право на существование для начинающих разработчиков, т. к. они не обладают еще нужным набором знаний для применения более технологичных решений. Но, как вы понимаете, данный способ хорош до поры до времени.

2. Как изменить URL удаленного репозитория?

Вы неверно назвали свой репозиторий, например, вместо StartJava почему-то написали Lesson1 или JavaOps. На что наставник вам сказал, что его нужно переименовать.

Или вы удалили свой репозиторий на GitHub, а у себя на компьютере — оставили. После этого создали новый удаленный репозиторий (УР), изменив его первоначальное имя.

Например, URL репозитория выглядел так:


https://github.com/ichimax/lesson1.git

А после изменений ссылка стала следующей:


https://github.com/ichimax/startjava.git

При этом в настройках локального репозитория (ЛР) адрес старого репозитория никуда не делся — его нужно обновить.

Свяжем ЛР с новым адресом УР:


> git remote set-url origin новый_url.git
> git remote -v

Когда вам в дальнейшем потребуется выполнить push, то необходимо будет написать полную версию команды git push -u origin master, чтобы заново связать ЛР с новым УР, а затем снова можете использовать сокращенный вариант.

3. Как удалить файл из репозитория?

3.1. Удаление файла из индекса

Представим, что вы забыли занести в .gitignore правило, которое позволяло бы игнорировать class-файлы. В итоге применив команду git add, добавили их случайно в индекс.

Это очень частая ошибка у начинающих, которая влечет за собой попадание мусорных файлов в УР.

Скомпилируем исходник, создав class-файл:

Внесем изменения в класс из предыдущих статей:


import java.util.Scanner;

public class MyFirstApp {
    public static void main(String[] args) {
        System.out.println("У какого языка программирования следующий слоган:");
        System.out.print(""Написано однажды, ");
        System.out.println("работает везде!"");

        String answer = new Scanner(System.in).next();
        if (answer.equalsIgnoreCase("Java")) {
            System.out.println("Вы угадали");
        } else System.out.println("Увы, но - это Java");
    }
}

Далее введем привычные команды:


> git add . && git status
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   MyFirstApp.class
        modified:   MyFirstApp.java

MyFirstApp.class в итоге попал в индекс Git. Необходимо его оттуда удалить, т. к. отслеживание изменений у данного вида файлов не несет никакой практической пользы.

Воспользуемся командой, подсказанной Git:


> git restore --staged MyFirstApp.class && git status
Changes to be committed:
        modified:   MyFirstApp.java

Untracked files:
        MyFirstApp.class

MyFirstApp.class снова стал неотслеживаемым, а измененный класс остался в индексе не тронутым.

Чтобы обезопасить себя, перед использованием команды git add, всегда нужно просматривать список файлов (git status), которые вы планируете добавить в индекс. Также обязательно добавьте шаблон *.class в .gitignore, чтобы больше не спотыкаться о class-файлы.

3.2. Удаление файла из коммита

Пойдем дальше и научимся удалять MyFirstApp.class из коммита.


> git status

Changes to be committed:
        new file:   MyFirstApp.class
        modified:   MyFirstApp.java

Добавим все изменения в коммит:


> git commit -m "Добавил quiz по слогану Java"

Перед тем, как запушить коммит, программист решил посмотреть, какие файлы в него входят:


> git log -1 --name-only --oneline
ead5167 (HEAD -> master) Добавил quiz по слогану Java
src/MyFirstApp.class
src/MyFirstApp.java

С командной git log мы уже сталкивались в предыдущей статье. Из нового — аргумент —name-only, который позволяет вывести только имена измененных файлов, находящихся в коммите.

Использование log позволило заметить, что MyFirstApp.class оказался в коммите. Его нужно оттуда убрать.


> git reset --soft HEAD~1

Разберем эту команду по частям:

  • reset — отменяет коммиты
  • —soft — позволяет выполнить отмену коммита без потери изменений
  • HEAD — указатель на локальную ветку в которой мы находимся. В нашем случае HEAD~1 указывает на первый коммит в дереве коммитов ветки master

Более подробно про команду reset (1, 2).

Тут следует сказать, что HEAD указывает на ветку, в которой вы находитесь в данный момент. Благодаря ему мы можем перемещаться по дереву коммитов и откатываться к любому из них.

Получается следующая картина: HEAD указывает на ветку master, а master является указателем на вершину в дереве коммитов.

Отобразим, куда указывает HEAD:

* обозначается текущая ветка.

Если команду ввести с параметром -v, то кроме названия ветки отобразится информация о коммите, на который указывает master:


> git branch -v
* master b59d871 Изменил вывод текста, отображаемого в консоль

После отмены коммита отобразим список оставшихся коммитов:


> git log --oneline
b59d871 (HEAD -> master, origin/master) Изменил вывод текста, отображаемого в консоль
39ba195 Переименовал about.txt в README.md и внес в него описание проекта
1e36e0f Инициализация проекта

Видим, что благодаря reset последний коммит из него был исключен.

При этом log отображает ту же самую информацию, о которой мы говорили выше: HEAD указывает на master, а он — на вершину дерева коммитов (коммит b59d871).

Стоит отметить, что команду reset необходимо использовать только для отмены коммитов, которые находятся исключительно на вашем компьютере и еще не попали на УР. Т. к. эта команда меняет историю коммитов, то это может принести множество проблем для других людей, которые совместно с вами работают в одном репозитории, если вы отмените с ее помощью коммит, а затем запушите изменения на УР.

Посмотрим, в каком состоянии теперь находится ЛР:


> git status
Changes to be committed:
        new file:   MyFirstApp.class
        modified:   MyFirstApp.java

Что делать дальше, вы уже знаете: нужно убрать из индекса class-файл, и закоммитить java-класс.

Исключаем MyFirstApp.class:


> git restore --staged MyFirstApp.class
> git status
Changes to be committed:
        modified:   MyFirstApp.java

Untracked files:
        MyFirstApp.class

И тут вы понимаете, что забыли, как у вас назывался отмененный коммит: изменения остались все те же, значит, придумывать описание к коммиту нет смысла — нужно воспользоваться тем, которое было раньше.

Есть одна волшебная команда git reflog, которая отобразит все, что вы когда-либо сделали в своем репозитории с коммитами. Это своего рода лог всех ваших операций. Приведу его малую часть, которая нам необходима:


> git reflog
b59d871 (HEAD -> master, origin/master) HEAD@{0}: reset: moving to HEAD~1
ead5167 HEAD@{1}: commit: Добавил quiz по слогану Java

Из вывода видно описание отмененного коммита. Используем его для нового:


> git commit -m "Добавил quiz по слогану Java"

Больше подробностей о reflog по ссылке.

Не забудьте добавить *.class в.gitignore.

3.3. Удаление файла с GitHub

Самый неприятный случай — это когда мусорный файл все же пробрался на GitHub, т. е. был запушен:

В этом случае наставник вам может написать замечание: «на GitHub не должно быть файлов с расширением *.class, только *.java. Необходимо удалить из УР все class-файлы».

Самый простой выход из этой ситуации — это удалить в ЛР class-файлы, добавить в .gitignore маску *.class и сделать новый пуш. После этих действий на GitHub class-файл удалится. Он также автоматически удалится и у всех людей, которые работают с вами в одном репозитории. Например, когда наставник перед проверкой вашего ДЗ сделает git pull, то удаленные вами class-файлы, удалятся автоматически и у него.

Выглядеть это может примерно так:


D:JavaStartJava (master -> origin)
> git rm src*.class
rm 'src/MyFirstApp.class'


> git status
On branch master

Changes to be committed:
        new file:   .gitignore
        deleted:    src/MyFirstApp.class

> git commit -m "Добавил .gitignore с маской *.class"
[master 4bf0ddd] Добавил .gitignore с маской *.class
 2 files changed, 1 insertion(+)
 create mode 100644 .gitignore
 delete mode 100644 src/MyFirstApp.class

> git push

4. Как изменить описание коммита?

4.1. Коммит не был запушен

Вы сделали коммит, но еще его не запушили. Выясняется, что описание к нему содержит опечатку или это сообщение нужно изменить. Разберем данную ситуацию.

Внесем ряд изменений в файл MyFirstApp.java, добавив в него код, запрашивающий у участника квиза его имя, которое будет выводиться, если он ответит правильно на вопрос:


import java.util.Scanner;

public class MyFirstApp {
    public static void main(String[] args) {
        Scanner console = new Scanner(System.in, "cp866");
        System.out.print("Введите, пожалуйста, свое имя: ");
        String name = console.next();

        System.out.println("У какого языка программирования следующий слоган:");
        System.out.print(""Написано однажды, ");
        System.out.println("работает везде!"");

        String answer = console.next();
        if (answer.equalsIgnoreCase("Java")) {
            System.out.println(name + ", вы угадали!");
        } else System.out.println("Увы, но - это Java");
    }
}

> git add MyFirstApp.java
> git commit -m "Добавил ввод имени учасника"

Выясняется, что описание содержит опечатку в слове «учасника».

Для исправления воспользуемся двумя вариантами команды commit:

  • в первом случае при вводе git commit —amend, откроется редактор для изменения сообщения:

Такой способ подходит для исправления многострочных комментариев. Нам же больше подходит второй способ.

  • во втором случае команда ниже позволит внести изменение прямо из консоли:

> git commit --amend -m "Добавил ввод имени участника"
[master 96e2847] Добавил ввод имени участника

Убедимся, что описание к коммиту изменилось, а прежнее — не сохранилось, отобразив сокращенную информацию по последнему коммиту:


> git log --oneline -1
96e2847 (HEAD -> master) Добавил ввод имени участника

Следует обратить внимание на то, что данные способы позволяют внести изменение в описание только последнего коммита.

4.2.1. Принудительная перезапись истории

Что описание к коммиту нужно изменить, вы вспомнили, когда он был уже отправлен на GitHub.

Чтобы решить эту задачу, необходимо к команде из предыдущего пункта добавить git push -f, которая принудительно перезапишет коммит с ошибочным описанием — исправленным:


> git commit --amend -m "Добавил ввод имени участника"
> git push -f

Среди прочего, в консоли отобразится примерно следующая строка:


+ 5aa3d6d...ce3cf6f master -> master (forced update).

Она сообщает, что было сделано принудительное обновление репозитория.

У ваших коллег (или наставника) после ввода git pull отобразятся строки, тоже сообщающие о принудительном изменении и последующем успешном слиянии (merge):


+ 5aa3d6d...ce3cf6f master     -> origin/master  (forced update)
Merge made by the 'ort' strategy.

5. Как выполнить пуш, если Git не дает это сделать?

Представим, что на первых порах вы еще не до конца освоили Git и какое-то время вносили изменения в файлы прямо на GitHub. Но рано или поздно поняли, что для своего профессионального роста все же нужно изучить базовые команды Git, и применять их в консоли.

После этого у себя на компьютере начали писать код очередного домашнего задания, а затем решили его запушить на GitHub для проверки наставником. Но сделать пуш у вас в итоге не получилось, а в консоли отобразилась ошибка:


hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes

Возможна и другая ситуация, когда вы пушите в один репозиторий на GitHub с разных компьютеров. Например, днем, в свободное от работы время, порешали домашку, а затем запушили ее на удаленный репозиторий. Вечером, придя домой, продолжили писать код для следующего ДЗ. А про код, запушенный на GitHub, либо забыли, либо подумали, что из-за него проблем не будет. Но в действительности оказалось все иначе.

Или на GitHub случайно попали class-файлы и вы без задней мысли пошли на сайт и удалили их.

Во всех этих ситуациях пуш приведет к одной и той же ошибке, связанной с тем, что истории изменений на локальном и удаленном репозитории пошли разными путями: на GitHub есть коммит, которого нет в ЛР. В дереве коммитов на ЛР на какое-то количество коммитов меньше, чем на УР.

Научимся решать эту проблему.

5.1. Подтягивание изменений с GitHub

Зайдя в свой репозиторий на GitHub, я внес в README.md следующие мелкие изменения:

  • добавил картинку в виде шапки
  • пункт «Командная строка» заменил на конкретное название используемой программы — cmder
  • добавил иконки к каждому пункту списка

В качестве описания к коммиту указал следующий текст:

При этом README.md содержит следующий код:


# [StartJava](https://topjava.ru/startjava) -- курс на Java для начинающих

![image](https://user-images.githubusercontent.com/29703461/194078652-25a6e509-cdc6-4af4-9ab0-78b6b336c749.png)

## Используемые на курсе инструменты и технологии

:coffee: Java

:octocat: Git/GitHub

:pager: cmder

:bookmark_tabs: Sublime Text

:fire: Intellij IDEA

:gem: SQL

:elephant: PostgreSQL

:newspaper: psql

Проделанные только что изменения я благополучно забыл подтянуть на свой компьютер с помощью git pull. И продолжил работать над классом MyFirstApp.java в ЛР, добавив в него еще один квиз и немного мелких правок.

В итоге класс (у меня на компьютере, не в GitHub) стал выглядеть так:


import java.util.Scanner;

public class MyFirstApp {
    public static void main(String[] args) {
        Scanner console = new Scanner(System.in, "cp866");
        System.out.print("Введите, пожалуйста, свое имя: ");
        String name = console.nextLine();

        System.out.println("n1. У какого языка программирования следующий слоган:");
        System.out.print(""Написано однажды, ");
        System.out.println("работает везде!"");

        String answer = console.nextLine();
        if (answer.equalsIgnoreCase("Java")) {
            System.out.println(name + ", вы угадали!");
        } else System.out.println("Увы, но - это Java");

        System.out.println("n2. Какая фамилия у автора языка Java?");

        answer = console.nextLine();
        if (answer.equals("Гослинг") || answer.equals("Gosling")) {
            System.out.println(name + ", вы угадали!");
        } else System.out.println("Увы, но - это Гослинг (Gosling)");
    }
}

Добавил изменения в коммит:


> git add MyFirstApp.java
> git commit -m "Добавил quiz по автору Java"

Отобразим полученный результат в консоли:


> git log --oneline -1
7106587 (HEAD -> master) Добавил quiz по автору Java

А теперь самое интересное: попробуем сделать push:


> git push
To https://github.com/ichimax/startjava2.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/ichimax/startjava2.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Отобразилась ошибка, означающая, что в локальном и удаленном репозитории истории изменений пошли разными путями и не соответствуют друг другу.

Для решения этой проблемы Git предлагает выполнить команду pull, которая подтянет коммиты с УР, а затем объединит их с локальными, чтобы выровнять историю:


> git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 1.16 KiB | 62.00 KiB/s, done.
From https://github.com/ichimax/startjava2
   ce3cf6f..2bdecf7  master     -> origin/master
Merge made by the 'ort' strategy.
 README.md | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

В этом сообщении стоить обратить внимание на строку Merge made by the ‘ort’ strategy. Из нее мы можем сделать вывод, что произошло слияние (merge).

Слияние — это объединение истории коммитов из разных веток в одну. У нас ветка хоть и одна (master), но история коммитов на GitHub и в ЛР стала с какого-то момента различаться. Из-за этого и не удавалось сделать push. Когда мы выполнили git pull, то Git автоматически объединил (что бывает не всегда) последний коммит из УР с последним коммитом из ЛР, создав новый.

Не всегда Git может выполнить слияние автоматически, что вызывает конфликт слияния. Такое бывает, когда в разных ветках был изменен один и тот же фрагмент кода. Из-за этого Git не сможет определить, какую версию использовать. Для решения проблемы потребуется вмешательство пользователя. Более подробно об этом можно узнать по ссылке.

Для того, чтобы минимизировать возникновение подобных ситуаций (конфликтов), рекомендуется каждый раз перед началом работы с проектом делать git pull, чтобы синхронизировать историю коммитов ЛР с историей УР.

Отобразим 4 последних коммита:


> git log --oneline -4
1b4a7b7 (HEAD -> master) Merge branch 'master' of https://github.com/ichimax/startjava2
7106587 Добавил quiz по автору Java
2bdecf7 (origin/master) Обновил README.md
ce3cf6f Добавил ввод имени участника

Из этого списка видно, что:
2bdecf7 — был сделан на GitHub
7106587 — был сделан в ЛР
1b4a7b7 — получился автоматически после слияния двух предыдущих коммитов

Обратите внимание, что у коммита, сделанного на GitHub, ветка называется не master, а origin/master. Разница в том, что master — это имя локальной ветки, а origin/master является удаленной веткой с именем master.

Отобразим ветки, связанные с нашим репозиторием:


> git branch -a
* master
  remotes/origin/master

Ветка master является текущей (помечена *) веткой ЛР. remotes/origin/master — это ветвь с именем master и псевдонимом origin на УР.

То, что это — разные ветки, можно убедиться визуально, введя следующую команду:


D:JavaStartJavasrc (master -> origin)
> git log --pretty=format:"%h - %s" --graph
*   1b4a7b7 - Merge branch 'master' of https://github.com/ichimax/startjava2
| 
| * 2bdecf7 - Обновил README.md
* | 7106587 - Добавил quiz по автору Java
|/
* ce3cf6f - Добавил ввод имени участника
* 4bf0ddd - Добавил .gitignore с маской *.class
* 90ca67c - Добавил quiz по слогану Java
* b59d871 - Изменил вывод текста, отображаемого в консоль
* 39ba195 - Переименовал about.txt в README.md и внес в него описание проекта
* 1e36e0f - Инициализация проекта

Опция —graph позволяет вывести граф в формате ASCII, который показывает текущую ветку и историю слияний. Более подробно с разными опциями команды log можно ознакомиться по ссылке.

Давайте взглянем на различия в последних коммитах в удаленной и локальной master-ветках:


D:JavaStartJavasrc (master -> origin)
> git diff origin/master..master
diff --git a/src/MyFirstApp.java b/src/MyFirstApp.java
index 8e25560..08099ad 100644
--- a/src/MyFirstApp.java
+++ b/src/MyFirstApp.java
@@ -4,15 +4,22 @@ public class MyFirstApp {
     public static void main(String[] args) {
         Scanner console = new Scanner(System.in, "cp866");
         System.out.print("Введите, пожалуйста, свое имя: ");
-        String name = console.next();
+        String name = console.nextLine();

-        System.out.println("У какого языка программирования следующий слоган:");
+       System.out.println("n1. У какого языка программирования следующий слоган:");
         System.out.print(""Написано однажды, ");
         System.out.println("работает везде!"");

-        String answer = console.next();
+        String answer = console.nextLine();
         if (answer.equalsIgnoreCase("Java")) {
             System.out.println(name + ", вы угадали!");
         } else System.out.println("Увы, но - это Java");
+
+        System.out.println("n2. Какая фамилия у автора языка Java?");
+
+        answer = console.nextLine();
+        if (answer.equals("Гослинг") || answer.equals("Gosling")) {
+            System.out.println(name + ", вы угадали!");
+        } else System.out.println("Увы, но - это Гослинг (Gosling)");
     }
 }

После всех манипуляций отобразим состояние репозитория:


> git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
 
nothing to commit, working tree clean

Посмотрим, какие два коммита мы должны запушить:


> git log --branches --not --remotes --oneline
1b4a7b7 (HEAD -> master) Merge branch 'master' of https://github.com/ichimax/startjava2
7106587 Добавил quiz по автору Java

Выполним push и снова введем команду, отображающую список из 4 коммитов:


> git push
> git log --oneline -4
1b4a7b7 (HEAD -> master, origin/master) Merge branch 'master' of https://github.com/ichimax/startjava2
7106587 Добавил quiz по автору Java
2bdecf7 Обновил README.md
ce3cf6f Добавил ввод имени участника

Видим, что история коммитов выровнялась: HEAD в ЛР и УР указывают на самый последний коммит 1b4a7b7.

Список решений тех или иных задач с помощью Git, разобранных в статье, с кратким описанием.

В статье мы рассмотрели самые простые, но часто возникающие проблемы, которые могут появиться при работе с Git и GitHub. Это базовый минимум, который поможет вам на первых порах не чувствовать себя растерянным, столкнувшись лицом к лицу с описанными сложностями.

Оцените статью, если она вам понравилась!




Содержание статьи


fatal: No such remote ‘origin’

fatal: No such remote ‘origin’

fatal: No such remote ‘origin’

Скорее всего Вы пытаетесь выполнить

$ git remote set-url origin https://github.com/name/project.git

Попробуйте сперва выполнить

$ git remote add origin https://github.com/name/project.git

2

To https://github.com/YourName/yourproject.git

! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ‘https://github.com/YourName/yourproject.git’


hint: Updates were rejected because the tip of your current branch is behind

hint: its remote counterpart. Integrate the remote changes (e.g.

hint: ‘git pull …’) before pushing again.

hint: See the ‘Note about fast-forwards’ in ‘git push —help’ for details.

Скорее всего Вы пытаетесь выполнить

git push origin master

в новом репозитории.

При этом, когда
Вы создавали удалённый репозиторий на github Вы отметили опцию initialize with readme file.

Таким образом на удалённом репозитории файл

README.md

есть, а на локальном нет. Git не
понимает как такое могло произойти и предполагает, что на удалённый репозиторий кто-то (возможно Вы)
добавил что-то неотслеженное локальным репозиторием.

Первым делом попробуйте

$ git pull origin master

$ git push origin master

Git скачает файл

README.md

с удалённого репозитория и затем можно будет спокойно пушить

Если сделать pull не получилось, например, возникла ошибка

From https://github.com/andreiolegovichru/heiheiru

* branch master -> FETCH_HEAD

fatal: refusing to merge unrelated histories

Попробуйте

$ git pull —allow-unrelated-histories origin master

$ git push origin master

ERROR: Permission to AndreiOlegovich/qa-demo-project.git denied to andreiolegovichru.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Возможная причина — git не видит ваш ключ. Либо ваш ключ уже используется для другого удалённого
хранилища.

Решить можно удалив стандарный ключ id_rsa.pub создать новую пару и добавить на удалённое хранилище.

Если этот способ не подходит — нужно настроить config.

Урок, в котором мы изучим команды git push и git pull и научимся работать с удаленным репозиторием

Видеоурок

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине.
Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.

Что такое push (пуш)

Это отправка данных на сервер, в удаленный репозиторий, на github. Данные — это коммиты и ветки.

Зачем пушить на сервер

  • для работы в команде, чтобы делиться своим кодом с коллегами
  • чтобы иметь резервную копию на случай потери данных на своей машине

Когда пушить на сервер

Когда сделали новый коммит или несколько коммитов

Как узнать, что есть незапушенные коммиты

В командной строке набрать git status


    $ git status
    
    On branch master
    $ git status
    On branch master
    Your branch is ahead of 'origin/master' by 5 commits.
      (use "git push" to publish your local commits)
    (use "git push" to publish your local commits)

Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов.
Если незапушенных коммитов нет, то картина будет такая


    $ git status
    
    On branch master
    Your branch is up-to-date with 'origin/master'.

«is up-to-date» означает, что у нас нет незапушенных коммитов

В PhpStorm понять, есть ли неотправленные коммиты, можно посмотрев в окно Version Control — Log, где находятся метка master и origin/master. Если master выше, то есть незапушенные коммиты.

master и origin/master

Это ветки: локальная и удаленная (на сервере, в github). По умолчанию мы находимся в ветке master.
Подробно работу с ветками мы рассмотрим в следующем уроке,
а пока достаточно запомнить, что master — это то, что на нашей машине, а origin/master — в удаленном репозитории, на github.

git push в терминале


    $ git push origin master
  • push — что сделать, отправить
  • origin — куда, на сервер
  • master — что, ветку master

Как пушить в PhpStorm

Правый клик — Git — Repository — Push… — Кнопка Push

Что такое pull (пулл)

Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.

Зачем пулиться с сервера

Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах

git pull в терминале


    $ git pull origin master
  • pull — что сделать, получить данные
  • origin — откуда, с сервера
  • master — а точнее, с ветки master

Как пулить в PhpStorm

Правый клик — Git — Repository — Pull… — Кнопка Pull

Когда что-то пошло не так…

Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры

git push rejected

Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое


    $ git push origin master
    To git@github.com:Webdevkin/site-git.git
     ! [rejected]        master -> master (fetch first)
    error: failed to push some refs to 'git@github.com:Webdevkin/site-git.git'
    hint: Updates were rejected because the remote contains work that you do
    hint: not have locally. This is usually caused by another repository pushing
    hint: to the same ref. You may want to first integrate the remote changes
    hint: (e.g., 'git pull ...') before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?

Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера.
Те самые, которые успели сделать наши коллеги. То есть сделать git pull.

Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected.
Значит, нам нужно сначала сделать git pull, а затем снова запушить


    $ git pull origin master
    remote: Enumerating objects: 4, done.
    remote: Counting objects: 100% (4/4), done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.
    From github.com:Webdevkin/site-git
     * branch            master     -> FETCH_HEAD
       239892a..383b385  master     -> origin/master
    Merge made by the 'recursive' strategy.
     README.md | 3 +++
     1 file changed, 3 insertions(+)
     create mode 100644 README.md

Здесь нас подстерегает неожиданность — в терминале выскакивает окно редактирования коммита. Пока просто сохраним, что предложено по умолчанию и закроем редактор.
Вот теперь можно пушить свои коммиты


    $ git push origin master 
    Counting objects: 19, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (17/17), done.
    Writing objects: 100% (19/19), 1.98 KiB | 0 bytes/s, done.
    Total 19 (delta 4), reused 0 (delta 0)
    remote: Resolving deltas: 100% (4/4), completed with 1 local object.
    To git@github.com:Webdevkin/site-git.git
       383b385..f32b91e  master -> master

Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git».
Это так называемый мердж-коммит, о нем чуть ниже.

Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.

Как избавиться от мердж-коммита

Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера.
Мердж-коммит не несет смысловой информации, кроме самого факта мерджа.
Без него история коммитов выглядит чище.

Чтобы избавиться от него, подтягивайте изменения командой git pull с флажком —rebase


    $ git pull --rebase origin master 

При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет.
И не забудьте после этого запушить свой коммит на сервер.

Мердж-коммит в PhpStorm

PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий.
Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант:
как подтянуть новые коммиты, с мерждем или ребейзом.
Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

Внимание

Объяснения в тексте не передают точно возникающие проблемы, это нужно видеть в динамике.
Поэтому лучше смотрите видеоуроки и еще лучше пробуйте сами повторять их содержание.

Что могу посоветовать

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

Но при работе в команде имеет смысл подумать над такими вещами:

  • пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
  • пулиться почаще — обратная ситуация, почаще получать свежие изменения
  • всегда пультесь с флажком ребейза — git pull —rebase origin master
  • не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
  • не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
  • больше практикуйтесь. Посадите домашний проект на git и работайте с ним

Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут.
Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.

git push pull whaaat

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними.
Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Спасибо за внимание и до встречи!

Все уроки курса

  • Вводный урок
  • 1. Установка и базовая настройка git
  • 2. Создание и клонирование репозитория git
  • 3. Делаем первые изменения, git status и git diff
  • 4. Коммиты и история коммитов, git commit, git log и git show
  • 5. Подробнее об истории коммитов. Путешествие по истории
  • 6. Работа с сервером, git push и git pull
  • 7. Ветки — главная фишка git, git branch и git checkout
  • 8. Работа с ветками на сервере, git fetch
  • 9. Слияния или мерджи веток, git merge
  • 10. Конфликты и их разрешение
  • Платная часть курса. Презентация
  • * 11. Работа с gitignore и git exclude
  • * 12. Буфер обмена git, git stash
  • * 13. Копирование коммитов, git cherry-pick
  • * 14. Отмена и редактирование последнего коммита
  • * 15. Отмена произвольного коммита, git revert
  •    16. Склеивание коммитов, git rebase —interactive и git reflog
  • * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
  • * 18. Работа с git rebase. Отличия от merge
  • * 19. Что такое git push —force и как с ним работать
  • * 20. Ищем баги с помощью git, git bisect
  • * 21. Как и зачем работать с тегами git
  • * 22. Процессы: github flow и git flow
  • * 23. Псевдонимы в git
  •    24. Мердж-реквесты
  • * 25. Форки

* платные уроки

список обновляется…

Error: failed to push some refs to – How to Fix in Git

When collaborating with other developers using Git, you might encounter the error: failed to push some refs to [remote repo] error.

This error mainly occurs when you attempt to push your local changes to GitHub while the local repository (repo) has not yet been updated with any changes made in the remote repo.

So Git is trying to tell you to update the local repo with the current changes in the remote before pushing your own changes. This is necessary so that you don’t override the changes made by others.

We’ll be discussing two possible ways of fixing this error in the sections that follow.

We can fix the error: failed to push some refs to [remote repo] error in Git using the  git pull origin [branch] or git pull --rebase origin [branch] commands. In most cases, the latter fixes the error.

Let’s go over how you can use the commands above.

How to Fix error: failed to push some refs to Error in Git Using git pull

To send a pull request means to «fetch» new changes made to the remote repo and merge them with the local repo.

Once the merging is done, you can then push your own code changes to GitHub.

In our case, we’re trying to get rid of the error: failed to push some refs to [remote repo] error by sending a pull request.

Here’s how you can do that:

git pull origin main

If you’re working with a different branch, then you’d have to replace main in the example above with the name of your branch.

Just keep in mind that there are chances of failure when using this command to sync your remote and local repos to get rid of the error. If the request succeeds, then go on and run the command below to push your own changes:

git push -u origin main

If the error persists, you’ll get an error that says: fatal: refusing to merge unrelated histories. In that case, use the solution in the next section.

How to Fix error: failed to push some refs to Error in Git Using git pull --rebase

The git pull --rebase  command is helpful in situations where your local branch is a commit behind the remote branch.

To fix the error, go on and run following commands:

git pull --rebase origin main

git push -u origin main 

If the first command above runs successfully, you should get a response that says: Successfully rebased and updated refs/heads/main.

The second command pushes your local repo’s current state to the remote branch.

Summary

In this article, we talked about the error: failed to push some refs to [remote repo] error.

This error occurs when you attempt to push your local changes to the remote repo without updating your local repo with new changes made to the remote repo.

We discussed two commands that you can use to fix the error: the git pull origin [branch] and git pull --rebase origin [branch] commands.

I hope this helps you fix the error.

Happy coding!



Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Понравилась статья? Поделить с друзьями:
  • Error failed to push some refs to https
  • Error failed to push some refs to heroku
  • Error failed to push some refs to gitlab
  • Error failed to push some refs to git как исправить
  • Error failed to push some refs to git github com