
Using Git Wrong - aarohmankad
https://dpc.pw/blog/2017/08/youre-using-git-wrong/
======
hasenj
This guy is espousing cargo cult version control.

> This is how the Kernel team does it, so everyone should do it that way

99% of the time, your team has absolutely nothing in common with the Kernel
team and it's foolish to adopt processes from other teams without knowing why.

If anything, I would say the right way to use git in a small team is to always
merge and never rebase.

Whatever you decide to do, make sure to think about _your_ problem first, then
use the tools to solve your problem.

~~~
w4tson
He's also forgotten that git was invented before continuous delivery and the
idea of releasing often from one stable master branch.

That said it can be useful _sometimes_ to push changes out of band straight to
a colleague. I have used this a few times to great effect but don't often come
across the need

~~~
sarnowski
Wait, what?

> git was invented before continuous delivery

git was invented 2005. So you mean when people used the term Continuous
Delivery more frequently? Because using CI and automatically deploy is not
"new" and was surely done before git - I remember doing that even with CVS and
SVN.

~~~
w4tson
Come off it. There's a lot more to continuous delivery than ci + deploy.

It's goes hand in hand with BDD and automated testing. I reckon there's a lot
less people doing this stuff today in the wild than you'd think.

Sure there's the Netflix's n googles of the world. It was only a few years ago
I would consult on projects that would have no CI. It happens.

The same thing is happening today, just because you read about kubernetes or
swarm simply does not mean anything like the majority of the people out there
are using it in production. Just go to a conference and and watch people stick
their hands in the air.

Sure SOMEONE might have been doing continuous delivery back in 2005, it
certainly wasn't me. I was too busy learning about data access objects vs ORMs
and releases were 3 months away if you were lucky.

------
rcthompson
I think it's a fallacy to say that just because Git _allows_ a completely
decentralized organizational structure, that not using one is somehow wrong.
The beauty of git and any other DVCS is that it doesn't prescribe any specific
organizational structure, so you're free to adopt any structure you like on
it. And critically, you're free to change it when it makes sense to do so. I
think the reality is that a centralized structure works best for most projects
most of the time, but git has the flexibility to break out of that mold.

For example, maybe in one project most of the time everyone pushes and pulls
from a centralized master and not to and from each other. But then two
developers get together to try and solve a particularly troublesome bug. While
they're doing this, they can push and pull directly from each other without
worrying about master, and then once they're done, they can merge, clean up,
etc., and then push the result to master. Git allows these kinds of pockets of
decentralized development within an overall centralized workflow, and does so
seamlessly.

Since Git allows any organizational structure, it's up to the people working
on a project to choose what works best for them. That's a responsibility that
they didn't have before DVCS, because only one structure was supported by the
tools.

~~~
magnet_ball
But why won't they just work on a separate branch still sitting against the
main git repo? So long as the internet is up it offers the same thing
basically.

~~~
jmiserez
If they work at the same company, yes. It’s often (always) easier to use the
central repo than to figure out connectivity or send patch files.

But if they’re in different companies, and there is no central repo
visible/accessible for both devs, then yes the D in DVCS is definitely
appreciated.

------
agrona
The author suggests one "symptom" of using git wrong is

>Have you ever did a code review, and gave feedback that was longer than doing
the fix yourself, while you’re at it?

But this seems to neglect the utility of teaching people to do things
correctly. Sure, I could always just fix junior programmers' mistakes, but it
seems better to educate them in the first place.

Sending the fixes back down doesn't seem like it would have the same impact.

~~~
nitemice
Depending on the kind of mistakes they've made, better again would be to
provide a style/implementation guide for the code etc. so that instead of
having to review code or have arguments break out over how something should be
written, you can just point to a definitive guide beforehand, and avoid the
troubles.

I say this, unfortunately, from experience. It has become common in our team
for a new developer's first commit to be met with a blasting review, telling
them everything they've done wrong, and most of it is
capitalisation/whitespace etc. stuff.

~~~
amenghra
Better yet, replace the style guide with a script (à la go fmt). You'll save
everyone time and make the new person's experience a million times more
pleasant!

~~~
userbinator
Not if the new person disagrees or prefers a slightly different style. Reviews
at least provide a chance of discussion and a possibility of change. Not
everyone wants to work in an authoritarian environment of "do it this way or
leave."

~~~
JelteF
Gofmt, or rustfmt or whatever language fmt are really one of the best things
that happened to modern development. Even if you don't agree with the style,
which nobody does fully, it's much better than having discussions about style
all the time and having to format the code manually. Formatting just happens
when you save the file, so you can forget spaces and everything when writing
and your code will look fine when you save it.

~~~
dozzie
> Gofmt, or rustfmt or whatever language fmt are really one of the best things
> that happened to modern development.

Funny way to state that. There is this formatting tool `indent' for C and C++.
It was already well known and rather rarely used back in 2003. Code formatters
have not happened to "modern development" by any stretch.

------
kazinator
> while it was created to be used like in Linux kernel development. [ ... ]

> * You have one online repository for every project (or even the entire code
> in case of a monorepo).

> * Your repository/repositories have one branch that everyone branch from and
> develop their changes against. (Release branches don’t count.)

The kernel has one main repo that integrates things from the others, the
"torvalds/linux.git":

[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/)

This keeps Linux together as One Thing. This is Linux's CVSROOT, so to speek.

> _You have one process that everyone have to follow to review the code; one
> review system and one place that runs all your tests._

No kidding; also: one payroll from which everyone gets paid and one product
that customers understand: not seven versions of the product based on whose
cubicle it came from. See the trend?

~~~
bonzini
Developers however use Linus's repository only to find a convenient forking
point. Most of the development happens either in subsystem trees, or in
distribution forks (where "distribution" includes big companies like Google or
Facebook); only bug fixes target Linus's tree directly.

And most users use stable trees or distribution forks. So Linus's tree has the
distinctive feature that almost no one uses it, unlike a traditional CVSROOT.

~~~
zie
That almost no-one uses _directly_ , but pretty much everyone you mentioned
definitely pulls from it(or pull from things branched from it). It would be
super interesting to see a path map of commits and what trees they came from
for the big distributions of the kernel(i.e. android, debian, fedora, etc).
But I'd bet that all of them pull from Linus's repo as a descendant.

My understanding of the general flow layout for the kernel is:

developer branch -> patch -> mailing list -> sub maintainers -> large
maintainers -> Linus -> Stable branch X.X -> distribution (i.e. Debian/etc).

With some things cherry picked here and there that don't flow through this,
but that most code does.

~~~
bonzini
Sure, everyone's tree descends from it. However:

\- normal CVSROOT: developers develop on top of the head of the day.

\- Linus's tree: developers develop on top of someone else's head of the day,
except for some bugfixes.

Linus's tree becomes "similar" to a CVSROOT only after he cuts a release. But
at that point, version control is actually not part of the game anymore.

------
lobster_johnson
In our company, every developer must fork the main repo to their own account,
and every change that they want merged into master needs to be done as a PR
that is then reviewed by the right person. That's a completely distributed
process, and works great for a small company. We obviously need a central repo
because apps need to be deployed from a single history -- a central master
branch is not an antipattern, as suggested by the author. Even Linux has a
central master branch.

~~~
thanksgiving
My perspective is that we might be looking at two different things:
development and deployment. Of course, each deployment has a canon. I think
the idea of the bazaar is that there does not need to be a single canon but
maybe I'm misinterpreting it.

------
godd2
A linked list is a binary tree, and using git in a centralized fashion is a
legitimate use of git.

Not everyone wants a distributed version control system, and not every team is
ready for a more complicated process.

------
matt4077
> Have you ever did a code review, and gave feedback that was longer than
> doing the fix yourself, while you’re at it?

I always thought this process was sort-of intended. I feel it shows some
respect to the author of the code under review to comment on it, and not to
change it–especially not if that would result in changes that are then merged
without first getting approval from the author. I'm having trouble finding the
right words for this idea...

It's also a way to teach people about coding standards and expectations for
little things, such as spelling in comments.

~~~
kqr
I'll provide contrast, then.

Code checked into version control is never changed. What happens is the
reviewer creates a derivative work. If they use my code as a basis for their
derivative work, that's a sign of respect just as much as anything else. It
means that they think I actually got it mostly right.

The same argument applies if it's merged right away. Unless the reviewer(s)
blatantly misunderstood something important, it's likely their fix is an
improvement. And even if they did, the previous code is just a
reset/rebase/oops-commit away.

That said, you should still discuss the code to iron out misunderstandings and
learn things.

------
colbyh
Author seems to assume that all software development is like Linux development
and it isn't. I can't have 10 different versions of my order processing
service floating around doing different things for different people.

~~~
A_No_Name_Mouse
Isn't his point that different people have different needs, and git was
created with one typical use in mind? So maybe not everyone should use git
exactly because their needs may be different? Disclaimer: not a serious
programmer myself

~~~
colbyh
But he starts by saying that people are using git "wrong" (or suboptimally).
If git fits my needs why should I worry about how this dude or Linus or the
prime emporer of gitland thinks it should be used?

I think the author has a great point about the differences between how git was
"designed" to be used as compared to how it ends up being used in orgs most
often. But I also balk at being told I'm using an open source tool incorrectly
as a general rule.

disclaimer - I really want prime emporer of gitland to be a proper honorific.

------
friendzis
I see one major flaw in reasoning in this post: trust.

Lets pretend that architects are under team leads, seniors under architects,
juniors under seniors, etc.. In this hierarchical model every layer forwards
some responsibilities down the chain and _trusts_ the task to be broken down,
distributed further down and completed. In this model code reviews function
merely as tools to _roughly_ check for gaping mistakes and whether code fits
"architecturally". People are trusted to do their job to the best of their
ability and are allowed to have personal style.

In a model where seniors go over everything juniors made, fix according to
their own view and then commit we have a problems that lower layers are not
trusted to do their job correctly and in the end everything has to strictly
conform to product owner's vision or will be "fixed" (rewritten). In this
model there are no longer junior, mid-level, senior engineers, because the
more minions one has under them, the less time they have to produce anything
on their own. In this model there are junior, mid, senior code-monkeys and one
mighty product owner who knows it all best. Not sure that environment where
only career growth opportunity is ability to rewrite other's code to your own
liking would be good for team morality.

~~~
pjmlp
You just described enterprise consulting with outsource/offshored projects.

------
skrebbel
What I really want is Subversion, but then without all the bugs and the weird
file locking. And with easy release branches and a way to make commits locally
and then share a bunch of them at once with my colleagues.

Of course no such thing exists, so I use Git which has these features but
combines them with 10x worse UX and 10x more condescension from the community.
But I put up with that, only because it's the lesser of two evils.

I can't imagine I'm alone in this.

~~~
chiefalchemist
What you (and I) want and need is Git with a better UI / UX. I want see a
better visual representation of that's happened, and not just a list of
commits.

For example (and simply thinking out loud so don't shoot me), why can't I
modified a file. Then modify another file. Then create a commit object (so to
speak) and drag the files on to that commit? And then, once I'm sorted, I drag
the commit on to a push. Which perhaps goes into a queue for review. And then
the tool somehow help enable that review knowing any other commits on the same
files, etc.

Coding is building. Seeing it visually is going to help. It always just seems
to me I'm forced to think too much about Git, when a UI would do. And the
brain cycles I use on Git (however small) could be used to write code (not
wrestle with managing it).

------
ravitation
I find this post quite amusing.

Many of the suggested methods of code sharing do happen, especially on large
projects with multiple teams.

But the “one master branch” _problem_ is not a result of missuing git... It's
a result of there being one version used in production... No git process
change is going to change that.

His real issue seems to be with code reviews... Which isn't really something
unique to git...

------
nurettin
The longer you keep your branch around "to be battle tested and swapped across
teams or modules", the more attention and time you have to pay keeping it
updated. Cost increases as your branch "gets battle tested". If your company
can afford that, it's fine.

This applies to pretty much any version control where you can create a remote
branch.

------
Walkman
I have one comment for the article: LOL.

Seriously, the author probably never worked in teams with different sizes [1,
2], considered another workflows [3, 4] and skill levels of the developers
(yes, that's a variable you have to consider also!)

Also if you use Git in the same manner as CVS, you should do it because it's
much faster, more reliable and more flexible...

Edit: Ok, the author is saying things which I agree with, I was commenting on
the click-bait title and the first paragraphs mostly, but still, there is more
to the story.

[1]: [https://m.signalvnoise.com/the-majestic-
monolith-29166d02222...](https://m.signalvnoise.com/the-majestic-
monolith-29166d022228)

[2]: [https://blog.bradfieldcs.com/you-are-not-
google-84912cf44afb](https://blog.bradfieldcs.com/you-are-not-
google-84912cf44afb)

[3]: [https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

[4]: [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/)

------
Sytten
These are nice ideas and I must confess that I never douted the way we use Git
before reading the article. However, in the companies I worked for (and I
think it applies to a lot of companies), the time constraints were too tight
to allow more than form-based reviews. I do feel these reviews are sub-optimal
and should be replaced, but checking out the repo and testing yourself is a
very slow process that we mostly can't afford. Most of the time the "go fast,
break things" motus is applied and it's fine if you are not building critical
applications like a kernel...

------
chmike
We need a git repo holding the production version.

This is also where the continuous integration tests usually take place.

What is a good point of the OP is that people may not be sharing and testing
code enough before pushing to the reference repo.

~~~
davestephens
Out of interest why do you "need" a repo/branch replicating production? I ask
out of curiousity rather than criticism.

We also have the same at my place of work, but for convenience when requiring
to patch production - ie just branch master rather than scramble to find the
commit hash last released. It's not a requirement, but it definitely makes
life easier.

~~~
chmike
Because it provides a unique reference point. If there wasn't such a a
reference point, there is a risk that the production branch of programmers
becomes desynchronized.

It is easier and safer to have n developpers synchronizing to one reference
repository, than to keep n developpers and repositories synchronized with each
other.

------
bsimpson
One interesting thought this article provoked:

Code review often catches typos, or edge cases that should be tested. As the
OP points out, you end up serializing the problem into a comment, which the
other developer has to deserialize, implement, and send back. Worse, these
sort of issues often come across as nags - I'd be happy to fix a typo myself,
but feel like a jerk calling someone else's out. I rather like the idea of
pulling down somebody's diff, amending it, and pushing it back up. I'll have
to try that sometime.

~~~
jmiserez
You can’t catch all the issues in code review every time, and it’s not always
you that does the reviews. If you fix everything yourself, the original
committer won’t learn anything and the next submissions will have the same
issues. Or perhaps the edge case isn’t really an edge case and there is
nothing to fix after all, in which case you’ve wasted time for nothing.

Also, if you do this people will likely subconciously take advantage [1] of it
in the long run, and if you ever leave the team quality will suffer.

[1] ever had flatmates? Do all the dishes and cleaning for a month and you’ll
see :-/

------
dasil003
> _And you might just not be enthusiastic about that “distributed” idea at
> all. Maybe more top-heavy, centralized system is actually what you need._

Talk about throwing out the baby with the bathwater!

Just because you have a blessed master branch, and a central repo, does _not_
mean imply you aren't making use of your DVCS. You can still do all
development on topic branches, including CI, and you can do it all in an
asynchronous manner.

This idea of pushing branches between individuals in an ad-hoc fashion with
whatever tools everyone wants to use makes perfect sense for something like
kernel development where A) there is no single product running on a single
production environment, it's a freaking kernel deployed to billions of systems
globally and B) you're dealing with a huge set of people who you could never
hope to standardize anyway.

When you're shipping a complex product to a single production environment, it
makes a great deal of sense to centralize certain things. Having everyone
bike-shedding on a million different code review paths, and relying on each
individual to pass their code around to other individuals with no single place
where you can look to find out what someone was working on will lead a lot of
chaotic inefficiency that will leave juniors confused, and all in the pursuit
of some platonic ideal that is cargo-culted from a completely different
project.

Don't get me wrong, I think most people have a lot to learn about how to use
git better, and I am a huge proponent of the value of a well-curated VCS
history, but this article is inappropriately prescriptive nonsense.

------
alphaalpha101
>Have you ever did a code review, and gave feedback that was longer than doing
the fix yourself, while you’re at it?

Yes. Yes yes yes. I hate this so much. I want my code reviews to involve
fixing little things. I don't even have suggested edits, I can only highlight
comments and make comments, and even suggested edits wouldn't be enough. I
want to just make the changes. It's all on a branch anyway.

~~~
bowmessage
Yeah, but you miss the training opportunity this way..

~~~
alphaalpha101
How so? It's on the code review. They see the change, and learn about it..?

99.9% of code review that I do, and that I get, is not training. So maybe
don't make all the changes for new employees? I use vim. Most people at my
work use vim. Our build process is complex. Everything we do is really
complicated. It works for the experienced, yet it has a learning curve.

So, new people get a slightly different experience. That's fine.

------
Everlag
> The way code review is done: by looking on an output of diff command,
> pretty-printed in a web-browser, and pointing out obvious mistakes is very
> inefficient and fundamentally insufficient

> open in IDE/text editor of their choice with or along diff viewer, jump
> around the new code, run tests and even write some new ones, toy with it

This doesn't scale. I know team leads in large projects where reviewing
external contributions is their main responsibility; this style would be
impossible.

Instead, I think the human, diff based approach with CI running against the
reviewed code is enough. A reviewer going over the tests which are shown to be
passing should be sufficient after the usual diff read-through.

------
chiefalchemist
Ideally, shouldn't all "merges" come from PRs? That, there's a gatekeeper (or
sorts) that helps to prevent sloppy, unnecessary and erroneous things from
ever making it into the code base.

Just because (autonomous) you can merge and push, doesn't mean you should.
Right?

------
sreya
Under "Changing Code":

>It might seem like chaos, but it is not. It is just fluid synchronization, or
to put differently: eventual consistency system.

Can anyone explain this? The example he used wasn't fleshed out enough for me
to understand how this system wouldn't be chaos

~~~
_pmf_
The part about eventual consistency is just the author throwing around terms
he does not understand in an effort to sound relevant.

------
feketegy
Every once in a while there's an article like this. S __t, use it how ever you
want as long as makes you productive.

------
cntlzw
git as a tool not a workflow. If you want to use git like a central VCS that
is fine. git allows it. If you want to go fully distributed like the kernel
devs. Fine, git allows it. As always, pick the approach that works best for
your environment and not tell people they are wrong because of X and Y.

