Станислав Макаров

Какая разница с какого аккаунта вы делаете пуш? Вы можете закоммитить от одного пользователя, а запушить совершенно от другого. Собственно при коммите вы указываете почту и своё имя (можно даже отдельно указать имя и почту автора от имени и почты коммитера), а как эти почта связаны с акком на гитхабе, это вы настраиваете на самом гитхабе. При пуше вы аутентифицируетесь в гитхабе, поэтому и указываете акк гитхаба. Но запушить вы можете коммиты хоть с сотней разных почт/имён.

оно ведь мне не даст запушить, или что?

или --force

Откройте панель управления, в поиске введите Credential Manager (не помню точно как в русском интерфейсе, кажется Диспетчер учётных данных), откройте первое окно в результатах поиска, там выберите вкладку Windows Credentials, и поищите в этом окне креды, которые вы ввели. Найденное - удалите. И затем попробуйте ещё раз склонировать, пароль должен запроситься ещё раз.

было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

Вам нужно решить, где чья ответственность. В большой команде не может каждый разработчик читать код каждого другого разработчика. Поэтому нужно просто делать адекватные коммиты/мелкие ПР и ревьюить их, а если они уже поревьюены - то не обращать на них внимания, т.к. это теперь не ваша ответственность.

Почему вы повторно ревьюите этот же код, ещё и теперь объединённый в один большой ПР? Какой смысл? У вас что-то не так с организацией ответственности.

Git-сервер не принимает ваш бранч. Там выше не написано, почему это происходит? Может быть Heroku пытается выполнить деплой, но у него не удаётся это сделать, и он отфутболивает бранч?

Поищите логи какие-то деплойские чтоли, а лучше это всё текстом, а не фотографией.

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

Git LFS?

Не исходный же код у вас 50 гигов весит, не так ли?

Передавать эту информацию через переменную окружения? И подставлять вручную/иными способами при сборке вне СКВ?

Считаю, что номер ревизии (т.е. хэш коммита/имя тэга и пр.) должны извлекаться не сборочным скриптом, а передаваться через окружение. Большинство CI-серверов имеют хорошо документированные переменные окружения, которые задаются перед началом сборки. Эти же переменные окружения можно задать и вручную.

https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%...
См. "Ссылки на предков".

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

Или я что то не правильно понял?

Да, вы не понимаете сути слияния веток в Git.

Начнём с того, что когда вы сливаете ветки, по большому счёту не так уж важно какую ветку в какую вы будете сливать. Вы В ЛЮБОМ случае создаёте мёрж-коммит, и создание этого мёрж-коммита (и соответственно разрешение конфликтов которое происходит при создании этого коммита) подразумевает, что вы соединили вместе две ветки. Это значит что начиная с мёрж-коммита все последующие коммиты (дочерние к нему) будут иметь изменения из ОБОИХ веток. Уже не будет разницы между тем что было сделано в первой и во второй ветке, отныне "они едины" (c).

Другой вопрос в том, в какую ветку поместить этот мёрж-коммит и УКАЗАТЕЛЬ какой из веток СДВИНУТЬ на новый мёрж-коммит. Теоретически, мы можем сдвинуть оба указателя, но в большинстве случаев нам достаточно сдвига лишь в одной ветке (и нередко только в одной из веток, в вашем случае f1, мы имеем право двигать указатель).

Когда вы попытаетесь сделать "обратное сливание f1 в develop", если в develop ещё не успело появиться новых коммитов (не являющихся предками созданного вами мёрж-коммита), то на самом деле никакого сливания и НЕ БУДЕТ. Ведь у вас УЖЕ есть коммит, учитывающий изменения в ОБОИХ ветках. Достаточно лишь передвинуть указатель ветки develop на этот коммит. Другое дело, что решение о том, что это можно и нужно сделать, приняв тем самым изменения в ветке f1 в ветку develop, принимает мейнтенер ветки develop, а это вовсе не обязательно тот же человек, что и работающий с веткой f1.

Почему мы сначала сдвигаем указатель ветки f1? Ну очевидно потому, что это ветка в которой ведётся разработка, и обычно принято принимать в общую ветку (коей видимо у вас является develop) уже полностью готовые правки. Готовые - это в том числе интегрированные с текущим состоянием кодовой базы. Обычно это задача работающего в ветке f1 - порезолвить все конфликты и интегрироваться со свежим состоянием develop, чтобы мейнтейнер проекта мог максимально быстро и безболезненно вмёржить f1 в develop.

Формальный (потенциальный) конфликт в Git в контексте слияния веток - ситуация, возникающая при создании коммита слияния (merge commit), когда один и тот же файл (один или более) имеет различное состояние в снимках (snapshots) сливаемых веток. Такие конфликты можно классифицировать на разрешаемые автоматически и не разрешаемые автоматически.

Конфликт, разрешаемый автоматически - формальный конфликт, при котором Git может самостоятельно сформировать снимок для коммита слияния путём применения алгоритма слияния (например, трёхстороннего слияния) согласно выбранной стратегии слияния к каждому из конфликтующих файлов.

Конфликт, не разрешамый автоматически - формальный конфликт, при котором Git не может самостоятельно сформировать снимок для коммита слияния. Обычно именно такие автоматически неразрешаемые конфликты и называют просто конфликтами. В таком случае для формирования снимка требуется ручное вмешательство (что и называется "разрешением конфликтов" в бытовом смысле).