3 ms·

Thanks, looking forward. Yeah, totally get about git diff - I'm talking exactly about how you know that it is commit X that you need to compare with and not com

Thanks, looking forward. Yeah, totally get about git diff - I'm talking exactly about how you know that it is commit X that you need to compare with and not commit A. Also my preferred workflow is different from yours. I try to use trunk based development with commits to master directly, branches generally allowed either on dev machines only or long-term release branches which are never merged back to master (on some high-compliance projects). I try to reduce the number of branches as much as I can - there is some pain there in committing to master and ensuring green build, but then you don't have that pain when merging (following advice of Continuous Delivery book by David Farley, Jez Humble).

verdverm 7y ago
Trunk doesn't really work for teams because you need multiple features to be worked in parallel Commit X is stored in a well known file and committed to git
- taleodor 7y ago
  Google does trunk-based development for thousands of people - https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ (Although if you mean short-lived 1-day feature branches always merged back to trunk - we're on the same page here). Worked fine for my teams as well, although I usually use multi-repo - part of what Reliza Hub does is it gives holistic view of multi-repo structure.
  - verdverm 7y ago
    Just because Google does something a particular does not mean it's right for everyone else. Most of us will never experience the problems of their scale. Do you check out subtrees from the monorepo like Google does?