Git Branching - Best Practices - Large project - long running branches

Git Branching - Best Practices - Large project - long running branches

[Mayne, Joe]

Hello,
I work on a team of 15+ developers. We are trying to determine best practices for branching because we have had code stepped on when a developer has a long running feature branch. 

We have a Development branch. Developers are instructed to create a branch when they begin working on a feature. Sometimes a feature may take a week or two to complete. So a Developer1 creates a branch and works for a week or two. In the meantime, other developers have created feature branches from Development and merged them back into Development. 

At this point we are not certain if Developer1 should: 
* Periodically merge the evolving Origin/Development into their Feature branch and when they are done work merge their feature branch into Origin/Development. 

OR 

* Stay on their pure feature branch and when they are done merge into Origin/Development. 

We have had issues with developers stepping on code when they have long running branches. We are looking for a best practices. 

Thank you,
Joe Mayne

Re: Git Branching - Best Practices - Large project - long running branches

[Jakub Narębski]

W dniu 31.03.2017 o 13:55, Mayne, Joe pisze:

> Hello, I work on a team of 15+ developers. We are trying to
> determine best practices for branching because we have had code
> stepped on when a developer has a long running feature branch.
> 
> We have a Development branch. Developers are instructed to create a 
> branch when they begin working on a feature. Sometimes a feature may 
> take a week or two to complete. So a Developer1 creates a branch and 
> works for a week or two. In the meantime, other developers have 
> created feature branches from Development and merged them back into 
> Development.
> 
> At this point we are not certain if Developer1 should:
> 
> * Periodically merge the evolving Origin/Development into their
> Feature branch and when they are done work merge their feature branch
> into Origin/Development.

This is one possible solution.

Another variant of this would be to enable rerere feature (reuse
recorded resolution), and periodically do a trial merge from the
Origin/Development branch to prime the rerere mechanism (discarding
those merges after resolving them).

> 
> OR
> 
> * Stay on their pure feature branch and when they are done merge
> into Origin/Development.
> 
> We have had issues with developers stepping on code when they have 
> long running branches. We are looking for a best practices.

There is yet another solution:

OR

* Periodically _rebase_ pure feature branch on top of current version
of Origin/Development, or do such rebase (perhaps an interactive one
to clean-up feature development steps) before pull request, before
they are to merge feature branch into Origin/Development.

You can also try to use third-party git-imerge tool to help merging
long divergent branches.

HTH,
-- 
Jakub Narębski

RE: Git Branching - Best Practices - Large project - long running branches

[Randall S. Becker]

-----Original Message-----
>On March 31, 2017 7:56 AM: Joe Mayne Wrote:
>Subject: Git Branching - Best Practices - Large project - long running
branches
>I work on a team of 15+ developers. We are trying to determine best
practices for branching
>because we have had code stepped on when a developer has a long running
feature branch. 
>We have a Development branch. Developers are instructed to create a branch
when they begin
>working on a feature. Sometimes a feature may take a week or two to
complete. So a Developer1
>creates a branch and works for a >week or two. In the meantime, other
developers have created
>feature branches from Development and merged them back into Development. 
>At this point we are not certain if Developer1 should: 
>* Periodically merge the evolving Origin/Development into their Feature
branch and when they
>are done work merge their feature branch into Origin/Development. 
>OR 
>* Stay on their pure feature branch and when they are done merge into
Origin/Development. 
>We have had issues with developers stepping on code when they have long
running branches.
>We are looking for a best practices.

One key thing that may help is standards on formatting. I know that sounds
silly, but many merge
issues result from developers hitting the source format button and create
merge problems. If you
keep things to format standards, it will help merging in future. Even
lengthening lines to 132 instead
of 80 may reduce confusion - another silly suggestion, but I have seen it
help in a couple of places.

Keep your interface classes and base classes stable. If you are changing
those during development,
you are going to impact the larger world and probably should set up a
dedicated feature branch
off of Development and have all topic branches involved in the API change
branch off that one.
Frequent merges into topic branches are common when API changes are ongoing
(as are conflicts)
- they should not be as much when the APIs are stable. If you can, get the
API changes done first,
then create topic branches after the API is stable.

From what I have seen, frequent conflicts are sometimes an indication of an
underlying
development process problem - you should look into this and see whether
there are issues here.
Conflicts happen, but the "why" is important to understand.

Cheers,
Randall