I find this is a big weakness while I try to interview and move up the corporate ladder. I recently bombed an interview because I did not know how to answer questions like "What is the typical workflow for a pull request?" or "How would you begin work on a ticket assigned to you?"
I think these are dumb questions, but it doesn't change the fact I found my foot in my mouth. Does anyone know good resources to learn these bigger-picture concepts and processes?
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.