Both of those questions are basically the same thing.
The usual workflow goes like this:
1. There's a ticket in Jira or Github. Depending on the team, either someone assigns it to you, or you choose to work on it.
2. You checkout the master branch in git locally, get it up to date with the current version.
3. You do `git checkout -B myName/ticket-7001` (or whatever format your team uses) to make a new git branch.
3. You write the code and tests for the new feature. Depending on the team or your own personal preferences, you may make lots of small commits, or one large one when you are done.
4. You push the branch up to the git server. Then on the git server, you create a pull request, using the branch name and requesting to merge it back to master. Then you give it a title with the feature name and description linking it back to the work ticket.
5. In a good organization, the git server will then run all tests, making sure they pass, and run a variety of linter checks, and code formatting checks. If any of these fail, you'll want to fix them.
6. You'll request that someone else on the team review the PR. This may take a day or two. Depending on the team and how critical the PR is, this may just be a "looks good to me" approval, or dozens of back and forth comments looking to simplify, and speed up, and otherwise improve the code. Eventually the reviewer will approve the PR.
7. You or the reviewer will then merge in the PR. Some teams use squash commits, where the entire PR becomes a single commit at merge time.
Because of the lag waiting on other people to review your code, you'll often be working on multiple PRs at once.
Hope that helps! A lot of how this workflow works is very team specific. I don't know that I'd asked about it in an interview because it's very easy to learn on the job.