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

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

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

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

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

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

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

1. В теории реализация не обязана использовать стек для хранения локальных объектов value-типов (см. https://blogs.msdn.microsoft.com/ericlippert/2009/... ).
2. Тем не менее, в текущих реализациях используется именно стек, поэтому всё как и в остальных языках: https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D... .
3. Помните, что значения value-типов иногда (не всегда) хранятся на стеке. Все значения value-типов, являющиеся частью объекта ссылочного типа (например, int-поле в классе или элементы массива double) рождаются и умирают вместе с этим объектом.

Итого:

• время жизни локальных объектов value-типов связывается с фреймом стека;
  
• время жизни объектов value-типов, находящихся в составе объектов reference-типов, связывается с временем жизни объемлющего объекта;
  

Более экзотические ситуации рассматривать не будем. И вообще, как говорит Липперт (см. ссылку), лучше не думать в терминах стека, т.к. это деталь реализации. Лучше говорить о времени жизни относительно вызываемых функций и относительно других объектов.

Но мне нужно докерезировать обычное Десктопное консольное приложение с .net framework 3.5+

На Windows 7, очевидно, докер будет работать только благодаря линуксовой виртуалке (кажется в VirtualBox-e). Т.к. .NET Framework никогда не работал и скорее всего не будет работать под Linux (в отличие например от Mono или .NET Core), вы не добьётесь своей цели с использованием имеющихся инструментов.

Вам как минимум нужны нативные контейнеры (Windows Containers), доступные в Windows 10 и Windows Server 2016.

Вот кстати неплохой пример, как раз консольное приложение: https://github.com/Microsoft/dotnet-framework-dock... . Цитаты из него:

To complete this sample you must have Windows 10 (or Windows Server 2016), Docker for Windows, Visual Studio, and Git installed.

You must use Windows Containers on Docker for Windows to run this image. Be sure to check that you are properly switched to Windows Containers. Do this by opening the system tray up arrow and right clicking on the Docker whale icon for a popup menu. In the popup menu make sure you select 'Switch to Windows Containers'.

1. Берёте https://github.com/jsoverson/preprocess .
2. Ищите лоадер для вашей системы сборки (мы используем с вебпаком).
3. Профит.

WPF умер. C# на клиенте тоже умер. C++ и Qt на клиенте умер. Нативные приложения и приближенные к ним (WPF/WinForms) вообще умерли. Нативные приложения пишут только разработчики ОС, и то до тех пор пока не перепишут их на Электроне. Электрон скоро будет модулем ядра / драйвером для повышения производительности HTML-интерфейсов.

Просыпаюсь в холодном поту
Фух, это всего лишь сон.

то используй DevExpress, а не WPF

Это как понимать? Я знаю что у DevExpress есть наборы компонентов для разных UI-технологий, а чтобы у них было своё UI-решение, не базирующееся на чём-то вроде WPF/WinForms/HTML - не слышал.

используй ASP.NET MVC, а не Silverlight

Т.е. генерировать только статический UI только на сервере? Почему вы сравниваете Silverlight (который кстати и правда умер, уже точно) с ASP.NET MVC, а не с HTML или HTML + React например?

Та сущность, по которой пробегают, должна реализовывать IEnumerable.
Та сущность, которая пробегает, должна реализовывать IEnumerator (обычно это вложенный, нередко приватно объявленный класс).

То что вы сказали я к сожалению не понял.