3 Key Version Control Mistakes (HUGE STEP BACKWARDS)

One thing I've noticed throughout my career is a lot of teams are way too quick to throw away version control history. It seems nearly every company I work for, I end up having to argue against a plan that includes throwing away version history. This happens when switching version control systems (including ones that have an importer), or restructuring repos. I've done quite a bit of version control sleuthing on bug fixes where version history I am looking for is years or even decades old. Often times version control history is the only documentation that exists for knowing why some complex logic exists and if it is still needed or what it should do.

Version control gives you "undo" in software projects. No one would use a word processor without undo.

I use version control for basically everything these days. From writing letters, for my study notes and config files. To never worry about a mistake setting you back more than a few commits is a powerful thing indeed.

A VCS should be taught as early as possible.Git has the advantage, you can use it offline. You can use Git on your phone. You won't use your phone for a serious project, but for toy projects it's a good tool. If you use Git for toy projects, where you can experiment, a Git disaster in serious projects is less likely.

Simply put but pure gold. Thank you Dave

This is a succinct clarity of such a critical topic that we all too often take for granted.

To make things work together, I think that it helps to think of what you are versioning as an ENVIRONMENT, everything you need to make the "system" work, not just code, but also your Jenkins, and Ansible scripts. Use a branch to build an environment from dark, and use tags to provide version control. The trunk then becomes the complete serialized image of your production environment. "No junk on the trunk".

I would love to see an Abstract Syntax Tree based VCS, where you work on language constructs (functions, classes), instead of filesystem constructs (files). Most languages have an 'official' formatter, that can output the AST in nicely formatted files for portability.

Where I work we tend not to do rollbacks to previous versions at least not in production. If a bug is introduced it can swiftly be tracked down to a specific unit of work and a specific commit that was made. This commit can be reverted, and a hotfix produced with that reversion. This now increments the minor version of the main branch & the production code. Given that each release could represent 100 separate JIRA tickets across maybe 5 teams, this more surgical approach works better for us than removing all the work that worked well in a given release.

I'm not sure about git successor but I've used a lot of different version control systems and git absolutely could be improved on. It does a lot of things right. Probably the big one that git and other DVCS do is allow for easy branching and merging. A lot of prior systems didn't handle this well at all. Even SVN didn't have merge tracking for a long time. But there is a ton we lose with git too. The command-line commands are pretty random and arbitrary. It feels like a random pile of shell scripts (which is partially correct). There is no way to manage which branch should integrate into which. No permissions. No file locking (yeah lfs is a hack). No bug tracking integrations build in. You have to git stash way too much to do basic things. Because a branch is a pointer, commits don't track what branch they were done on. Deleting a branch can delete history. So yes, git is an improvement from many other systems but it is also a step back. First we should get back what we lost and then we can talk about the future.

It is a shame that all the knowledge that could be shared always has a negative connotation, would love to see more positive videos on this channel

I've recently head of, but not tried, a sort-of new version control system Jujutsu. I say "sort-of new" because it sits on git's very good back-end whilst putting a slightly less tortuous user interface on the front end. That's the part of git that really really does need to be replaced. git's user interface provides absolutely no abstraction whatsoever and after over 20 years of banging my head against it, I still find it next to impossible to give it any love at all.

You hit on a big point. Save your AI interactions. last year I started identifying the log files of the AI systems that I use and I capture those logs, and though although some of them are proprietary, I've used AI to backwards engineer what was said and unless they start encrypting them I will continue to do so as to change. But this discussion that you have with the system is important. If you save URLs in your code documentation for reference later or even in just the check-in notes it's essentially the same thing. And I find it extremely valuable to go back over discussions that I've had with systems and read what was said before and compare it to even new systems output because the systems have gotten better. I try not to rely too heavily on the output on critical systems without seriously vetting everything that comes out of it but probably preach into the choir there. Some of the agentic solutions that are out there are doing this. And they even allow you to roll back. So this is a problem that is in the process of being solved. But this feature is not shiny and isn't getting a lot of attention. Yet.

The issue with AI not being able to reproduce consistent solutions is a serious issue. It reminds be of the ACID test (atomicity, consistency, isolation, durability) for transaction systems, which is what versioning, or iterative software releases are. Regarding versioning software, it's important to version both the components the make up a system, and the interfaces between components. Often it's just the code/text files that are versioned.

Version control is a subject guaranteed to get the developer arguments flowing. The mistakes i have seen are backup files committed to VCS. Showing someone didn't really understand what VCS did. The other is using branches to avoid merging into a release branch. So dev creates a feature branch and then expects that feature branch to pass QA before it gets merged into the development branch. Whereas customers only care that the feature actually works in their release and the fact it worked on a development branch means nothing. I work with a lot of people that avoid TDD and TBD. Hence we have lots of integration challenges and also ground hog days with bugs that would have been caught by TDD.

The best feature of git is that you can work on a branch to work on a feature, and the main branch always remains releasable. Previous version control systems were not good at merging - which put a lot of people off from using branches.

Also useful for configuration, just need to be careful to handle secrets securely.

На этом канале всегда годные связки!

Thank you, Dave, for pointing out the bug in the Excel spreadsheet! Our minister of finance here in Germany knowingly acted on the wrong suggestion and did big harm to countries like Greece, Italy and Spain. Many people died. He never apologized.

Can you please add time stamps so I can understand what you are talking about in a short summary?