gitflow VS GitExtensions

1. GitFlow

Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.

Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.

https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow

It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:

[1] https://github.com/nvie/gitflow

[2] https://github.com/datasift/gitflow

[3] https://github.com/wpsharks/hubflow?tab=readme-ov-file

https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices.

The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ;

>> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/

SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain.

jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj

"Ask HN: Best Git workflow for small teams" (2016)

A successful Git branching model - известная модель ветвления от Vincent Driessen.

Before embarking on the project, we needed to decide on our Git workflow. Having experienced the unnecessary indirection and bureaucracy of Gitflow, I immediately proposed and implemented a trunk-based strategy instead.

As a best practice, consider creating a dev branch where you can stage your code and collaborate with other developers on your team. Alternatively, you can follow the Trunk-based development branching strategy. For larger teams and complex deployment cycles, the Gitflow branching model might be more suitable.

Note - this IS NOT Git Flow, which is way too complicated for what we're doing. Even the person who created Git Flow has some warnings and thoughts about it, 10 years later (https://nvie.com/posts/a-successful-git-branching-model/).

just use Gitflow

Git and this: https://nvie.com/posts/a-successful-git-branching-model/

I agree that git is almost asking you to juggle commits.

My preference is to use temporary branches and cherry-picking instead of stashing; I mostly use a gui* to work with git so it is easy to select the two or three commits to cherry-picking or see visually if an interactive rebase would work.

* https://gitextensions.github.io/

I use Git Extensions myself as I find the git interface very straight forward, however they still have this fucking insane and frustrating issue: In the mergetool "Theirs" and "Mine" are swapped

Git Extensions is a more-intuitive way to manage your Git repositories in Windows. Its standalone interface serves as an effective, CLI-free means to control Git. Preferred by namtab00, because "SourceTree hides and shortcuts too much git functionality."

I presume this is where one goes to make a feature request? https://github.com/gitextensions/gitextensions/issues

If you're on Windows, I'd start with installing official Git. It comes with a Git Bash CLI and what not. There are also third party apps like GitExtensions and TortoiseGit if you want more UI/shell integration.

Everyone's going to downvote this, but I prefer the GUI over the command-line. I use http://gitextensions.github.io/

https://github.com/gitextensions/gitextensions/releases/tag/v2.51.05 - nice little ui for working with git. unfortunately, v2.51.05 is the last version that I can confirm works under mono (it was the last 2.x version and they completely rewrote the code from scratch in the 3.x series. My understanding was that it lost Linux compatibility at that point).