Suppose I am logging into Gmail by giving my credentials. Does my plaintext get encrypted or is it first converted to the hash and the hash encrypted?
And also if I am communicating to the bank web server and I am doing transactions, is the bunch of packets first converted to a hash and then the hash is encrypted, or is the plaintext of the packets encrypted?
If you connect to the server via TLS, then all your communication, including your credentials, will be encrypted.
Once the server has received them, the server will decrypt your credentials, then hash them, and then compare that hash to what is stored on the server. If it matches, you will receive some authentication token to indicate you are authenticated. If it does not match, you will receive an error.
In typical setups, clients will always encrypt the plaintext password (usually relying on TLS or something similar) and then send it onto the server. In some cases, application level encryption may be employed, but rarely is a password hashed client side.
Modern implementations, salt the passwords before hashing them. Hence server need the plaintext passwords to salt before hashing. If the client-side hashes the password, there's no way the server can salt it and compare.
Sometimes, there's an encryption at the javascript level, hence the server needs to decrypt the line encryption (TLS), and then perform a separate application level encryption to obtain the plaintext password, which then can be salted, hashed and compared.
I've seen scenarios where clients send a hash, and servers perform a hash (of a hash) -- but this is atypical.
So to answer your question -- it really depends on the implementation. But generally speaking, we always encrypt the plaintext, send it to the server, and have the server performs the hash, and compare it to the database.
There's a clear reason WHY the credentials MUST NOT be hashed client-side, before sending them to the server: otherwise the hash itself becomes the password, and a leaked hash list can directly be used for logins. Therefore, the communication between the client and the server is encrypted altogether.
TLS doesn't care about the contents: whatever is done with the password happens on application layer, while TLS takes care of encrypting the connection. The TLS doesn't only provide privacy, but also authentication of the communication parties (so that e.g. you won't send the password to someone else) and integrity to make sure that your requests nor server responses aren't modified during transport.
Suppose I am logging into Gmail by giving my credentials. Does my plaintext get encrypted or is it first converted to the hash and the hash encrypted?
And also if I am communicating to the bank web server and I am doing transactions, is the bunch of packets first converted to a hash and then the hash is encrypted, or is the plaintext of the packets encrypted?
You have a great deal of misunderstanding. I can almost reverse engineer how concepts you have heard about, but did not understand, got mish mashed in your head into such a mess. There is no good way to answer your question except by finding out everything that you know wrong or just don't know and then explaining it. You should start with wikipedia.
You should read about the concept of layers in networking stacks, and how the technology that powers the web is layered.
You should read about how TLS works, at a high level, as a tunnel, and how TLS is used for all sort of things not just HTTPS and not just by browsers.
You should read a little about what modern browsers do with web pages loaded over https differently than with pages loaded over http, which is a separate thing from what TLS is, and is a thing that browsers try to do to make the web safer, and how limited they are because of ossification and backwards compatibility concerns.
For example, if you don't fully understand the following, keep reading wikipedia and stack exchange answers: Web forms submit data using HTTP POST requests. They don't know whether the textbox is type "password" or type "text". They don't know whether the form was loaded over http or https, whether there is js code loaded over http running in the same origin, whether the data is submitted over http or https, etc. Some user agent user interface (like "don't submit passwords over http" interacts with the page, but again, layering, what the User Agent does, etc.).
You should read what cryptographic hashing is, and how hashing is irreversible, etc.
You should read about password based key derivation functions and password storage. You might want to read about PAKEs and augmented PAKEs and how they are very rarely used.
In very short, pages loaded over https keep the conversation between you and the server private from and not changed by the coffee shop WiFi. The green lock icon (if present) does not mean anything about whether you should trust the server or not.
gmail and your bank see the plaintext of your password. They can store the plaintext of your password and can leak it, if they are incompetent.
In practice, gmail is competent enough to store your password securely, so they themselves don't know your password, don't store it, don't log it, can't tell you what it is, etc.
Banks are another deal. Some are competent, some are not. Unless they reveal to you that they know your password, you can't know whether they store it securely or not.
