this post was submitted on 16 Jul 2024
22 points (100.0% liked)

Git

2935 readers
1 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 2 years ago
MODERATORS
 

Coming from CVS and ClearCase it took me some time to adopt to Git. The fact that it was distributed was confusing at first, for example, because I thought that would cause chaos. But the way we used it was actually not "that distributed". But once I understood how it worked, not doing DVCS was "the wrong way" immediately.

top 8 comments
sorted by: hot top controversial new old
[–] [email protected] 7 points 5 months ago

I've only worked in software for about 15 years, so don't have much experience outside of git.

But my first job used Microsoft Team Foundation, and I didn't need any experience to know that user experience sucked. I've also done the "date named zip file" type of version control, which is not ideal.

When I started using git it just made sense to me, have had no major complaints since.

[–] [email protected] 5 points 5 months ago

Having used SCCS, RCS, CVS, SVN and then Git - like a progression of successive added features - as well as clearcase, I find the biggest difference when stepping up to git was the flinging of patchballs via the push mechanism.

I like how every working dir is really kinda a repo, and the ability to pick back into a repo from a suitably rich checkout has been a life-saver from time to time.

Having marshalled my own builds by hand or by cron, I do like the CI stuff in gitlab to trigger CIs and CDs; but the stuff in forgejo and GitHub can go to hell without any supper. Enough goddamned YAML, please.

As I think of projects I recently ditched before I started playing with CI, too, I almost want to pick them back up. We talk on another thread about the wasting death of good projects because the greybeards are dying and the kids dont have the time and clue to pick up after them, but maybe this automation will help them to keep maintaining their stuff (and someone else's) just a bit longer.

Git is good things. Clearcase was awesome but IBM destroyed the best company I ever worked for and bought Rational and withheld licenses while doing so, so they and clearcase can die in the same firey hell as YAML.

[–] [email protected] 3 points 5 months ago

As an ancient ops person, I was unfamiliar with version control before git. So git has really changed how I look at look at version control!

[–] [email protected] 3 points 5 months ago

How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.

When DVCS came up and became popular, I used Git and Bzr.

At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.

Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you'd now have the change in two places as different commits.

Anyway, I've never found Git difficult. I used it, learned and understood it, and it's consistent. I know enough "internals"/technical details to understand and use it well and without confusion.

[–] BillSchofield 3 points 5 months ago (1 children)

Local vcs let's you decouple saving progress (commit) from publishing your change (push).

This is a huge improvement over exclusive locks (old visual source safe) and shared server (like perforce).

There are many other improvements, but that is the one that had the most impact on my daily workflow.

[–] [email protected] 2 points 5 months ago

I had a sad incident where I had committed changes but not pushed, and then I accidentally spilled a drink on my computer and bricked it. Even though this is unlikely to happen again because I won't bring open containers like mugs or bowls of soup around computers anymore (water bottles are fine), and it was only three hours of work lost, because of this incident I do not feel I have saved until I have pushed. "What if you brick your computer again, huh, where's all that progress now?"

But overall I agree about decoupling saving changes from actually publishing them!

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

The staging area changed the way I work for the better. When I develop something, a file can be at the same time "not modified yet," in progress where I can carefully accept or reject the modifications, and partially done when the parts have been confirmed and added to the staging area.

Once nothing is "in progress" anymore, I know that my future commit is almost perfect and I can quickly review my stuff before committing. It’s faster and more safe than other tools.

[–] [email protected] 2 points 5 months ago

Too new to have come from older vcs, but I can tell it's a clear improvement over zip files.