Error src refspec main does not match any перевод

Я клонирую свой репозиторий с помощью:

Я клонирую свой репозиторий с помощью:

git clone ssh://xxxxx/xx.git 

Но после того, как я изменю некоторые файлы, add и commit их, я хочу отправить их на сервер:

git add xxx.php
git commit -m "TEST"
git push origin master

Но ошибка, которую я получаю обратно:

error: src refspec master does not match any.  
error: failed to push some refs to 'ssh://xxxxx.com/project.git'

4b9b3361

Ответ 1

Возможно, вам просто нужно зафиксировать. Я столкнулся с этим, когда сделал:

mkdir repo && cd repo
git remote add origin /path/to/origin.git
git add .

Oops! Никогда не совершал!

git push -u origin master
error: src refspec master does not match any.

Все, что мне нужно было сделать:

git commit -m "initial commit"
git push origin master

Успех!

Ответ 2

  1. Попробуйте git show-ref посмотреть, что у вас есть. Есть ли refs/heads/master?

  2. Вы можете попробовать git push origin HEAD:master как более локально-независимое решение. Это явно указано, что вы хотите, чтобы подтолкнуть локальный реф HEAD к удаленному рефу master (см refspec ГИТА-нажимной документация).

Ответ 3

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

Мое сообщение об ошибке было примерно таким:

error: src refspec master does not match any.
error: failed to push some refs to '[email protected] ... .git'

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

touch README
git add README

git add (all other files)
git commit -m 'reinitialized files'
git push origin master --force  # <- caution, --force can delete others work.

Это, надеюсь, это поможет.

Ответ 4

  • Мои изменения уже были совершены
  • Force push все равно дал мне ту же ошибку.

Итак, я попробовал Vi-решение:

git push origin HEAD:<remoteBranch> 

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

Ответ 5

git push -u origin master
error: src refspec master does not match any.

Для этого вам нужно ввести сообщение коммита следующим образом, а затем нажать код

git commit -m "initial commit"

git push origin master

Успешно толкнул мастера

Ответ 6

Для меня я должен был убедиться, что открытый ключ правильно настроен на сервере (добавлен в ~/.ssh/authorized_keys) и в github/bitbucket (добавлен в мои SSH-ключи на github или битбакет) — они должны соответствовать.

Тогда:

git add --all :/

git commit -am 'message'

git push -u origin master

Работал для меня в конце.

Ответ 7

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

Как только я добавил файл (например, README), git push работал отлично.

Ответ 8

Отсутствие или пропуск git add . или git commit может привести к этой ошибке:

git push -u origin master
Username for 'https://github.com': yourusername
Password for 'https://[email protected]': 
error: src refspec master does not match any.
error: failed to push some refs to 'https://github.com/yourusername/foobar.git'

Чтобы исправить это, повторите инициализацию и следуйте правильной последовательности:

git init
git add .
git commit -m 'message'
git *create remote
git push -u origin master

Ответ 9

Чтобы исправить это, повторите инициализацию и следуйте правильной последовательности кода:

git init
git add .
git commit -m 'message'
git push -u origin master

Ответ 10

Убедитесь, что вы добавили сначала, а затем commit/push:

Подобно:

git init
git add .
git commit -m "message"
git remote add origin "github.com/your_repo.git"
git push -u origin master

Ответ 11

Это происходит также, когда вы находитесь в определенной ветке и пытаетесь нажать другую ветвь, которая еще не существует, например:

$ git branch
* version-x  # you are in this branch
  version-y

$ git push -u origin master
error: src refspec master does not match any.
error: failed to push some refs to 'origin_address'

Ответ 12

просто добавьте начальную фиксацию, выполните следующие действия: —

  • git add.

  • git commit -m «initial commit»

  • git push origin master

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

Ответ 13

В моем случае я забыл включить файл .gitignore. Вот все необходимые шаги:

  1. Создайте пустой репозиторий Git на удаленном компьютере,
  2. На локальном создании .gitignore
    файл для вашего проекта. Github дает вам список примеров здесь
  3. Запустите терминал, и в вашем проекте выполните следующие команды:

    git remote add origin YOUR/ORIGIN.git

    git add .

    git commit -m "initial commit or whatever message for first commit"

    git push -u origin master

Ответ 14

Я столкнулся с такой же проблемой, и я использовал --allow-empty.

$ git commit -m "initial commit" --allow-empty
...
$ git push
...

Ответ 15

Вы, вероятно, забыли команду «git add». после команды «git init».

Ответ 16

Моя проблема заключалась в том, что ветвь «master» еще не была создана локально.

Быстрый

git checkout -b "master" 

создал главную ветвь, в этот момент быстро:

git push -u origin master

Передвинул работу до репозитория git.

Ответ 17

Я также следовал указаниям githubs, как указано ниже, но все еще сталкивался с той же ошибкой, что и OP:

git init git add. git commit -m "message" git remote add origin "github.com/your_repo.git" git push -u origin master

Для меня, и я надеюсь, что это поможет некоторым, я загружал большой файл (1.58 GB on disk) на моем MacOS. Копируя, вставляя предложенную строку кодов выше, я не ждал, пока мой процессор завершит add. процесс. Поэтому, когда я набрал git commit -m "message" он, по сути, не ссылался ни на какие файлы и не выполнил все, что нужно для успешной фиксации моего кода на github.

Доказательством этого является то, что когда я набираю git status я обычно получаю зеленые шрифты для добавленных файлов. Но все было красным. Как будто это не было добавлено вообще.

Поэтому я переделал шаги. Набрал git add. и дождитесь окончания добавления файлов. Затем выполните следующие шаги.

Я надеюсь, что это помогает кому-то.

Ответ 18

Это просто означает, что вы забыли сделать первоначальную фиксацию, попробуйте

git add .
git commit -m 'initial commit'
git push origin master

Ответ 19

  • сначала git добавить.
  • second git commit -m «message»
  • третья git push origin branch
    проверьте наличие орфографических ошибок, поскольку это также может привести к этой ошибке.

Ответ 20

У меня была такая же проблема, когда я пропустил запуск:

git add .

(У вас должен быть хотя бы один файл, или вы снова получите ошибку)

Ответ 21

В сценарии, где вы извлекаете код из внешнего репозитория (GitHub),
и хотите импортировать его в личную/внутреннюю систему,

эта команда действительно светит:

git push --all origin

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

Ответ 22

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

Ответ 23

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

1. git commit -m 'message'
2. git config --global user.email "your mail"
3. git config --global user.name "name"
4. git commit -m 'message'
5. git push -u origin master

Надеюсь, что это поможет кому-то

Ответ 24

Если вы получите эту ошибку при работе в режиме отсоединения HEAD, вы можете сделать это:

git push origin HEAD:remote-branch-name

См. Также: создание git-нажатия от отдельной головки

Если вы находитесь в другом локальном филиале, чем удаленная ветвь, вы можете сделать это:

git push origin local-branch-name:remote-branch-name

Ответ 25

git добавить.

— это все, что вам нужно, чтобы этот трек отслеживал все необработанные файлы в вашем каталоге

Ответ 26

Это также произойдет, если у вас есть опечатка в названии ветки, которую вы пытаетесь нажать.

Ответ 27

Если вы столкнулись с этой проблемой даже после выполнения git init и нажатия начального коммита. Вы можете попробовать следующее,

git checkout -b "new branch name"
git push origin "new branch name"

Ваш код будет нажат как новая ветка.

Ответ 28

Вам нужно настроить свой git, если вы впервые используете его с помощью:

git config --global user.email "[email protected]"

git config --global user.name "Your Name"

Ответ 29

Я забыл сделать «git pull origin master» после фиксации и перед нажатием, и это вызовет ту же проблему: «src refspec master не соответствует никому при нажатии на фиксацию в git».
Итак, что вам нужно сделать:

1. git add .
2. git pull origin master
3. git commit -am "Init commit"
4. git push origin master

Ответ 30

Чтобы проверить текущий статус git status

и выполните следующие действия

git init
git add .
git commit -m "message"
git remote add origin "github.com/your_repo.git"
git push -u origin master

Table of Contents
Hide
  1. When does git throws error: src refspec master does not match any?
    1. Scenario 1 – Pushing the changes to master or remote branch
    2. Solution for error: src refspec master does not match any.
    3. Scenario 2 – Check if a remote branch exists.
    4. Scenario 3 – Mismatch in Local and remote branch
    5. Scenario 4 – Committing and pushing Empty Directory in Git

There are quite a few reasons Git throws an error: src refspec master does not match any. Let us look at each of these cases and the solution to it.

Scenario 1 – Pushing the changes to master or remote branch

Let’s say you have created a git repository and added all the files from your local branch, but before committing the files, you try to push them into the remote branch or master branch.

mkdir repo && cd repo
git remote add origin /path/to/origin.git
git add .

After adding the files from the local branch, if you do git push, you will get an error: src refspec master does not match any. error: failed to push some refs to master.

git push -u origin master
error: src refspec master does not match any.

Solution for error: src refspec master does not match any.

All you need to perform is git commit with a proper message and then do git push to the remote origin to avoid any errors.

mkdir repo && cd repo
git remote add origin /path/to/origin.git
git add .

git commit -m "initial commit"
git push origin master

Scenario 2 – Check if a remote branch exists.

If you are working with Github, they have replaced the master branch with the main branch. Hence, in these circumstances, the local branch and remote branch ref will differ, and when you try to push the changes, git will throw an error since the remote branch itself is not present.

Solution First, check what refs you have, and once you find that, make a git push to the specific remote branch.

# To get all the ref 
git show-ref

# replace with your branch name according to ref 
git push origin HEAD:<branch>

Scenario 3 – Mismatch in Local and remote branch

Generally, even the typo in the branch name while pushing the commit to the remote branch will lead to a refspec error. 

Solution  Validate and check if you have given the right branch name while pushing the code to the remote branch.

Scenario 4 – Committing and pushing Empty Directory in Git

A certain version of Git like GitHub, bitbucket does not track the empty directories, so if a directory is empty and you are trying to commit and push, it will lead to an error: src refspec master does not match any.

Solution – Add a file to your directory before pushing it to a remote branch. 

Avatar Of Srinivas Ramakrishna

Srinivas Ramakrishna is a Solution Architect and has 14+ Years of Experience in the Software Industry. He has published many articles on Medium, Hackernoon, dev.to and solved many problems in StackOverflow. He has core expertise in various technologies such as Microsoft .NET Core, Python, Node.JS, JavaScript, Cloud (Azure), RDBMS (MSSQL), React, Powershell, etc.

Sign Up for Our Newsletters

Subscribe to get notified of the latest articles. We will never spam you. Be a part of our ever-growing community.

By checking this box, you confirm that you have read and are agreeing to our terms of use regarding the storage of the data submitted through this form.

@callumgourlay

Describe the bug

When trying to create backup i recieve this error
Screenshot 2021-10-20 171855

Relevant errors (if available)

No response

Steps to reproduce

Attempt to push backup

Expected Behavior

No response

Addition context

No response

Operating system

Windows

@jasonho1308

this should git issue, not related to this plugin, can you push it through cmd?

@callumgourlay

Yeah, I can. I think it’s issues with something local. Going to wipe and start again

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

________________________________
From: Jason Ho ***@***.***>
Sent: Friday, October 22, 2021 2:19:50 PM
To: denolehov/obsidian-git ***@***.***>
Cc: Callum Gourlay ***@***.***>; Author ***@***.***>
Subject: Re: [denolehov/obsidian-git] [Bug]: Error: Src refspec main does not match any error:failed to push some refs (Issue #126)

this should git issue, not related to this plugin, can you push it through cmd?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#126 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APSTFE2NAZWSQGNIBAGJRILUIFQHNANCNFSM5GMBTEIQ>.

@denolehov

@callumgourlay this error usually appears when you don’t stage files for commit. Running the below bash commands should fix the issue:

@callumgourlay

I managed to resolve it by adding the .git folders to all the internal folders and after that it worked fine

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

@saswatm78

@callumgourlay I am having the same issue, have been having it around the same Oct timeframe but was not very proficient with Git so thought maybe I was doing something wrong. I am able to manually push the files using suggestion that @denolehov provided above but the plugin continues to throw the same error.
Obsidian Git Plugin error

Can you explain what you meant by copying all the git folders, are you copy all the contents of the .git folder into each and every nested folder in your vault? appreciate your help.

@denolehov Thank you for the plugin it used to work like a charm for me until this happened.

@callumgourlay

I managed to sort it by creating a new repository and copying the .git folder from one to another. Other than that I don’t remember much of it as it was a while ago now

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

@NorthernBlow

all of your comments doesn’t work for me. i try to push and see that error : error: src refspec main does not match any

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

  • main против master
  • error: src refspec main does not match any
  • согласование отдельных ветвей main и master

Каждый из них находится в отдельном разделе.

main против master

Сам Git не имеет специальных имен веток. 1 Вы можете использовать main, master, trunk или любое другое имя в качестве имени вашей первой ветки. Git традиционно использовал здесь имя master, но есть проект, который делает это настраиваемым, так что если вы француз или испанец, вы можете использовать имя principal, première или {{ X6}}, или, если вы предпочитаете маори, вы можете использовать matua или tuatahi. В настоящее время вы можете сделать это вручную во время или после git init, 2 , но проект заставляет Git делать это автоматически, не требуя второго шага: Если для any причина, по которой вы хотите любое другое имя по умолчанию, вы можете настроить это.

Между тем, GitHub уже решил сделать шаг вперед и присвоить начальному имени ветки по умолчанию main вместо master. Но это оставляет ваш Git и GitHub Git как бы рассинхронизированным. Для получения дополнительной информации о замене GitHub см. Разница между основной и главной ветвью в Github?


1 В такой претензии есть некоторые технические недостатки. Как мы знаем, технически правильный — лучший вид правильного, поэтому позвольте мне добавить несколько предостережений в эту сноску:

  • При объединении автоматически создается сообщение формы merge branch X into Y, когда вы находитесь в ветке Y и запускаете git merge X. Однако, когда вы находитесь на master, Git обычно генерирует только сообщение формы merge branch X.

  • Новый пустой репозиторий, созданный git init, не имеет коммитов и, следовательно, не имеет ветвей (потому что ветка может существовать только при наличии коммитов). Однако вы должны быть в какой-либо ветке в этом новом пустом репозитории. Итак, Git сохраняет какое-то имя в символической ссылке HEAD. Это имя ветки, в которой вы находитесь, даже если это имя ветки не существует (пока). В течение долгого времени в Git был жестко закодирован код, позволяющий вставить туда имя ветки master. (Фактически, это то, что GitHub изменил.)

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

2 Если у вас Git 2.28 или новее, запустите git init --initial-branch=name и / или установите init.defaultBranch с git config в вашей системе или в глобальной конфигурации. Если у вас установлена более ранняя версия Git или вы уже запускали git init, просто используйте git branch -m, чтобы переименовать master на любое имя, которое вам нравится.


error: src refspec main does not match any

Это сообщение об ошибке от Git довольно загадочно для новичков, но на самом деле довольно просто. Проблема в том, что он загружен жаргоном (webster; wikipedia) и сокращает» источник «до» src «.

Git — это все о коммитах. Когда мы клонируем репозиторий, наш Git обращается к другому Git. Этот другой Git ищет репозиторий, а этот другой репозиторий полон коммитов. Затем наш Git создает новый репозиторий локально, переносит в него все их коммиты и превращает все их имена веток в имена удаленного отслеживания . Затем наш Git создает в этом новом репозитории одно имя ветки на основе одного из имен веток. По крайней мере, это нормальный процесс. (И, если вы знаете, что означают все эти термины, хорошо! Если нет, не беспокойтесь о них прямо сейчас. Здесь нужно помнить, что мы получаем все их коммиты и ни одна из их веток , и тогда у нас обычно есть наша Git create одна ветка, соответствующая одной из них.)

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

Когда мы используем git push, мы просим нашу программу Git, которая читает наш собственный репозиторий Git, подключиться к какой-либо другой программе Git, обычно работающей на сервере, которая затем может записывать данные в другой репозиторий Git. Мы бы хотели, чтобы наш Git отправлял Git некоторые из наших коммитов. В частности, мы хотим отправить им наши новые коммиты: те, которые мы только что сделали. В конце концов, именно там мы размещаем все наши хорошие новые вещи. (Git — это все о коммитах, так что это единственное место, где мы можем разместить что угодно.)

Однако после того, как мы отправили эти коммиты, нам нужно в их Git установить одно из их имен веток, чтобы запомнить наши новые коммиты. Это потому, что Git находит коммиты использует имена веток. 3 Настоящие имена каждого коммита — это большие уродливые номера идентификаторов хешей, которые никто не хочет запоминать или смотреть; так что Git запоминает эти числа, используя имена веток. Таким образом, нам нужно только смотреть на имена веток, и эти имена могут иметь для нас значение: trunk, или feature/tall, или tuatahi, или что-то еще.

По умолчанию и по соглашению способ, которым мы делаем это с помощью git push, довольно прост:

git push origin main

Например. Часть git push — это команда, которая означает отправить коммиты и попросить их указать имя . Часть origin — это то, что Git называет удаленным : короткое имя, которое в основном содержит URL. Часть main в конце здесь — это имя нашей ветки. Это тот, который наш Git использует для поиска наших коммитов . Мы попросим Git отправить наши коммиты, а затем попросим их Git также установить свои main.

Эта последняя часть — там, где мы поместили здесь main — это то, что Git называет refspec . На самом деле Refspecs позволяет нам вводить два имени, разделенных двоеточием, или парой других форм. Мы можем, например, использовать HEAD:main, как в ответе Арки (хотя по техническим причинам мы можем захотеть использовать HEAD:refs/heads/main во многих случаях). Но в простых случаях мы можем использовать только одно имя ветки: git push origin main. Простое имя ветки — это простая форма refspec.

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

(См. Также Сообщение ‘src refspec master does not match any’ при отправке коммитов в Git)


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


Что, если наш Git создал только master?

Предположим, мы используем GitHub и попросили GitHub создать для нас новый репозиторий . Они запускают форму git init, которая предоставляет в качестве имени начальной ветки нового репозитория имя main. Они также могут создавать или не создавать одну фиксацию. Скажем, мы заставили их создать этот коммит. Эта одна фиксация будет содержать файлы README и / или LICENSE в зависимости от того, что мы выберем с помощью веб-интерфейса. Создание этой начальной фиксации фактически создает имя ветки main.

Если мы сейчас клонируем их ветку, мы получим их одну фиксацию, которая будет под именем их ветки main. Наш Git переименует их main в origin/main, а затем создаст одно новое имя ветки, main, чтобы соответствовать их имени. Так что все будет хорошо.

Но, если мы создадим наш собственный пустой репозиторий Git, используя сами git init, наш Git может настроить нас так, что наша первая фиксация создаст имя master. У нас не будет ветки main: вместо нее будет ветка master.

Или, если у нас нет GitHub, создающего начальную фиксацию , репозиторий GitHub будет полностью пуст. Поскольку у него нет коммитов, у него нет ветвей: имя ветки может существовать только в том случае, если оно указывает какую-то фиксацию. Поэтому, если мы клонируем этот пустой репозиторий, у нас тоже не будет веток, и наш Git не будет знать, как использовать main: наш Git может вместо этого использовать master. Мы вернулись к той же ситуации, когда наш Git считает, что первое имя, которое нужно создать, должно быть master.

Итак, в этих различных ситуациях мы делаем наши первые фиксации, и все они попадают в ветку с именем master. Если мы сейчас запустим:

git push -u origin main

-u или без него; я не буду вдаваться в подробности о -u здесь) наш Git ищет в нашем репозитории Git ветку с именем main. Нет ни одного! Итак, наш Git просто дает нам следующее:

error: src refspec main does not match any

Сообщение об ошибке.

Чтобы исправить это, мы можем либо git push origin master — который отправляет наши коммиты, а затем просит GitHub создать новую ветку в репозитории GitHub с именем этой ветки master, либо переименовать наш master на любое имя, которое мы хотели, а затем используйте это имя:

git branch -m master xyzzy
git push -u origin xyzzy

Сделает (единственное) имя ветки, которое мы оба используем, xyzzy. Если вы хотите, чтобы здесь main, переименуйте свой master в main.

Что, если вы случайно создали обе ветки?

Предположим, мы использовали GitHub для создания нового репозитория с новым именем ветки по умолчанию main, которое включает одну начальную фиксацию с обычными файлами README и LICENSE. Затем, не задумываясь, мы использовали git init на нашей собственной машине для создания нашего собственного нового репозитория с именем ветки по умолчанию master, и мы сделали пару коммитов на нашем master .

Если мы теперь переименуем наш master в main:

git branch -m master main

А затем попробуйте нажать:

git push -u origin main

Мы получаем другую ошибку:

 ! [rejected]        main -> main (non-fast-forward)

Причина этого достаточно проста: У них есть фиксация, которую они находят, используя свое имя main, которой у нас нет. Если они изменят свое имя main, чтобы найти последнюю отправляемую им фиксацию, они потеряют сделанную ими начальную фиксацию с помощью README и ЛИЦЕНЗИОННЫЕ файлы.

Здесь у вас есть несколько вариантов:

  • Вы можете игнорировать сделанную ими первоначальную фиксацию. В конце концов, это всего лишь шаблонный коммит. Вы можете сказать им, чтобы они выбросили его полностью. Используйте git push --force, как указано в любом из многих существующих ответов StackOverflow.

  • Вы можете получить их начальную фиксацию и перебазировать свои коммиты по этим коммитам. Это может быть немного сложно, потому что ваша первая фиксация — это корневой коммит . Если ваша первая фиксация содержит файлы README и / или LICENSE, вы получите здесь конфликт добавления / добавления. В этом случае, вероятно, проще просто нажать принудительно.

  • Вы можете получить их начальную фиксацию и объединить свои коммиты. В современном Git для этого требуется использовать параметр --allow-unrelated-histories. Как и в случае с методом rebase, если ваши коммиты содержат файлы README и / или LICENSE, вы получите конфликты добавления / добавления. В результирующем репозитории также будет два корневых коммита. Ни одна из этих проблем не является серьезной, но может немного раздражать.

Чтобы получить их фиксацию, просто запустите git fetch origin. Это получит первую фиксацию GitHub и будет использовать имя origin/main в вашем собственном репозитории Git, чтобы запомнить его. Затем вы можете:

git rebase origin/main

Или же:

git merge --allow-unrelated-histories origin/main

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


2

torek
7 Дек 2020 в 03:20

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Error unable to request shsh что это 3utools
  • Error sparse file not allowed ubuntu
  • Error unable to read askpass response from
  • Error source net sqlclient data provider
  • Error unable to perform an operation on node rabbitmq

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии