Support for production branch and merge single commits in GIT?

Question

git

Hello!
Our team is a bit forced to move to Git with SVN (“thank you” Atlassian!). In general, we figured out everything in the migration process and will continue working in Git from Monday. But, as usual, there is one caveat.
In SVN, we had an almost production version in the trunk. The development of features was carried out in separate branches (branches) and after testing they were integrated into the trunk, most of the errors were corrected in 1-2 commits in the trunk (except for non-trivial ones). Bug fixes were checked based on trunk builds. We also had an industrial branch, spun off from the trunk, into which bug fixes and features were merged as they were ready and matured in the trunk. As a rule, bug fixes were merged within 0-2 days, features were usually defended longer, up to a week, in order to identify all sorts of integration points.
Perhaps this was due to the selective merge of commits from the trunk to the production branch. In TortoiseSVN, it was easy to see unfrozen commits, select ready ones and freeze. Naturally, we tried to preserve the natural order as much as possible, but this is not always possible and appropriate.
The problem is that there is no inherently normal mechanism in Git for doing this production branch. A simple merge or rebase merges all the commits. This is ideal for features, but not for maintaining a production branch where injections of selective commits are needed. Of course, there is git cherry-pick, but it seems that this is a second-rate mechanism. There is not a lot of information on it and I have not seen it mentioned anywhere in various popular tutorials.
What are your thoughts on this matter? Please comment only on the essence, we are not ready to change the strategy of working with branches on the go.

Answer 1

Please comment only on the essence, we are not ready to change the strategy of working with branches on the go.

With such an ending, I advise you to stay on SVN (change the host).

Answer 2

The usual strategy is: "one feature - one branch." Well, or group them with meaningful blocks that are deployed at the same time.
Another common strategy is "infrequent deployments". Those. we write everything in a branch of maidens, or in several. We measure as necessary, test, etc. and let's say once a week we merge all this into the master, migrate the base, etc. If the history of commits is kept more or less accurately, if necessary, cleaned up on the local repository, then there are almost no situations when you need to postpone something in the middle. And the little things can be corrected with standard means.
Here's a bit on reordering commits. Maybe you can come up with something more convenient for you.
git-scm.com/book/ru/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82 %D1%8B-Git-%D0%9F%D0%B5%D1%80%D0%B5%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0 %B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8

Answer 3

Make a production branch, or master, well, or trunk then :)

Answer 4

Look towards Mercurial. In my opinion, it is more convenient than Git and allows you to do exactly what you want.
For hosting, you can use bitbucket.org, as a client I advise TortoiseHg, because the client from Atlasian IMHO is unfinished.
However, be prepared for common non-obvious problems.