Cant finish github sharing process что делать

Как опубликовать проект на Github

Если вы не хотите потерять ваш проект и сохранить его на будущее, то удобно опубликовать его на GitHub.

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

И т.к. вы представляете проект на конференции — то вам надо это сделать и добавить ссылку в конце презентации.

Регистрируетесь

Публикуете проект

1) Открываете проект в IDEA

2) Жмете сверху VCS -> Import into Version Control -> Share project on GitHub (или Git -> Github -> Share project on GitHub)

Repository name: AngryBirds Private: не ставить галочку (если поставить, то репозиторий будет виден только вам) Remote: origin Description: Игра про стрельбу птицами по свиньям написаная на Java Swing.

3.5) Если при логине вы получаете ошибку “Invalid authentication data. 404 Not Found — Not Found”, то попробуйте:

в окне логина сверху справа Use Token, затем Generate — Ok на странице github (для создания токена для логина)
скопируйте токент (длинная строка)
вставьте его в поле в IDEA — теперь должно залогинить

4) Если снизу справа появилась ошибка “Can’t finish GitHub sharing process … initial push failed”, то:

5) VCS -> Git -> Remotes

6) Нажмите справа на карандашик и замените URL на https://USERNAME:PASSWORD@github.com/USERNAME/REPOSITORYNAME.git (поправив USERNAME, PASSWORD и REPOSITORYNAME)

7) Теперь сделайте push еще раз: VCS -> Git -> Push… -> Push

Сохраняйте в репозитории новые изменения (коммитьте их)

2) Жмите не на Commit , а на стеролчку справа и там — Commit and Push.

3) Если вы все же сделали обычный Commit , то просто выполните еще и это: VCS -> Git -> Push… -> Push

Чтобы посмотреть изменения которые вы ранее делали

1) Снизу слева жмете “9: Version Control”

2) Чуть повыше жмете Log (правее от Version Control: Local Changes Console)

3) Можете выбрать любой коммит, справа выбрать файл и нажав на него правой кнопкой и там Show Diff — увидите изменения в файле

А чтобы посмотреть какие локальные изменения вы сделали до сих пор — вместо Log вам нужно нажать на Local Changes

Убедитесь что вы не забыли закоммитить в том числе картинки

Если у вас есть картинки в проекте, то стоит их тоже закоммитить. Например можете рядом с папкой src создать папку data и складировать всё туда.

Чтобы было проще запускать ваш проект на другом компьютере или через миллион лет найдя репозиторий — как минимум измените пути картинок на относительные (т.е. с C:\\Users\\. \\image.png на data\\image.png ) и при запуске игры в идее убедитесь что в Run -> Edit Configurations. в запускаемом вами файле указана Working directory: равная пути к папке с вашим проектом, т.е. чтобы относительно этой рабочей папки ( Working directory: ) картинки действительно были доступны по пути data\image.png .

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

Сделайте описание вашего проекта

Чтобы сделать описание вашего проекта например в таком стиле — после публикации и изначального push -а:

1) Откройте ваш репозиторий на GitHub.com в браузере

2) Проверьте что вы залогинились

3) Нажмите сверху и немного правее чем исходные файлы кнопку Create new file (левее зеленой кнопки Clone or download )

4) Укажите названием файла README.md и обратите внимание что по мере редактирования файла вы можете посмотреть как он выглядит — достаточно переключиться на Preview , а потом обратно на Edit new file

5) Этот файл можно писать на языке разметки Markdown, что-то о нем можно почитать тут — Mastering Markdown.

Как вариант вам предлагается воспользоваться таким шаблоном:

# AngryBirds — большие буквы отделенные чертой от последующего текста
![Титульный скриншот или например иконка](/screenshots/screenshot1.png) — картинка из вашего репозиторий лежащяя по пути screenshots/screenshot1.png (текст в квадратных скобочках — описание которое появится если картинка не прогрузится)
**W** — сделает текст внутри звездочек выделенным
[Intellij IDEA](https://www.jetbrains.com/idea/) — ссылка ведущая на указанный адрес в интернете, но показанная как синяя надпись с текстом из квадратных скобок

# AngryBirds ![Титульный скриншот или например иконка](/screenshots/screenshot1.png) Игра про стрельбу птицами по свиньям с двухмерной физикой на базе Java Swing. # Управление 1. **W**, **A**, **S**, **D** - двигать что-нибудь ввеох, влево, вниз и вправо соответственно 2. **ПРОБЕЛ** - запустить крутой фейерверк 3. Проведя мышкой с зажатой левой кнопкой можно оттянуть птицу и отпустив левую кнопку - выстрелить # Как поиграть - Либо скачать ```.jar```-файл последней версии со [страницы](https://github.com/USERNAME/REPOSITORYNAME/releases) с опубликованными релизами - Либо открыть проект в [Intellij IDEA](https://www.jetbrains.com/idea/) # Скриншоты ![Скриншот основного геймплея](/screenshots/screenshot2.png) ![Скриншот основного геймплея](/screenshots/screenshot3.png) ![Скриншот меню](/screenshots/screenshot4.png) А это скриншот баги которая мне так понравилась, что теперь это фича: ![Скриншот неприятной баги которую я не знаю как поправить, поэтому притворюсь что так и задумано](/screenshots/screenshot5.png)

Как скомпилировать проект в самодостаточный .jar -файл и опубликовать его в папку https://github.com/USERNAME/REPOSITORYNAME/releases — смотрите здесь.

Несколько примеров с неплохим описанием из которых можно вдохновиться хорошими идеями и примерами Markdown-разметки:

https://github.com/wozniakty/PuzzleDash — README.md
https://github.com/RothschildGames/release-cycles — README.md
https://github.com/sdrdis/hotfix — README.md
https://github.com/Nurgak/Cube-engine — README.md
https://github.com/lutzroeder/digger — README.md
https://github.com/hughsk/ludum-dare-27 — README.md

Полярный Николай Вадимович
Моя почта: PolarNick239@gmail.com
+7 (911) 959-11-70
быстро отвечаю в Telegram (ответ может быть в стиле «вечером отвечу»)
можно писать в PolarNick

Как исравить ошибку Phpstorm при расшаривании проекта на github — Successfully created project on GitHub, but initial push failed?

Создал пробный аккаунт в Github, и получилось из Phpstorm создать приватный репозиторий и залить проект. Но!
Решил перекинуть проект на свой рабочий аккаунт github и тут начали возникать сюрпризы:
При расшаривании приватного проекта — проект создается, но не заливается, пишет ошибку:

Can't finish GitHub sharing process Successfully created project 'test-007' on GitHub, but initial push failed: repository 'https://github.com/user-name/test-007.git/' not found

Как это исправить, что делаю не так?

Вопрос задан более трёх лет назад
126 просмотров

Removing sensitive data from a repository

If you commit sensitive data, such as a password or SSH key into a Git repository, you can remove it from the history. To entirely remove unwanted files from a repository’s history you can use either the git filter-repo tool or the BFG Repo-Cleaner open source tool.

The git filter-repo tool and the BFG Repo-Cleaner rewrite your repository’s history, which changes the SHAs for existing commits that you alter and any dependent commits. Changed commit SHAs may affect open pull requests in your repository. We recommend merging or closing all open pull requests before removing files from your repository.

You can remove the file from the latest commit with git rm . For information on removing a file that was added with the latest commit, see «About large files on GitHub.»

Warning: This article tells you how to make commits with sensitive data unreachable from any branches or tags in your repository on GitHub.com. However, those commits may still be accessible in any clones or forks of your repository, directly via their SHA-1 hashes in cached views on GitHub, and through any pull requests that reference them. You cannot remove sensitive data from other users’ clones of your repository, but you can permanently remove cached views and references to the sensitive data in pull requests on GitHub by contacting us through the GitHub Support portal. GitHub Support only assists in the removal of sensitive data in cases where we determine that the risk can’t be mitigated by rotating affected credentials.

Once you have pushed a commit to GitHub, you should consider any sensitive data in the commit compromised. If you have committed a password, you should change it. If you have committed a key, generate a new one. Removing the compromised data doesn’t resolve its initial exposure, especially in existing clones or forks of your repository.

If the commit that introduced the sensitive data exists in any forks of your repository, it will continue to be accessible unless the fork owner also removes the sensitive data from their fork or deletes the fork entirely. You will need to coordinate with the owners of any forks of your repository, asking them to take the appropriate actions. Please note that GitHub cannot provide contact information for these owners.

Consider these limitations and challenges in your decision to rewrite your repository’s history.

Purging a file from your repository’s history

You can purge a file from your repository’s history using either the git filter-repo tool or the BFG Repo-Cleaner open source tool.

Note: If sensitive data is located in a file that’s identified as a binary file, you’ll need to remove the file from the history, as you can’t modify it to remove or replace the data.

Using the BFG

The BFG Repo-Cleaner is a tool that’s built and maintained by the open source community. It provides a faster, simpler alternative to git filter-repo for removing unwanted data.

For example, to remove your file with sensitive data and leave your latest commit untouched, run:

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

To replace all text listed in passwords.txt wherever it can be found in your repository’s history, run:

bfg --replace-text passwords.txt

After the sensitive data is removed, you must force push your changes to GitHub. Force pushing rewrites the repository history, which removes sensitive data from the commit history. If you force push, it may overwrite commits that other people have based their work on.

git push --force

See the BFG Repo-Cleaner’s documentation for full usage and download instructions.

Using git filter-repo

Warning: If you run git filter-repo after stashing changes, you won’t be able to retrieve your changes with other stash commands. Before running git filter-repo , we recommend unstashing any changes you’ve made. To unstash the last set of changes you’ve stashed, run git stash show -p | git apply -R . For more information, see Git Tools — Stashing and Cleaning.

To illustrate how git filter-repo works, we’ll show you how to remove your file with sensitive data from the history of your repository and add it to .gitignore to ensure that it is not accidentally re-committed.

brew install git-filter-repo

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/ > remote: Counting objects: 1301, done. > remote: Compressing objects: 100% (769/769), done. > remote: Total 1301 (delta 724), reused 910 (delta 522) > Receiving objects: 100% (1301/1301), 164.39 KiB, done. > Resolving deltas: 100% (724/724), done.

cd YOUR-REPOSITORY

Force Git to process, but not check out, the entire history of every branch and tag
Remove the specified file, as well as any empty commits generated as a result
Remove some configurations, such as the remote URL, stored in the .git/config file. You may want to back up this file in advance for restoration later.
Overwrite your existing tags

 $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA Parsed 197 commits New history written in 0.11 seconds; now repacking/cleaning. Repacking your repo and cleaning out old unneeded objects Enumerating objects: 210, done. Counting objects: 100% (210/210), done. Delta compression using up to 12 threads Compressing objects: 100% (127/127), done. Writing objects: 100% (210/210), done. Building bitmaps: 100% (48/48), done. Total 210 (delta 98), reused 144 (delta 75), pack-reused 0 Completely finished after 0.64 seconds.

Note: If the file with sensitive data used to exist at any other paths (because it was moved or renamed), you must run this command on those paths, as well.

$ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore $ git add .gitignore $ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore" > [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore > 1 files changed, 1 insertions(+), 0 deletions(-)

git remote add origin https://github.com/OWNER/REPOSITORY.git

$ git push origin --force --all > Counting objects: 1074, done. > Delta compression using 2 threads. > Compressing objects: 100% (677/677), done. > Writing objects: 100% (1058/1058), 148.85 KiB, done. > Total 1058 (delta 590), reused 602 (delta 378) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599. 051452f main -> main (forced update)

$ git push origin --force --tags > Counting objects: 321, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (166/166), done. > Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done. > Total 321 (delta 124), reused 269 (delta 108) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599. 051452f main -> main (forced update)

Fully removing the data from GitHub

After using either the BFG tool or git filter-repo to remove the sensitive data and pushing your changes to GitHub, you must take a few more steps to fully remove the data from GitHub.

Note: GitHub Support won’t remove non-sensitive data, and will only assist in the removal of sensitive data in cases where we determine that the risk can’t be mitigated by rotating affected credentials.

$ git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin $ git reflog expire --expire=now --all $ git gc --prune=now > Counting objects: 2437, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (1378/1378), done. > Writing objects: 100% (2437/2437), done. > Total 2437 (delta 1461), reused 1802 (delta 1048)

Note: You can also achieve this by pushing your filtered history to a new or empty repository and then making a fresh clone from GitHub.

Avoiding accidental commits in the future

Preventing contributors from making accidental commits can help you prevent sensitive information from being exposed. For more information see «Best practices for preventing data leaks in your organization.»

There are a few simple tricks to avoid committing things you don’t want committed:

Use a visual program like GitHub Desktop or gitk to commit changes. Visual programs generally make it easier to see exactly which files will be added, deleted, and modified with each commit.
Avoid the catch-all commands git add . and git commit -a on the command line—use git add filename and git rm filename to individually stage files, instead.
Use git add —interactive to individually review and stage changes within each file.
Use git diff —cached to review the changes that you have staged for commit. This is the exact diff that git commit will produce as long as you don’t use the -a flag.

Fix Can’t finish GitHub sharing process

Иконка канала JavaScript для предпринимателей

Can’t finish GitHub sharing process Successfully created project ‘HatDe_Hello2’ on GitHub, but initial commit failed: *** Please tell me who you are. Run git config —global user.email » you@example.com » git config —global user.name «Your Name» to set your account’s default identity. Omit —global to set the identity only in this repository. fatal: unable to auto-detect email address (got ‘hatde@nguyenductung.(none)’) during executing git «C:\Program Files\Git\cmd\git.exe» -c core.quotepath=false -c log.showSignature=false commit -m «Initial commit» —

Войдите , чтобы оставлять комментарии