Do you want to catch up with the master with git?Should I close the branch every time?

"When I want to reflect the latest status of the master in my branch, is it okay to ""merge the master""?"
Close my branch when master merges my branch and
Should I create a new branch from the master every time I make a new change?

I think that's all right.
It depends on the workflow, but we cut branches by ticket and delete branches after master merge by pull request.

For rebase, please refer to the following URL and understand the nature of git before deciding whether to use it or not.I don't rebase.
(Except pull requests to sources published in GitHub)

Not scary git
rebase merits and demerits

It may depend on the development flow, but

 git checkout master
git pull origin master
git checkout my-branch
git rebase master

This allows you to replace the starting point of my-branch with the latest commit of master.Personally, I like to use rebase because merging normally requires one commit and gets dirty when I look at the logs later.

Also, as stated in the question, I think it would be simpler to recreate the branch life each time. You can delete the branch that has been incorporated into master.

"At this time, when I want to reflect the latest status of the master in my branch, is it okay to ""merge the master""?"
When I actually tried it, the bitbucket pull request says My Branch → master.

I think the merge direction is the opposite. If you want to capture the commit of master, you should be able to synchronize now because the page of the branch you want to import looks like "32 commits behind master. Sync now."

Some people may say that it doesn't matter because we're joining, but internally, we can identify who's the parent, so I think it's less likely to cause problems if we use them separately.

Close my branch when master merges my branch and
Should I create a new branch from the master every time I make a new change?

This is often the case for temporary branches such as feature branches.On the other hand, develop and production are separated so that they can be merged at any time, leaving them both alive.

I also use Bitbucket a lot, but I haven't used rebase since I started using Pullik.

• rebase is a mechanical reapplication of each commit, so depending on how the master progresses, conflicts occur for each commit, which is troublesome
• Rebase, regardless of rebase, --ff merge makes it difficult to see the junction when viewed later
  (When merging pulliks on Github/Bitbucket, a merge commit is always created because it is a so-called --no-ff merge.)

The reasons related to Pullik are

• If you want to review or modify after creating a pullik, is the commit log bad anyway?So it's not worth much

The big thing is that plastic surgery is not as good as it is troublesome.

By the way, in the case of OSS published on Github, by synchronizing with master as git merge master instead of rebase, there are many cases where the conflict can be resolved by the pullik is called WIP before proceeding.

Atlassian, the operator of Bitbucket, has published a tutorial on workflow using Git and Git in Japanese, so why don't you read it?

https://www.atlassian.com/ja/git