(Note: starting Oct. 2020, any new repository is created with the default branch main, not master. And you can rename existing repository default branch from master to main.
The rest of this 2014 answer has been updated to use «main«)
(The following assumes github.com itself is not down, as eri0o points out in the comments: see www.githubstatus.com to be sure)
If the GitHub repo has seen new commits pushed to it, while you were working locally, I would advise using:
git pull --rebase
git push
The full syntax is:
git pull --rebase origin main
git push origin main
With Git 2.6+ (Sept. 2015), after having done (once)
git config --global pull.rebase true
git config --global rebase.autoStash true
A simple git pull would be enough.
(Note: with Git 2.27 Q2 2020, a merge.autostash is also available for your regular pull, without rebase)
That way, you would replay (the --rebase part) your local commits on top of the newly updated origin/main (or origin/yourBranch: git pull origin yourBranch).
See a more complete example in the chapter 6 Pull with rebase of the Git Pocket Book.
I would recommend a:
# add and commit first
#
git push -u origin main
# Or git 2.37 Q2 2022+
git config --global push.autoSetupRemote true
git push
That would establish a tracking relationship between your local main branch and its upstream branch.
After that, any future push for that branch can be done with a simple:
git push
Again, with Git 2.37+ and its global option push.autoSetupRemote, a simple git push even for the first one would do the same (I.e: establishing a tracking relationship between your local main branch and its upstream branch origin/main).
See «Why do I need to explicitly push a new branch?».
Since the OP already reset and redone its commit on top of origin/main:
git reset --mixed origin/main
git add .
git commit -m "This is a new commit for what I originally planned to be amended"
git push origin main
There is no need to pull --rebase.
Note: git reset --mixed origin/main can also be written git reset origin/main, since the --mixed option is the default one when using git reset.
Sometimes, Git can’t make your change to a remote repository without losing commits. When this happens, your push is refused.
If another person has pushed to the same branch as you, Git won’t be able to push your changes:
$ git push origin main
> To https://github.com/USERNAME/REPOSITORY.git
> ! [rejected] main -> main (non-fast-forward)
> error: failed to push some refs to 'https://github.com/USERNAME/REPOSITORY.git'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes (e.g. 'git pull') before pushing again. See the
> 'Note about fast-forwards' section of 'git push --help' for details.You can fix this by fetching and merging the changes made on the remote branch with the changes that you have made locally:
$ git fetch origin
# Fetches updates made to an online repository
$ git merge origin YOUR_BRANCH_NAME
# Merges updates made online with your local workOr, you can simply use git pull to perform both commands at once:
$ git pull origin YOUR_BRANCH_NAME
# Grabs online updates and merges them with your local workВремя на прочтение
6 мин
Количество просмотров 64K
В финальной части нашей серии статей о работе с Git мы продолжим разговор о ветках, рассмотрим особенности работы с командой push и расскажем, что такое rebase. Первую и вторую статьи серии вы можете прочитать по ссылкам.
Глава 16. Откуда взялась ветка?
Набираемся терпения и продолжаем рассматривать разные рабочие ситуации. Если мы сделаем несколько коммитов, а потом выполним команду fetch (скачаем свежие коммиты, но пока не применим их в рабочий каталог), то увидим немного сбивающую с толку картину:
Что это ещё за ветка получилась? Мы ведь не создавали никакой ветки. Может её создал кто-то из сотрудников? Нет, никто её не создавал. Восстановим хронологию событий:
- Сначала мы скачали свежие коммиты. Тогда последним был коммит «2».
- Затем мы сделали коммиты «3» и «4» (но пока не пушили их).
- В это время другие сотрудники запушили в удалённый репозиторий коммиты «5», «6» и «7». Тогда мы ничего не знали об этом.
- Наконец, мы сделали fetch и увидели то, что на картинке.
В Git каждый коммит хранит ссылку на предыдущий (это и позволяет нам соединять кружки на рисунках; каждый отрезок – это ссылка на предыдущий коммит). Когда мы сделали коммит «3», для нас последним коммитом был «2» поэтому они соединены. Но когда на origin кто-то запушил коммит «5», там последним был тоже коммит «2» – ведь мы свои коммиты «3» и «4» ещё не запушили, и на origin их не было. А раз так, то для коммита «5» предыдущим тоже выступает коммит «2», именно эту связь Git и запомнил.
Итого, разные люди независимо друг от друга поменяли результат коммита «2» – вот и возникла ветка. Кстати, эта ветка сейчас есть только в нашем локальном репозитории. В origin её пока нет, поскольку коммиты «3» и «4» мы до сих пор не запушили.
Что дальше? Поскольку мы сделали fetch, а не pull, то скачанные коммиты ещё не применились к нашему рабочему каталогу. Давайте применим их – для этого выполним merge. Результат представлен на картинке:
Произошедшее уже знакомо нам. Образовался автоматический merge-commit «8» – master и head теперь указывают на него. В рабочей копии появились изменения из коммитов «5», «6» и «7», которые объединились с нашими изменениями из коммитов «3» и «4». origin/master по-прежнему указывает на «7», поскольку последние наши операции проходили на локальном компьютере. А origin/master может сдвинуться только после общения нашего репозитория с origin.
Наконец, делаем push, и вот теперь origin/master тоже указывает на «8», ведь:
- Наш merge-commit «8» отправлен в origin.
- Там он стал последним, а значит удалённый указатель master теперь показывает на него.
- Нам скачалась информация об удалённом указателе master и мы её видим как origin/master.
Вот он и показывает на «8». Логично.
Не поддавайтесь малодушному желанию пропустить эти объяснения. В них нет ничего сложного, нужна лишь внимательность. Обязательно пройдитесь по шагам до тех пор, пока не поймете, почему все так работает.
Глава 17. Почему push выдаёт ошибку?
Вы обязательно столкнетесь с тем, что Git выдаёт ошибку при команде push. В чём проблема? Почему он не принимает наши коммиты? Push успешно завершится, только если для каждого отправляемого в origin коммита Git сможет найти предшественника. Пример:
Здесь слева изображены коммиты в вашем локальном репозитории, а справа – коммиты в удалённом репозитории (origin).
Хронология этих коммитов следующая:
- Сначала в origin были коммиты «1» и «2».
- Мы сделали pull (в локальном репозитории тоже оказались лишь эти два коммита).
- Потом мы закоммитили «3» и «4» в локальный репозиторий (но не пушили).
- Кто-то запушил коммит «5» в origin.
И получилось то, что сейчас на картинке. Разобрались?
Теперь наша попытка запушить «3» и «4» в origin завершится ошибкой. Git откажется пристыковать наши коммиты к последнему коммиту «5» в origin, поскольку в local предшественником для коммита «3» является коммит «2» – а вовсе не «5», как в origin! Для Git важно, чтобы предшественник был тот же.
Проблема решается легко. Перед тем, как сделать push, мы сделаем pull (забираем коммит «5» себе). Тут вы можете спросить: «Секунду! А почему это забрать коммит «5» Git может, а послать коммиты «3» и «4» он не может? Вроде же ситуация симметричная в обе стороны». Правильный вопрос! А ответ на него простой. Если бы Git позволил отправить коммиты «3» и «4» в такой ситуации, то пришлось бы делать merge на стороне origin – а кто там будет разрешать конфликты? Некому. Поэтому Git заставляет вас сначала забрать свежие коммиты себе, сделать merge на своем компьютере (если будут конфликты, то разрешить их), а уже готовый результат он позволит вам отправить в origin командой push. При этом, никаких конфликтов в origin уже быть не может.
Давайте посмотрим, как будет выглядеть локальная история, после того, как вы заберете коммит «5» командой pull.
Здесь у «3» и «5» предок «2», как и на предыдущей картинке. А новый коммит «6» – это уже давно известный нам merge-commit.
В таком состоянии локальные коммиты уже можно запушить. Пусть тут и появилось разветвление истории, но обе ветки при мерже объединились. А значит голова у ветки снова одна. То есть, ничего не мешает сделать push. После этого в origin коммиты будут выглядеть такой же точно «петелькой».
Теперь, когда push выдаст вам ошибку, вы уже знаете почему и что с этим делать.
Глава 18. Rebase
В предыдущей главе мы сделали несколько локальных коммитов, а потом командой pull забрали коммиты других сотрудников из удалённого репозитория. У нас в локальном репозитории образовалась как бы «ветка», которая потом обратно объединилась с основной. После push это временное раздвоение ветки попало в origin, откуда его скачают сотрудники и увидят в своей истории. Часто такие «петли» считаются нежелательными. Поскольку вместо красивой линейной истории получается куча петель, которые затрудняют просмотр.
Git предлагает альтернативу. Выше мы делали fetch+merge. Первая команда забирает свежие коммиты, вторая объединяет их с нашими незапушенными коммитами (если они есть) и создаёт merge-commit с результатом объединения.
Так вот, оказывается можно вместо fetch+merge делать fetch+rebase. Что за rebase и чем он отличается от merge? Вспомним ещё раз, как проходил merge в предыдущем примере:
Rebase действует по-другому – он отсоединяет вашу цепочку незапушенных коммитов от своего предка. Напомним, это были коммиты «3» и «4». Они отсоединяются от своего предка «2» и rebase ставит их «сверху» на только что скачанный коммит «5». То есть, «3» и «4» будут прицеплены сверху к «5» (а мерж-коммит «6» вообще не появится). Итог будет таким:
Никакой петли больше нет, история линейная и красивая! Да здравствует rebase! Теперь мы знаем, что при скачивании коммитов из origin лучше объединять их со своими локальными коммитами при помощи rebase, а не merge.
Хорошо, а если речь не о паре-тройке ваших коммитов, а о большой ветке с разработкой новой фичи. Когда настанет время влить эту фичу в главную ветку, как это лучше сделать – через rebase или merge? У обоих способов есть преимущества:
- rebase позволит сохранить историю простой и линейной – он добавит цепочку ваших коммитов из ветки в конец основной ветки.
- merge сделает петлю, но зато в истории более наглядно будет прослеживаться история разработки вашей фичи.
Вопрос предпочтения rebase или merge в таких случаях обсудите с ведущим программистом вашего проекта.
Глава 19. Эпилог
Мы с вами разобрались в множестве команд Git для работы с репозиториями:
- pull
- commit
- push
- add
- clone
- checkout
- stash
- merge
- rebase
- abort
- fetch
Это не все команды, которые бывают нужны в работе – только самые частые. Будьте готовы, что потребуется освоить и другие. Работать с Git можно при помощи разных git-клиентов. Мы в основном используем эти три:
- Консольный
- SourceTree
- TortoiseGit
Выбор клиента – дело вкуса.
Консольный – работает на всех платформах, но у него крайне аскетичный интерфейс. Если вы не привыкли работать в консоли, то скорее всего вам будет в нем некомфортно.
SourceTree — графический клиент с довольно простым интерфейсом. Есть версии для наших основных платформ: Win и Mac. Однако, сотрудники часто жалуются на его медленную работу и глюки.
TortoiseGit — еще один графический клиент. Есть версия для Win, для Mac`а нет. Интерфейс несколько непривычный, но многим нравится. Жалоб на глюки и тормоза существенно меньше, чем в случае с SourceTree.
Интересно, что и SourceTree, и TortoiseGit не работают с репозиторием Git напрямую. Внутри себя они используют консольный Git. Когда вы нажимаете на красивые кнопки, вызываются консольные команды Git с разными хитрыми параметрами, а результат вызова снова показывают в красивом виде. Использование всеми клиентами консольного Git означает, что все они работают со стандартной файловой структурой Git-хранилища на вашем жёстком диске. А значит можно использовать смешанный стиль работы: одни операции выполнять в одном клиенте, а другие – в другом.
Итак, вы узнали основные концепции, используемые системой контроля версий Git. А также, как работают основные команды. Наверняка при чтении статьи вам не хватало описания «какие кнопки нажимать». Однако, в каждом Git-клиенте это выглядит по-разному, поэтому нам пришлось отделить описание логики от описания интерфейса. Настало время выбрать один из клиентов и изучить его интерфейс пользователя.
Успехов!
Git: советы новичкам – часть 1
Git: советы новичкам – часть 2
Git: советы новичкам – часть 3
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 mainIf 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 mainIf 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
- →
В предыдущей статье мы прошли базовые команды 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 для начинающих
## Используемые на курсе инструменты и технологии
: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. Это базовый минимум, который поможет вам на первых порах не чувствовать себя растерянным, столкнувшись лицом к лицу с описанными сложностями.
Оцените статью, если она вам понравилась!
