+1 on splitting large tickets into bite-size pieces... -- Nikita Ivanov
On Sun, May 24, 2020 at 4:54 AM Sergey Makov <[email protected]> wrote: > I think it is a good idea to go with one commit per feature. > Such approach makes the Git history much cleaner and it is already > widely adopted by the open source community. > > Regarding the case of multiple developers working on the same branch, > I think we should try to avoid it by splitting large features into a > set of smaller features. > > Here is some imaginary example: > > We need to add a new type of NCServerEnricher that replies on some > external ML library. > Such integration requires changes of our existing APIs and addition of > some new code to integrates with that library. > > I would suggest splitting it into two separate features: > - Refactoring of the core API can be done in `core-changes` branch by > someone who is more familiar with the NLPCraft core components > - Implementation of integration code can be done in `ml-changes` by > someone who is more familiar with that ML technology (which can even > use some other programming language) > > It is ok if one branch will depend on the other (i.e. core-changes -> > ml-changes) as we can merge them to master one by one. > But at the end each feature should result in one commit: > /core-changes: Extend NCServerEnricher API with XYZ... > /ml-changes: Custom implementation of NCServerEnricher that uses ML > library... > > Regards, > Sergey > > On Sun, May 24, 2020 at 12:06 PM Sergey Kamov <[email protected]> > wrote: > > > > Hi! > > > > I want to discuss commit comments policy. > > > > If one developer works on small task, everything is clear - he should > > add detailed commit comments, and these comments will be pushed in > > master branch after merge. > > > > 1) If developer worked on long time task in separated branch, he could > > done a lot of intermediate commits. > > Should he do one result squash commit with one united comment when he > > merges work branch to master? > > (Seems reasonable) > > > > 2) But what should we do if few developers worked in same branch on long > > time task? > > If one of them does squash commit, comments of another developer will be > > lost? (and their work will not be visible at all) > > > > > > Lets define one common policy? > > > > > > Regards, > > > > Sergey > > >
