3 ms·

I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfin

by 6510 6y ago

I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either. I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand? When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves. I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence. In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!

ptx 6y ago
> I have no idea what the point is. As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want? Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine. You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.
- seba_dos1 6y ago
  > Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. ...and manual copies don't offer you the great automations that git provides you for free, like being able to tell when exactly each line has been changed last time (so you can check the whole context of how and why that change was made) or perform a binary search of a revision that introduced a bug. Even when working alone, these tools are invaluable.

by 6510 6y ago

ptx 6y ago

> I have no idea what the point is. As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want? Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine. You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.

seba_dos1 6y ago
> Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. ...and manual copies don't offer you the great automations that git provides you for free, like being able to tell when exactly each line has been changed last time (so you can check the whole context of how and why that change was made) or perform a binary search of a revision that introduced a bug. Even when working alone, these tools are invaluable.