Git can feel overwhelming for newbies, especially if you are a DBA or a new DBRE who is suddenly expected to use it every day. The best thing you can do is build a consistent workflow. Over the years, I have learned that consistency creates real muscle memory, and you are far less likely to make mistakes because anything outside your normal flow forces you to slow down and think.
I have simplified my own steps into a workflow that keeps me out of trouble, keeps my branches clean, and makes everything a lot less painful. I started using Git about ten years ago, and the good news is that it has not changed much. If you are mentoring beginners, stepping into a DBRE role, or just want muscle memory steps that work every single time, this is for you.
Clone the Repo
If you are making a change for the first time, you will need to clone the repository locally. This means you are taking a copy of the code in the repo and pulling it down to your laptop.
git clone git@github.com:username/repo.gitStart With a Clean Slate
If you already have the repo and you are about to start work, always sync your local copy first. This prevents surprises when you try to merge or push.
git fetchgit pullThis brings your local branch up to date with the remote. If you skip this step, you will eventually hit a merge conflict at the worst possible time.
Create a Branch for Every Change
Never work directly in main or master.
Always create a branch, even for small fixes.
git switch -c myBranchNameThis keeps your work isolated and makes code reviews much easier.
Some are use to creating branches the old way, that works too.
Make Your Changes and Track Them
After editing your files, stage your changes:
git add .Or if you want everything, including deletions:
git add --allCommit Your Work
Use clear commit messages. Do not be cryptic because your future self and your reviewers will appreciate the clarity.
git commit -a -m "Fix issue with login validation"Push Your Work
Once you are ready:
git pushYour work is now in GitHub and ready for a pull request.
Keep Your Branch Updated Before a Pull Request
If other people have committed changes to the branch you originally branched from, such as main or master, you need to update your feature branch before opening your pull request.
This prevents the situation where you see thousands of unexpected file changes.
git fetchgit pull origin mainResolve any conflicts, push again, and continue with your pull request.
Muscle Memory Shortcut
Once you get comfortable, you will probably use this often:
git add --all && git commit -a -m "my message" && git pushI use this when I am deep in a problem and want a quick checkpoint.
Best Practices
I have posted a full blog on best practices before, but here are a few quick ones that matter:
- Do not push a large batch of changes at once. Smaller changes are easier to review and easier to roll back if needed.
- Do not keep using old branches. Delete them when you are done.
- Always write detailed commit messages that explain what changed.
These habits keep your workflow clean and prevent confusion for everyone involved.
Final Thoughts
A consistent workflow makes a difference. If there is something you would like to add please leave comments below, I’d love to hear them.
Simple steps. Fewer mistakes. Cleaner repos.
GIT WORKFLOW CHEAT SHEET
Here is a list you can copy and paste to your local for a cheat sheet later.
#Clone
git clone git@github.com:username/repo.git
#Update repo
git fetch
git pull
#Create a new branch
git switch -c newBranch
#Checkout existing branch
git checkout newBranchNameHere
#Stage changes
git add .
#or
git add --all
#Commit with message
git commit -a -m "message"
#Push changes
git push
#Update your branch with changes from another branch
git fetch
git pull origin different-branch
#Muscle memory
git add --all && git commit -a -m "message" && git push
Leave a Reply