How it works
Git is a distributed version control system. It records changes to files in a project so the team can review history, create separate lines of work, and merge changes. Each local copy of the repository can keep the history needed to work, even without a continuous connection to a remote server.
A change usually goes through steps. The person modifies files, selects what to include, creates a commit with a description, and when needed, pushes the changes to a remote repository. A branch lets you develop a task separately from the main branch. Then the changes can be reviewed and integrated.
Git is not the same as GitHub. Git is the version control tool; GitHub is a service that hosts repositories and offers collaboration features. There are other hosting services, and it is also possible to use Git without publishing the project on an external platform.
Practical example
A developer needs to fix a bug without mixing the task with other changes. She creates a branch, edits the code and runs tests. Then she reviews what changed, prepares a commit and shares the branch for review.
If the review requests adjustments, she can make new commits on the same branch. After approval, the changes are integrated into the main branch according to the team's process. If something goes wrong, the history helps identify when a change was introduced and which files were affected.
Before sharing a repository, check if it contains secrets, private files or data that should not be published. Git records history, so removing a key only from the current version may not remove it from previous versions. If a secret is sent by mistake, follow the revocation or rotation procedure, in addition to fixing the history when appropriate.
What it is for
Git is used to track changes in code, documentation, configurations and other project files. It facilitates collaboration, review and recovery of previous versions. Teams also use it to compare changes and keep clear records of technical decisions.
In projects with AI agents, Git offers a way to inspect what was modified before accepting a suggestion. The commit makes changes identifiable, and branches can isolate parallel tasks. Still, review the diff and run tests: having a history does not guarantee that the code is correct or safe.
Git is useful for individual work too. Small, descriptive commits help understand progress and separate tasks. It is not necessary to push every commit to a remote service, but keeping backups and following a collaboration strategy reduces the risk of losing work.
Best practices
Use messages that explain the intent of the change, keep each change focused and check the repository state before running operations that rewrite history. Avoid destructive commands when you do not know exactly which files will be affected.
Read the project instructions about branch names, review and integration. Different flows may use different conventions, but the principle is the same: make changes traceable and facilitate collaboration without exposing improper data.