How to manage the incomplete features in Azure repos

I'm new to DevOps and want to know how to manage the project in Azure Git repos.

I have chosen the Trunk based branching strategy for the development, where we will have the main branch, feature branches, release branches, and bugfix branches (to fix bugs in the releases).

1. Feature management:

As Continuation integration says we need to commit our changes to the main branch at least once a day so how to manage incomplete feature branches and what are the best practices? 

I'm aware of the feature toggle/flag concept, but Is there any other option than the feature toggle?

2. Release management:

How to create Release branches only with the complete feature if the main branch also contains incomplete features?

Thanks.

You are correct that CI is about merging your branches to your mainline branch at least once a day. Jez Humble created a slightly jokey certification process for CI. You just need to be able to answer yes to 3 questions.

1. Do all developers merge their code to the mainline branch at least once a day?
2. Do you have a process for validating that the merge hasn't broken anything? (build and test)
3. If the merge has broken something, is it fixed or reverted within 10 minutes?

If you can answer yes to all 3 questions then you are doing CI. If you can't answer yes to all 3 then you're doing something, but it isn't CI. Unfortunately tooling vendors have muddied the waters by calling build tools "CI Tools" so a lot of folks think that if they have an automated build then they are doing CI. But that's only relevant to question 2

In addition CD says that your mainline branch should always be releasable. So you should be able to push the code in the mainline to prod at any time, and not worry about it.

This philosophy of keeping the mainline in an always-releasable state is the central tenet of Continuous Delivery. https://martinfowler.com/articles/branching-patterns.html#release-ready-mainline

Which leads us to your question.

The short answer is, you don't use branches to manage feature availability or release management. You use feature toggles! It's a big subject but there are 2 obvious things to focus on.

1. Do you have sufficient test automation to answer question 2 above. I.e if your build passes, are you confident that the code "works"
2. Feature flags / toggles.

There are different types of Feature Toggle and you're need seems to be release toggles. This is a technique where you hide features behind a toggle so that they can be active or dormant depending on the environment.

That way you can have code paths that are only available in development / test environments but that functionality is hidden from the users in production. Once the development of the feature is complete then you can flip the toggle in production and users can now see the new feature.

Essentially what you're trying to do is decouple Deployments and Releases. Where a Deployment is "installing and configuring software" and a Release is "Making new functionality available to customers, including potentially spending a bunch of money of Marketing"

In very very basic terms you're sticking your new feature behind an "if" statement and pulling in a value of true or false from an external datastore of some kind which can be updated without the need for a deployment. For release toggles, these if statements tend to be transitory, so once the feature is released you need to go and clean up the code.

Other types of toggle might be longer lived. you might have a toggle thats based on "is the customer paying me extra money" in which case that toggle will exist until the feature is retired or becomes part of the base product.

There are some tools which can help with Feature toggles. Launch Darkly is quite popular for example.

AS I said, it's quite a broad topic, but most teams I've worked with have found that it's worth the investment as it can simplify the branching strategy significantly and give them a safety net when experimenting with new functionality.