Сергей Кузнецов

Ох уж эти трудности перевода)) remote обычно переводят на русский как удалённый. Но что если я захочу удалить remote? Удалить удалённый?
Поэтому лучше говорить «внешний», чтобы не путаться. Мы работаем с локальным репозиторием, а все остальные по отношению к нему будут внешними. В Git нет централизации, все репозитории равноправны и могут обмениваться информацией в произвольных направлениях.

Итак: у нас есть два внешних репозитория и хочется их синхронизировать? Без проблем.
Можно использовать локальный компьютер как вспомогательный.

Я сделал
git init
git remote add origin ....

Начало уже нелогичное. Ты же говоришь что уже выкачал репозиторий с сервера?
Т. е. выполнил git clone <server1>
Это уже создало копию репозитория и init не нужен. А ещё это автоматически создало ссылку origin тоже.

Дальше можно поменять адрес origin на второй сервер
git remote set-url origin <server2>

И сразу увидим в git status есть ли отличия.
Хотя нет, вру. Надо после смены адреса скачать к себе заново внешние ветки командой
git fetch
Только тогда будет что сравнивать.

Примерно так. Это первое что пришло в голову и пожалуй грубовато. Можно придумать более аккуратную схему.

Я бы лучше не удалял старый remote, а добавил новый. То что ты «скачал с сервера» пусть так и останется как origin. А «удалённый» репозиторий обозначим как upstream

git remote add upstream <server2>
git fetch upstream

Тогда мы сможем сравнивать любые ветки и синхронизировать.

Как форматировать .GITIGNORE для GITHUB?

Правильный ответ на поставленный вопрос — никак.
Файл .gitignore не используется в сервисе GitHub.

Но после публикации Release
Каждый раз в архиве пакета находятся все файлы из этого репозитория.

А ты ожидал чего-то другого? Что ты поместил в ветку, то и увидишь в релизе.
Добавление масок файлов в .gitignore не удаляет никакие файлы из проекта.
Хочешь удалить файл — удали его непосредственно из ветки репозитория.

Что означают строки с символами <<<<<<< и >>>>>>> в .gitignore?

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

<<<<<<< OURS 
=======
>>>>>>> THEIRS

файл XML должен загружаться по URL но не должен попадать в архив.

Используй для сайта и для архива с релизом разные ветки и будет тебе счастье. По умолчанию сайт GitHub Pages хранится в ветке gh-pages. Зачем ты свалил всё в кучу и используешь ветку master и для сайта и для самого проекта?

Просмотр истории
Если вы укажете каталог или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире (--), чтобы отделить пути от опций:

git log --name-status --graph --oneline --since=4.months -- ToModel*.php

Такие файлы добавляются в .gitignore так же, как и любой другой файл.
Но, подозреваю, что вопрос в другом. Хочется чтобы файлы исчезли из проекта?
Ты видишь, что файл никуда не исчез и сделал вывод, что файл не добавлен в игнор. Но это не так.
По сути .gitignore тебе совершенно не нужен, потому что добавление файла в игнор не удалит его автоматически из репозитория, если он ранее уже был добавлен в отслеживаемые. Этот файл нужен только чтобы случайно не добавить в репозиторий лишнее. Но даже он не помешает нам добавить любой файл в репо командой git add файл

Когда не хочешь видеть файл в репо, просто удали его физически и сделай коммит.

Если же файл нужен в рабочем каталоге, но ты не хочешь его светить в репозитории, то удали файл только из индекса командой git rm --cached имя_файла и закоммить это.

Скорее всего pull предлагает сделать не после push, а после нажатия кнопки синхронизации в VSCode.
До того как собственно сделает сам push, спрашивает «а не хотите ли сначала обновиться?»
Более точный ответ мы увидим в консоли, смотри там что происходит.
Скачивать ветку заново сразу после отправки действительно нет никакого смысла.

Ветки создаются командой: git branch имя
Всё! Никаких коммитов дополнительно создавать не надо. Главное чтобы репозиторий уже содержал хотя-бы один коммит, чтобы веткам было куда указывать (ветка это лишь указатель на коммит).

Push отправляет конечно же не файлы а именно ветки. По умолчанию только одну ветку, которая текущая. Чтобы отправить сразу все, следует его об этом попросить: git push origin --all

Если капитан любит линейную историю то легко можно избавиться от коммита слияния:

git rebase origin/master databаse_branch

Эта команда пересадит ветку databаse_branch на вершину актуальной ветки database, которая судя по всему связана с веткой master в вышестоящем репозитории origin. Коммит слияния исчезнет.

Затем придётся принудительно обновить в вышестоящем репозитории эту ветку:

git push --force

И если кто-то её уже скачивал к себе, то попросить их обновиться через:

git pull databаse_branch --rebase

Как-то так. Я мог не угадать названия веток, так как по скрину не всё видно. Но принцип решения должен сработать.

Это называется перебазирование. Мы пересаживаем одну ветку на вершину другой ветки.
git rebase deps react-app
Но ветка react-app у тебя уже запушена, значит её придётся принудительно обновить во внешнем репозитории.
git push --force
И будь внимателен, если ветку react-app уже кто-то скачал себе, то ты их должен предупредить, чтобы они удалили её у себя и скачали заново. Либо обновили через git pull --rebase

Перед тем как применить новую аутентификацию, удали старую командой:

echo "url=https://github.com" | git credential reject

На твоём скрине я вижу обратное. Не появляются, а наоборот исчезают. И не табуляции, а пробелы.
По умолчанию в редакторах JetBrains удаляются лишние пробелы (trailing spaces) только в изменённых строках. Проверь это у себя в настройках редактора вот тут Editor / General / On Save


Но, по хорошему, надо эти косяки в коде везде поправить.

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

git reset $(git commit-tree HEAD^{tree} -m 'Новое начало истории')

Вторая команда очистит папку .git от мусора:
git gc --prune=now --aggressive

Ну и конечно отправить новое состояние ветки на гитхаб:
git push --force

Если у вас Windows, то работайте в git-bash, а не в стандартной командной строке.

Пароль не запрашивает почему? Потому что он уже сохранён в хранилище паролей.
Что нужно сделать чтобы пароль запросился снова? Нужно старый пароль удалить конечно же!
В разных операционных системах пароли хранятся по-разному и поэтому тебя первым делом попросили показать конфиг git config -l, чтобы уточнить способ очистки.

Но можно попробовать универсальный метод сброса авторизации:

echo "url=https://github.com" | git credential reject

Если теперь снова попробовать git push, то вылезет окошко выбора способа авторизации.

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

Но ты можешь распаковать (checkout) разные ветки в разные каталоги (worktree). И уже для каждого сможешь сделать нужные настройки. Так ты получишь желаемое и пароли не придётся светить в публичном внешнем репозитории.

Pull Request делают только тогда, когда нет прав напрямую коммитить в ветку. В твоей же ситуации это сейчас бесполезная операция. Определись, как будет называться твоя главная ветка. Похоже на гитхабе у тебя основная ветка называется main, а локально ты создал master. Двух мастеров, как ты написал, быть не может. В одном репозитории невозможно создать две ветки с одним именем.

Твоя команда
git push -u origin master
отправляет твою текущую локальную ветку master в такую же ветку master на гитхабе и настраивает связь между ними (ключ -u).
Если ты хочешь отправлять из локальной master в вышестоящий main, то пиши иначе
git push -u origin master:main
После того как связь создана, то дальше можно отправлять короткой командой
git push

Лучше переименовать локальный master чтобы не путаться
git branch -M main

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

А правильней было копировать ТОЛЬКО сам репозиторий на флешку. И не в виде папки, а одним файлом, так надёжнее и быстрее. Для этого даже специально придумали команду git bundle. Затем на новом компьютере распаковываешь файл пакета и восстанавливаешь рабочий каталог.

Сам создал себе проблему на пустом месте, но она легко решаема:

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

Либо если ты нашел другой компьютер с интернетом, то клонируй туда снова свой проект с гитхаба (надеюсь ты не забыл сделать push перед тем как копировать файлы на флешку?) и потом так же очисти рабочий каталог и запиши изменённый проект на это место.

Ты в общих чертах описал рабочий процесс git-flow, но rebase там неуместен, синхронизация делается исключительно через merge, так как ветки master и dev долгоиграющие.
Погугли. На эту тему много хороших статей, но не факт что вашей компании такая модель идеально подойдёт.
Такие вопросы решаются до начала разработки обычно, так как схем ветвления можно придумать много и не существует единственно правильной.

А судя про то, что пишешь про комментирование кода чтобы временно скрыть и про перебазирование для синхронизации — ты похоже не понимаешь зачем нужен и как работает Git.
Почитай документацию или посмотри Git-курс на Ютубе.

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

Тебе надо установить указатель твоей ветки на текущий коммит, на который указывает HEAD
git checkout -B имя_твоей_ветки HEAD
Тут важен регистр опции -B, так как ветка с таким именем уже где-то существует и мы принудительно пересоздаём её на новом месте. А находясь в ветке, мы уже сможем её запушить.

Это называется не добавить, а распаковать ветку в рабочий каталог из локального репозитория (сделать текущей), в который она уже загружена (добавлена) командой fetch.
git checkout -b develop origin/develop --
И всё. После checkout сможешь работать с этой веткой.

Там в меню вашей IDE есть ещё несколько методов откатить изменения.
Это же JetBrains? Все способы подробно описаны в справке, например вот как в IntelliJ IDEA

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

Revert не удаляет коммит, а создаёт новый, который описывает действия необходимые для отмены выбранного коммита.

Undo позволяет отменить последний коммит. Но изменения коммита предлагает сохранить в новый changelist. Файлы в рабочем каталоге не изменятся и можно будет их подправить и заново закоммитить.

Drop — удобная команда для удаления произвольного коммита из середины истории. Под капотом там на самом деле выполняется интерактивный rebase, но в автоматическом режиме.

Revert Selected Changes напоминает Revert, но отменяет изменения отдельного файла, а не всего коммита. Эта команда доступна на Панели изменённых файлов.

Get позволяет вернуть любой файл к состоянию на определённый коммит в истории. Выберем файл любым удобным способом и контекстное меню Git | Show History покажет все коммиты, в которых изменялся данный файл. Кликнув на нужном коммите правой кнопкой увидим команду Get

Show history показывает историю только в пределах конкретной ветки.
Если ты новый коммит не привязал ни к какой ветке, то ты его не увидишь ни в истории, ни в общем журнале коммитов. Не забывай проверять в какой ветке находишься и присваивай цепочке коммитов название ветки если начал строить ответвление не от вершины, а от середины другой ветки. Иначе потеряешь работу и придётся искать эти коммиты через git reflog