Git is a distributed version control system that tracks changes to files over time. Every team member holds a full copy of the project history on their local machine, so work can continue offline and merges happen explicitly when you are ready.
- Repository — a directory tracked by Git, containing all project files and their full change history
- Commit — a snapshot of staged changes saved to the local repository, identified by a unique hash
- Branch — an independent line of development; the default branch is usually called
main or master
- Merge — combining changes from one branch into another; Git resolves non-overlapping changes automatically and flags conflicts for manual review
- Push — upload local commits to a remote repository so teammates can access them
- Pull — download and integrate remote commits into your local repository
The four areas Git works with:
- Workspace — your local folder with actual files; changes here are untracked until staged
- Staging area — a holding area where you select which changes to include in the next commit
- Local repository — your personal copy of the full project history, stored in the
.git folder
- Remote repository — the shared server-side repository (GitHub, GitLab, Bitbucket, or self-hosted) that the team pushes to and pulls from
| Command | What it does |
|---|
git clone <url> | Copy a remote repository to your local machine |
git branch <name> | Create a new branch |
git add <file> | Stage a file for the next commit |
git commit -m "message" | Save staged changes to the local repository |
git push | Upload local commits to the remote repository |
git pull | Download and merge remote commits into the current branch |
git merge <branch> | Merge another branch into the current one |
git stash | Temporarily save uncommitted changes |
While Git itself is a command-line tool, most teams use a hosting platform for the remote repository:
- GitHub — the most widely used platform; excellent for open source and team collaboration with pull requests, Actions CI/CD, and project boards
- GitLab — a complete DevOps platform with built-in CI/CD pipelines, container registry, and issue tracking; can be self-hosted
- Bitbucket — integrates natively with Jira and Confluence; well suited for teams already in the Atlassian ecosystem
Git servers can also be hosted on your company's internal network, keeping database models and sensitive files entirely within the organization.
- Organize by database — create a separate folder for each database (e.g.,
/production-db, /analytics-db). This keeps schemas isolated and avoids accidental cross-project changes.
- Use a
/shared subfolder — place .dbs files or SQL scripts shared across team members here, labelled clearly with the object name and version.
- Branch per environment — maintain long-lived branches for
dev, staging, and production. Changes flow from dev → staging → production through pull requests.
- Small, descriptive commits — commit one logical change at a time with a message like
Add customer_orders table rather than bundling unrelated changes.
- Resolve conflicts early — pull frequently so your branch stays close to
main; the longer a branch diverges, the harder conflicts become to resolve.
- Use pull requests for shared tables — for changes that affect shared schema objects, open a pull request so teammates can review the diff before it is merged.