I've a projectA repository which has master branch and other feature branches gets merged into the master branch with pull requests.
Now, we're going to start a new projectB which will have everything as same as projectA with few features turned off and will have few new features that are not needed in projectA. Two different teams will be working on projectA and on projectB. If something gets added in projectA then projectB also needs to be updated with latest changes.
I do not want to create separate repositories for projectA and for projectB. How do I manage these 2 projects under one repository? Should I create two branches projectA and projectB from the master branch?
The way most people do this type of thing is with two separate repositories, but I do not particularly like the proliferation of repositories, no matter how popular it is.
The second most popular option would be to use two branches. It does involve some bureaucracy every time you make a change to one branch and want to apply the same change to the other branch, but that's the type of thing that git was made for. (I believe you will find the cherry-picking option quite useful.)
A rather unpopular and possibly blasphemous option would be to keep both projects in the same repository, just in separate subdirectories. (That's the option likely to be chosen by people who are more familiar with SVN, or who appreciate SVN's simplicity over git's ability to do everything but with a huge complexity cost.) Of course if you follow that approach then each time you want to cross-apply a change you will have to do it manually.