The user has finished a pull request and merged the changes from dev-nickw to master. Now from the screenshot master has 1 commit (that pull request) ahead of dev-nickw.
git.PNG
That is correct. The merge is treated as a commit and that is the one commit shown in master ahead of dev. Code should be the same.
Not sure what you meant in the second question. You don't need to delete the dev branch and recreate it every time. You can just reuse the current branch and continue to use pull requests to send the code to master.
As Jobin said, your current situation looks great.
With the specific commit set above, the branches should be actually in-sync (identical code). If there had been changes to master, your user could merge from master to dev-nickw. If he does that now, and allows it to be a fast-forward merge, Git will just move the branch reference to commit 210ae0f, which would clearly be in-sync.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To answer the second question, there would be effectively no difference between continuing to use the branch vs. deleting it and creating a new branch off of develop. A branch is just a pointer, so deleting it and then recreating it at (effectively) the same point won't make any difference.
Also, just to add to everyone else's answer, had there been any commits on the master branch after dev-nickw branched off, then the fact that his dev branch was behind would have had actual meaning, in which case you would want to either merge the master back into dev-nickw, rebase dev-nickw off of master, or (my recommendation) delete dev-nickw and create a new branch, named after the feature you're working on rather than the developer doing the work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.