git branching model

Git Branching most of the time seemed like a maze to me. Specially while sending a Pull Request for sprint development.

When there are three features in a sprint,

1) One idea could be  - maintain three local branches for each feature and send three parallel PRs separately.
After feature gets merged, delete local and remote feature branches.

2) The other could be - maintain three local branches for each feature, but when finished merge them to one single branch and send a PR one by one or ?.

I think the second one restricts from having number of unwanted branches to be deleted later, which looks OK to me while working in a team. 

Here's how I implement this approach; assuming sprint/develop is an upto-date branch created with HEAD of master,

STEP 1 - create feature branch

git checkout -b module-1/feature-1 sprint/develop

STEP 2 - after feature completion

Merge it to single sprint/develop branch

git checkout sprint/develop

git merge --no-ff module-1/feature-1 # create a new commit object.

## delete the feature branch

git branch -d module-1/feature-1

STEP 3 - rebase sprint/develop branch with master

git rebase master ## if any conflicts occur, resolve them manually, git add conflicted files, and

                            ## git rebase --continue

STEP 4 - push develop changes

git push origin sprint/develop  ## or git push --force origin sprint/develop

STEP 5 - Send PR and get reviewed
Send PR for merge on master. what?? few implementation not aligned with architecture of codebase?? FIX them on same branch and push.