Comment by greysteil
7 years ago
Nice. For anyone who hasn't see it, Flight Rules for Git is even more comprehensive: https://github.com/k88hudson/git-flight-rules
7 years ago
Nice. For anyone who hasn't see it, Flight Rules for Git is even more comprehensive: https://github.com/k88hudson/git-flight-rules
I like this. I was trying to do something similar with my Git cheatsheet - https://gist.github.com/JamesSkemp/15fcf0147cb85bb633bf - but it doesn't have the kind of organization I'd like due to the limitations of using a Gist.
I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.
> I'm planning on making a hard push for git on the team I just joined
You mean a force push. `git push --force` is one of my favorite commands. I've aliased `git yolo` to `git push --force --no-verify`.
--force-with-lease is usually the better option; it makes sure nobody pushed anything since the last time you fetched from the remote.
If they have, you can fetch, see if you still want to overwrite that branch, and if so run it again.
Maybe I ought to also insist I build git from source and scrub any reference to --force from it.
2 replies →
>git yolo
I hope you do not work on missiles or on passenger aircrafts!
I'm genuinely curious how they manage source without any VCS. Is it just a bunch of zip files for old versions?
No judgment, nobody is born knowing this stuff, just that I'm surprised to hear this is still out in the wild.
When I started working for the government (2010) it was .backup, .bak, .new, .newNEW, new-JIM, .20100910... all on one guy's workstation. Luckily Gitorious landed within months. (better than nothing)
We SSH onto a server to do work and it seems we just make folders wherever for our individual projects. They do (nightly, I think) backups which is sort of a rudimentary version control. And while I'm told it exists, it seems the "dev" version of their website isn't used, so they just kind of add in their changes live; definitely a risky environment. They've had a small team for a while and most of their applications could run relatively in isolation from others, so they could get away with it, but they're looking to grow so I'm trying to push this stuff.
3 replies →
Everybody that is not a programmer (or otherwise IT/technical) doesn't understand version control at all. So as other commentators have said, their idea of version control is to save the file with a different name, a different extension, etc.
I have seen it as files on a shared drive. I have seen it as files on a sharepoint drive. I have seen it as files inside of an SVN repository.
1 reply →
I remember joining a company where the official build was cut from whatever was on the engineer's PC at the time, since that PC was the only one set up that could build the software. No documentation, no formal bug tracking, no source control, very infrequent backups that were probably never tested. It was basically a "0 on the Joel Test" shop. This software was for embedded aerospace applications too (however not safety-critical where DO-178B would apply, thank god).
i know that some shops do nightly tape backups of the harddrive on the fileshare and consider that sufficient for version control. the theory is "developers don't have to learn a new tool and we will never lose more than one day's worth of work".
these shops don't understand the benefits version control offers when it comes to code review and maintenance patches on old versions of the software, or vendor-specific streams for your software.
My friend works for a small company that doesn't use a VCS. They just make a new folder and copy the project into it every once in a while.