Reputation: 165

Git workflow--merging master into work branch for final merge

A coworker uses a git merging strategy that I'm unfamiliar with and seems kind of unusual, and I'm trying to make sure that I understand how merges work. My understanding is that the normal flow is this:

checkout a new branch from master
work on that branch for a while
when you're done, checkout the work branch, and run git merge <work-branch-name>

I also get that if your work branch has been running for a while, you may merge master into that branch periodically to keep it up to date with other changes.

What my coworker does is for the final merge is git checkout master; git merge <work-branch-name>. This results in a network like the one below. Where the black branch would normally be master, in this image it's actually the work the coworker did on their work branch, while blue is the work done on master.

So the question is: does this flow have any downsides? The rest of the team does the more traditional "merge into master" or rebasing. My thought is that the coworker's work might get overwritten, if someone else on the team makes changes on the master branch in the same places that the coworker has edited in their branch. Anything else I might be missing?

Upvotes: 2

Answers (3)

Eric

Reputation: 779

So I started answering this post on reddit.com/r/git but it may be a better resource if I post my response here as well.

git checkout workbranch

Do work
Save work

git commit -a -m "message"

"and now 'master' has moved on from where it was"

This is because someone has merged changes and pushed them to master. [OP answered my question in the reddit post]

git checkout master
git pull
git checkout workbranch
git merge master

So the purpose of merging master into your workbranch, is to pull any changes that someone else may have pushed up. This is normally used when your workbranch needs to stay current with code that may have relevant changes you want in your workbranch.

A better way to do those steps is to not checkout master. What if someone pushes changes to master before you complete the merge? Instead do the following

git checkout workbranch
git fetch origin
git merge origin/master

By running git merge origin/master you tell it to just merge the remote branch of master into your current branch.
Note: This is the same branch you are checking out by running

git checkout master 
git pull

So up to this point everything makes sense imo, it is the long way to do things but it isn't 'wrong'

Here is the real concerning part.

git checkout master
git reset --hard workbranch
git push

A quick glance at the documentation for git reset yielded the following,

git reset [] []
This form resets the current branch head to and possibly updates the index (resetting it to the tree of ) and the working tree depending on . If is omitted, defaults to "--mixed".....

--hard
Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.
Source: https://git-scm.com/docs/git-reset

So it sounds like it resets to the commit of the workbranch and removes all other changes. Then the push sends the changes up to the repository.

Normally the repository should be rejecting or creating a merge conflict because the commit id's do not line up. This could mean a git push -f is occurring, that's a no no if you don't know what you are doing and others are using that repository it can lead to some headaches.

Upvotes: 1

George Chen

Reputation: 6959

Instead of

git checkout master; 
git merge <work-branch-name>

git rebase master
git checkout master; 
git merge <work-branch-name>

rebase results in a clear commit history

also

`I also get that if your work branch has been running for a while, you may rebase master into that branch periodically to keep it up to date with other changes.'

You can found detailed explanations in this tutorial

My thought is that the coworker's work might get overwritten, if someone else on the team makes changes on the master branch in the same places that the coworker has edited in their branch. Anything else I might be missing?

I am with you, resolving merge conflicts sometimes causes losing changes, work get overwritten. The practice we are using is, before push to master, we fetch and rebase from master, resolve conflicts locally(if any),run all unit-tests. If changes are covered by unit-tests, any merge error will be detected. There is also a CI server that runs integration tests every time changes pushed to master.

Upvotes: 0