Git is what’s known as “Version Control Software” which basically means that it keeps track of the changes you make.
It’s primarily used for software development, and where it shines is when multiple people are collaborating on a project which will receive many changes. You can create a “branch” of the project with the changes you want to “commit” and then after they’re reviewed in a “pull request” you can “merge” them back inyo the main branch. If at any point in the process you discover that the changes cause issues, a history allows you to “revert” those changes back to what you had previously.
As you can probably see, there’s a fair bit of terminology in git. It’s a powerful tool that has a learning curve in order to use it.
While git is primarily used in software development, it doesn’t have to be. In fact, you could use it for any collection of files that receive changes. It’s not uncommon to see it used for technical writing , wikis, or large collaborative documents. I recall seeing a compelling argument that it could be used for drafting legislation, although I’m not aware of any government which uses it for that purpose.
Some people argue about whether or not you should use git with non-text files because the changes are much larger, but you don’t have to rigidly follow dogma.
I knew a guy who liked to use git for his RPG campaign notes. The main branch held his setting info, and when he’d run a game he’d create a new branch. If he was pleased with the game and wanted to enshrine it in canon, he’d merge it into main. Otherwise, he could leave the branch alone, but he’d still always be able to go back and look at the adventure with the details of the setting as it was at that time. I thought it was overkill, but he had fun.
Git is what’s known as “Version Control Software” which basically means that it keeps track of the changes you make.
It’s primarily used for software development, and where it shines is when multiple people are collaborating on a project which will receive many changes. You can create a “branch” of the project with the changes you want to “commit” and then after they’re reviewed in a “pull request” you can “merge” them back inyo the main branch. If at any point in the process you discover that the changes cause issues, a history allows you to “revert” those changes back to what you had previously.
As you can probably see, there’s a fair bit of terminology in git. It’s a powerful tool that has a learning curve in order to use it.
While git is primarily used in software development, it doesn’t have to be. In fact, you could use it for any collection of files that receive changes. It’s not uncommon to see it used for technical writing , wikis, or large collaborative documents. I recall seeing a compelling argument that it could be used for drafting legislation, although I’m not aware of any government which uses it for that purpose.
Some people argue about whether or not you should use git with non-text files because the changes are much larger, but you don’t have to rigidly follow dogma.
I knew a guy who liked to use git for his RPG campaign notes. The main branch held his setting info, and when he’d run a game he’d create a new branch. If he was pleased with the game and wanted to enshrine it in canon, he’d merge it into main. Otherwise, he could leave the branch alone, but he’d still always be able to go back and look at the adventure with the details of the setting as it was at that time. I thought it was overkill, but he had fun.