[Bioc-devel] Best practice on commit

Martin Morgan martin.morgan at roswellpark.org
Mon Feb 26 20:58:40 CET 2018

On 02/23/2018 02:24 PM, Nicolas Descostes wrote:
>   Dear Bioconductor community,
> When developing further a package, is the best practice to create a branch
> and bump the version when a full new feature is merged or to stay on the
> master without bumping when committing temporarily? More generally, When do
> you usually bump a version?

Great question!

I'm not a pro, but have found that developing on a branch and then 
merging to master works well. This is especially true if whatever it is 
I'm developing might take a few days, when there are other things that I 
might want to address or that other people do to the code.

Often I think I'll do something small on the master branch, only to look 
up two hours later with a ton of changes that really belong on a branch 
as an intermediate commit, so I'm always wishing that I started with a 
branch, even for the small things.

I've found that I make lots of commits locally and the branch often 
never leaves my local computer.

Recently I've started to use --squash and other approaches to revise the 
commit history -- I think it will be much more helpful in a year to see 
a single commit capturing an 'atomic' view of the commit, rather than 
the dozen small steps and 6 mis-steps taken on the way to the bug fix or 
feature. Also, commits on the master and branch can overlap in time, so 
that a simple merge can create nonsensical intermediate versions.

It seems like branching can introduce some complexity, and furthermore 
that one can (quite ironically) make a permanent mess of a repository. 
So it seems like one has to be quite careful about pushing commits, and 
especially careful when adopting new git practices.


> Thank you.
> Nicolas
> 	[[alternative HTML version deleted]]
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or...{{dropped:2}}

More information about the Bioc-devel mailing list