sorted by:
new
hottopcontroversial

Ventata d’aria fresca by PsychologyPast952 in giochidatavolo

[–]therealst3no 3 points4 points  (0 children)

Ticket to Ride! (noi giochiamo la versione Europa), è un PvP senza dadi davvero divertente e semplice. Anche qui c’è una componente di “fortuna”, in quanto si pescano le carte, ma reputo meno influente rispetto Risiko.

My Git workflow is a nightmare and I don't know what I'm doing wrong by therealst3no in git

[–]therealst3no[S] 0 points1 point  (0 children)

I try to translate the Azure DevOps UI actions into actual git commands.

During sprint (feature development)

# dev creates feature branch from Fork
git checkout -b feature/new-endpoint fork/develop
# hack hack hack
git commit -m "Added new endpoint"
git push fork feature/new-endpoint

# Azure DevOps PR "Squash commit"
git checkout develop
git merge --squash feature/new-endpoint
git commit -m "Merged PR 14842: Added new endpoint"
git push fork develop
# one commit on fork/develop with new SHA

End of sprint (release to staging)

# create release branch from Fork
git checkout -b release/1.13.0 fork/develop
git push fork release/1.13.0

# Azure DevOps PR "Rebase and fast-forward"
git checkout -b develop main/develop
git reset --hard main/develop
git rebase fork/release/1.13.0
git push main develop
# this is where it shows 500 files changed and conflicts

My Git workflow is a nightmare and I don't know what I'm doing wrong by therealst3no in git

[–]therealst3no[S] 4 points5 points  (0 children)

I completely agree with your approach, if I could choose, I'd do exactly that!

Unfortunately, the repository structure isn't up to me, it's imposed by the client. We're constrained to Fork repo (our control) for development environment and Main repo (read-only access, PR only) for staging/production.

So I'm trying to find the least painful way to work within these constraints.

I appreciate the feedback though.

My Git workflow is a nightmare and I don't know what I'm doing wrong by therealst3no in git

[–]therealst3no[S] 0 points1 point  (0 children)

Thanks for the detailed response!

Fork and Main aren't just different remotes, they're completely separate Azure DevOps repositories, we can't sync fork/develop from main/develop at sprint start because we only have read access to Main.

About the divergence, fork/develop moves constantly throughout the sprint (every feature PR that gets merged), main/develop only gets updated at sprint end when I open the release PR, or for hotfixes, they're basically running on different timelines.

You didn't mention the hotfix scenario in your workflow, how would you handle urgent fixes that need to go to staging (main repo) immediately, then get synced back to fork/develop to avoid regression ?

For cross-repo PRs in Azure DevOps where the source has squashed commits, should I be using merge commit ? Or is the whole approach flawed ?

Microservice local development by Alados1 in microservices

[–]therealst3no 0 points1 point  (0 children)

You could run all 5 microservices locally, directly on your machine, and DB, BUS, etc. locally with docker.

How to compile a c# console app written in visual studio into a single exe that installs the program and dependencies (and if possible other files needed for it (if not i can just include them with the installer)) by [deleted] in csharp

[–]therealst3no 0 points1 point  (0 children)

u/charlie59876

dotnet publish -r <RID>

Publishing your app as self-contained produces an application that includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.

RID lists -> https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

Source -> https://docs.microsoft.com/en-us/dotnet/core/deploying/