On 2020-06-21 17:07, Sad Clouds wrote:
On Sun, 21 Jun 2020 10:32:32 -0400
g...@duzan.org wrote:
On 2020-06-21 16:07, Rhialto wrote:
On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
I am still curious about how to manage well in git the scenario
where you do
have a central repository that holds the actual source of truth,
and where
you want to review and approve anything that gets committed.
Let me point you to the hell that is called "Gerrit"...
Example: https://review.opendev.org/
Like I said. We are using gerrit. It's not without a bunch of
issues all on its own... :-)
Any other options around with similar functionality?
Johnny
Our group at work uses Gerrit. We have had some trouble
maintaining it, so we have been considering moving to Bitbucket,
which already exists in the company. Bitbucket seems nice enough,
though of course it is commercial. If I were looking for a solution
today I would consider Phabricator/Differential, as it is open
source, supports Mercurial, and appears decent enough.
Gary Duzan
What is the actual benefit of these tools? In a commercial environment
I find them to be a complete distraction and it often results in people
blocking you from committing changes due to various petty reasons.
Ideally, you wouldn't need to manage anything, you trust your team
members to use their own experience and commit correct and well tested
code. You can still review the changes on their private branch, but you
can easily do that on the command line - "svn diff --diff-cmd=meld ..."
was the best review tool for me.
Not talking about a specific tool, but the process then.
There are multiple advantages by having code reviewed.
First of all, noone is perfect. People make mistakes all the time, and
having two people look at it already reduce silly errors significantly.
Even when you have unit tests (which you should), there are still plenty
of errors not caught by that. However, automatically running unit tests
on all code to be committed, *before* it is committed, is also very
valuable. For which you obviously need a process.
Thirdly, it is also about spreading knowledge. It is never good to have
just one person be familiar with some code. By having another person
review things, you have at least two people who have a little deeper
understanding of the code.
There is absolutely nothing wrong with going back and reviewing already
committed code later. But in all honestly, that's more often than not
the exception rather than the rule. So I would never count on such a
process.
Finally, there are also the larger system type issues to be considered.
Code might be perfectly fine in the local context, but others might also
know a bit about other modules this code interacts with, and how those
other modules work, and how they expect things to be used. And code
reviews help catch those kind of issues as well. And it also helps from
a system architecture point of view to make sure that the code is
designed and works the way the overall design was intended, and that
people don't drift off and start doing things in completely different
ways which will break the overall design.
When you are in projects with more than a couple of people writing and
committing code, all of these issues have always been appearing, in my
experience.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
