This guy is espousing cargo cult version control.<p>> This is how the Kernel team does it, so everyone should do it that way<p>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.<p>If anything, I would say the right way to use git in a small team is to always merge and never rebase.<p>Whatever you decide to do, make sure to think about <i>your</i> problem first, then use the tools to solve your problem.
I think it's a fallacy to say that just because Git <i>allows</i> 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.<p>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.<p>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.
The author suggests one "symptom" of using git wrong is<p>>Have you ever did a code review, and gave feedback that was longer than doing the fix yourself, while you’re at it?<p>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.<p>Sending the fixes back down doesn't seem like it would have the same impact.
> while it was created to be used like in Linux kernel development.
[ ... ]<p>> * You have one online repository for every project (or even the entire code in case of a monorepo).<p>> * Your repository/repositories have one branch that everyone branch from and develop their changes against. (Release branches don’t count.)<p>The kernel has one main repo that integrates things from the others, the "torvalds/linux.git":<p><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...</a><p>This keeps Linux together as One Thing. This is Linux's CVSROOT, so to speek.<p>> <i>You have one process that everyone have to follow to review the code; one review system and one place that runs all your tests.</i><p>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?
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.
A linked list is a binary tree, and using git in a centralized fashion is a legitimate use of git.<p>Not everyone wants a distributed version control system, and not every team is ready for a more complicated process.
> Have you ever did a code review, and gave feedback that was longer than doing the fix yourself, while you’re at it?<p>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...<p>It's also a way to teach people about coding standards and expectations for little things, such as spelling in comments.
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.
I see one major flaw in reasoning in this post: trust.<p>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 <i>trusts</i> the task to be broken down, distributed further down and completed. In this model code reviews function merely as tools to <i>roughly</i> 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.<p>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.
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.<p>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.<p>I can't imagine I'm alone in this.
I find this post quite amusing.<p>Many of the suggested methods of code sharing do happen, especially on large projects with multiple teams.<p>But the “one master branch” <i>problem</i> 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.<p>His real issue seems to be with code reviews... Which isn't really something unique to git...
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.<p>This applies to pretty much any version control where you can create a remote branch.
I have one comment for the article: LOL.<p>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!)<p>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...<p>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.<p>[1]: <a href="https://m.signalvnoise.com/the-majestic-monolith-29166d022228" rel="nofollow">https://m.signalvnoise.com/the-majestic-monolith-29166d02222...</a><p>[2]: <a href="https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb" rel="nofollow">https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb</a><p>[3]: <a href="https://trunkbaseddevelopment.com/" rel="nofollow">https://trunkbaseddevelopment.com/</a><p>[4]: <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow">http://nvie.com/posts/a-successful-git-branching-model/</a>
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...
We need a git repo holding the production version.<p>This is also where the continuous integration tests usually take place.<p>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.
One interesting thought this article provoked:<p>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.
> <i>And you might just not be enthusiastic about that “distributed” idea at all. Maybe more top-heavy, centralized system is actually what you need.</i><p>Talk about throwing out the baby with the bathwater!<p>Just because you have a blessed master branch, and a central repo, does <i>not</i> 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.<p>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.<p>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.<p>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.
>Have you ever did a code review, and gave feedback that was longer than doing the fix yourself, while you’re at it?<p>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.
> 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<p>> 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<p>This doesn't scale. I know team leads in large projects where reviewing
external contributions is their main responsibility; this style would be impossible.<p>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.
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.<p>Just because (autonomous) you can merge and push, doesn't mean you should. Right?
Under "Changing Code":<p>>It might seem like chaos, but it is not. It is just fluid synchronization, or to put differently: eventual consistency system.<p>Can anyone explain this? The example he used wasn't fleshed out enough for me to understand how this system wouldn't be chaos
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.