Я клонирую свой репозиторий с помощью:
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'
Ответ 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
-
Попробуйте
git show-ref
посмотреть, что у вас есть. Есть лиrefs/heads/master
? -
Вы можете попробовать
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
. Вот все необходимые шаги:
- Создайте пустой репозиторий Git на удаленном компьютере,
- На локальном создании .gitignore
файл для вашего проекта. Github дает вам список примеров здесь -
Запустите терминал, и в вашем проекте выполните следующие команды:
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
- When does git throws error: src refspec master does not match any?
- Scenario 1 – Pushing the changes to master or remote branch
- Solution for error: src refspec master does not match any.
- Scenario 2 – Check if a remote branch exists.
- Scenario 3 – Mismatch in Local and remote branch
- 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.
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.
Describe the bug
When trying to create backup i recieve this error
Relevant errors (if available)
No response
Steps to reproduce
Attempt to push backup
Expected Behavior
No response
Addition context
No response
Operating system
Windows
this should git issue, not related to this plugin, can you push it through cmd?
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>.
@callumgourlay this error usually appears when you don’t stage files for commit. Running the below bash commands should fix the issue:
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.
…
@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.
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.
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.
…
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