CODEWITHSUNDEEP
gitmergerebasepull-request
Aaron G
Aaron G

Reputation: 83

Is it OK to use the same local branch forever

We recently switched to git from Team Foundation Version Control. I've found a tendency among our development team to want to make a local branch off of local master, call it local-dev, and then use that branch forever. We are using a pull request process so they push their local-dev onto the server and perform a pull-request onto master.

When the pull-request completes, they delete the server-dev branch but keep their local-dev branch. They just pull the latest into their local master, and then merge local master into local-dev. Then repeat the cycle.

Is this an OK thing to do? In my head I see that since their local-dev is never being rebased, they are continuously pushing all history since day 1 onto the server every time they do a pull request and are forcing the server to handle that merge. Which seems to work OK.

Is this a ticking time-bomb? Is this perfectly acceptable and I'm worried about nothing? What is the server doing to handle this merge?

Upvotes: 2

Views: 248

Answers (3)

Evert
Evert

Reputation: 99543

If they are rebasing origin/master every time they pick up a few feature, then there's not that much harm as the full history of their own local-dev branch is shared with master.

But if they are doing the opposite, and are in fact doing a forced-pushed on master and full rewrites, then yes I would argue that they are using the tool incorrectly. If this were the case, I imagine they would also need to resolve the same conflicts over and over again.

Rebases aren't that harmful on short-lived feature branches, but I would probably never want to allow them (or force-pushes) on master unless it's to repair something after someone broke it.

Upvotes: 0

bk2204
bk2204

Reputation: 76499

Git uses revision walking to negotiate a common set of commits on both sides. So if, during a push, the client side knows what the server's master branch is, then it will be able to eliminate anything it contains from being sent, including the old version of the local-dev branch.

The workflow that's being used isn't necessarily inefficient for pushes, but repeated criss-cross merges between master and the local-dev branch make git log --topo-order very slow. So while it may not be a problem for inexperienced Git users, it will make advanced users a little unhappy since it causes some slowness in advanced operations. It also creates an untidy history, which some people feel strongly about.

In addition, this workflow prevents having multiple branches in flight at once. A developer might need to wait to merge a branch because the subject matter expert is on vacation and can't give a review, and creating a new branch would allow working on a different piece of work while waiting for that review.

The typical workflow is to create a new, uniquely named branch for the feature or bug fix in question, make changes, and push that up. The local branch can be discarded when the server branch is merged (or kept if the person prefers).

So ultimately the answer is that this is not a typical workflow and it causes a few practical problems, but it isn't hugely problematic. It wouldn't be a problem to educate your users, but it's up to you whether you think it's important enough to enforce in policy.

Upvotes: 3

Popeye
Popeye

Reputation: 380

The short answer is NO.

A suggested method.

  • A new branch should be created as new branch. Developer must work on that branch
  • Pull request should be done with either development or master branch. I dropped development branch and create pull request with master branch. And permission to merge with master is limited, so risk get mitigated. If there was no option, I would have keep development branch and create pull request with development branch.
  • After Approval and before release create release branch from master, create pull request with from feature branch to release branch, approve, merge.
  • Release the release branch
  • Create a pull request with master branch and development(if you have) branch
  • When product manager or producer are satisfied with the release create pull request from release to master and move on with your life
                     Release branch
                /--------- <- Release ------------ 
master branch  /        /merge with release  \  \  merge feature with master
-----------------------/-----------------------  \
               \ Feat / ure branch                \
                \---------------                   \
                      \  for review purpose only    \
development branch     \   (parallel to master)      \ merge feature with dev
------------------------------------------------------------

sorry, look messy

Upvotes: 0

Related Questions