Workflow for features with Git

Hi, I'm just starting using features and this is a really great tool to do coordinating work with others.
Here's the features' workflow with git.
From start, work-flow-1:

1. Create a views called "views-X" locally, create a feature called "features-A" to contain "views-X".
2. Download the tar file of "features-A" to modules folder(sites/all/modules/custom/features), enable this feature. Why enable it as there's already a views called "views-X" existing in local machine? Because "views-x" maybe changed in the future through views UI, and the "feature-A"(if it's enabled) will be able to check the changes.
3. Git commit "feature-A", and git push. Go to remote server, enable "feature-A". That's it, "views-X" will be available in remote server.

Then, we did some changes to "features-A" components, like adding another views called "views-Y" to this feature, or adding different displays to "views-X". Here's the work-flow-2:

1. Make changes to "features-A" components locally(only make changes to "views-A"). State of "features-A" will be changed from 'default' to 'Overridden'. Database configuration overrides "features-A" file code.
2. drush features-update features-A. Update "features-A" to match up the configuration in database. This will create a new "features-A" folder matching current database configuration to replace the original one.
3. Git commit and push. Now, the "features-A" module folder in remote server will be replaced by the local updated one. And state of "features-A" in remote server will be changed from "default" to "overridden". In remote server, database configuration overrides "features-A" file code.
4. In remote server ,drush features-revert features-A. This will change the database configuration get updated to match uo the new features file code. Then we can see the changes about "views-X" in remote server now.

I'm not sure about work-flow-2 in step 4? Do we really need to do "drush features-revert features-A" in remote server to make "views-X" in remote server get updated? Some experience told me it's not necessary. Is that true?

Here's another case. We already have a views called "views-Z" in remote server and local machine. Now we need to update "views-Z", like adding some displays to it. Note, there's not a features associated with this views. Work-flow-3 comes:

1. Update "views-Z" locally, add 5 displays in "views-Z".
2. Create a features called "features-B" to contain "views-Z". The state of "features-B" is default.
3. Git commit and push "features-B" to remote server. When I were doing this, the state of "features-B" in remote server is overridden, even this feature is a new feature in remote server. I checked the diff page for "features-B". The default state seems to be the code I just commited, while the overrides code seems to be the code of default "views-Z" in remote server. So, default database configuration overrides "features-B" module file code.
4. In remote server, do drush features-update/revert features-B. I think it should be features-revert, not features-update. But my colleague helped me with drush features-updated to get remote "views-Z" updated. Or there was something else we didn't notice.

So, is this work-flow-3 right, especially step4? It took me a lot of time to figure out why this new features "features-B" has a state 'overridden'.
If I don't use dursh features-update features-B, "views-Z" never get updated in reomte server. I'm not sure what happed here. Command drush features-update should make features code in file system get updated to match up database configuration, not make database configuration get updated to match up features file code.
We did try many ways to get "views-Z" get updated in remote server. Perhaps we have done something else to make it happen, but we were not aware of that.

This post sounds like rambling, sorry to disturb you. But any help will be appreciated!! Thank you.