Skip to content

Git commands

Jump to bottom
Joel B edited this page May 12, 2026 · 1 revision

This page is a reference for Git commands used in this project. Beginners should start with the Contributor workflow page first to understand how we work.

If you do not have the repository yet

git clone https://github.com/blomma-dev/pynventory.git
cd pynventory

Always start from an up-to-date master

git checkout master
git pull origin master

Creating a branch

The recommended way is from a GitHub issue:

  1. Open the issue.
  2. In the issue sidebar, find Development.
  3. Click Create a branch.
  4. Keep the default branch name.
  5. Copy and run the commands GitHub shows.

Manual branch names use these prefixes:

  • feature/ - new functionality
  • fix/ - bug fixes
  • chore/ - cleanup, refactoring, documentation

Examples:

git checkout -b feature/search-by-name
git checkout -b fix/delete-confirmation
git checkout -b chore/refactor-functions

Staging and committing

Commit often with clear messages:

git add .
git commit -m "add search command with partial name matching"

Commit messages

A good commit message:

  • has a short subject line (50 characters or less)
  • is written in the imperative mood: "add search" not "added search"
  • has a blank line, then a longer description if needed

Good example:

fix crash when deleting a product that does not exist

The program would raise an IndexError if you tried to
delete an ID that was not in the table. Now it checks
first and shows a clear message.

Avoid vague messages like "update code" or "fix bug".

Pushing your branch

git push origin your-branch

Keeping your branch up to date with master

If someone merged something to master while you were working, you should update your branch.

Option 1: Merge (recommended for beginners)

git checkout master
git pull origin master
git checkout your-branch
git merge master

If there are conflicts, fix them, then commit the merge.

Option 2: Rebase (cleaner history)

git checkout master
git pull origin master
git checkout your-branch
git rebase master

Rebase rewrites your branch history to place your commits on top of the latest master. This produces a cleaner, linear history.

When to use which:

  • Use merge if you are new to Git or unsure. It is safer and easier to undo.
  • Use rebase if you want a clean history and are comfortable with Git. Never rebase a branch that someone else is also working on.

Resolving merge conflicts

A conflict happens when Git cannot automatically combine changes. Here is how to handle it:

  1. Git will tell you which files have conflicts. Run:
git status
  1. Open the conflicted file. You will see markers like this:
<<<<<<< HEAD
your changes
=======
changes from master
>>>>>>> master

  1. Edit the file to keep the correct code. Remove the <<<<<<<, =======, and >>>>>>> markers.

  2. Stage and commit the resolved file:

git add path/to/resolved-file.py
git commit -m "resolve merge conflict in resolved-file.py"
  1. If you were rebasing, continue:
git rebase --continue

If you get stuck, ask for help. It is better to ask than to lose work.

Undoing mistakes

Unstage a file (not yet committed):

git restore --staged data/products.db

Discard changes in a file (not yet staged):

git restore path/to/file.py

Amend the last commit (fix a mistake in your most recent commit):

git add corrected-file.py
git commit --amend

This replaces your last commit with a new one. Only use this on commits that have not been pushed yet.

Undo a commit you already pushed:

git revert <commit-hash>

This creates a new commit that undoes the changes. It is safe for shared branches.

Reset to a previous state (dangerous, only on local branches):

git reset --hard <commit-hash>

This throws away all commits after the specified one. Never do this on a branch others are using.

Stashing work (context switching)

Sometimes you need to switch branches but have unfinished changes. Use git stash:

git stash

This saves your changes and gives you a clean working directory. Switch branches, then come back:

git checkout your-branch
git stash pop

git stash pop restores your changes and removes them from the stash. If you want to keep them in the stash, use git stash apply instead.

Check your stashed changes:

git stash list

Recovering from a bad rebase with reflog

If a rebase goes wrong, git reflog can save you. The reflog records every change to your branch tips, even if commits seem lost.

git reflog

You will see something like:

a1b2c3d HEAD@{0}: rebase: some commit
e4f5g6h HEAD@{1}: rebase (start): some commit
h7i8j9k HEAD@{2}: commit: your last good commit

Find the commit you want to return to, then:

git reset --hard h7i8j9k

This restores your branch to that point. The reflog is your safety net. Do not panic if you lose work during a rebase.

Checking what changed

See what files changed:

git status

See the actual changes:

git diff

See changes in a specific file:

git diff path/to/file.py

See your commit history:

git log --oneline -n 10

See what changed in a specific commit:

git show <commit-hash>

Clone this wiki locally