ok, but I think, sometimes tasks cannot be split.
Simple example - I guess, python server (last PR from Gleb) cannot be
merged into master before other developers finish some components based
on it.
Or some another big module cannot be merged partially because it doesn't
have sense in this case.
Maybe following schema for task A.
1) branched A prepared based on master
2) developer-1 works with its branch A1 based on A and merges A1 into
A when necessary using squash
developer-2 works with its branch A2 based on A and merges A2 into
A when necessary using squash
...
3) As a result, branch A should be merged into master without squash
What do you think?
Regards,
Sergey
25.05.2020 02:35, Nikita Ivanov пишет:
+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
