This guide follows Your first repository. Run these commands inside your local repository folder. The examples use main as the default branch and origin as the Pillion remote; use your repository’s names if they differ.
1. Start from the latest shared version
git statusThis shows your current branch and any changes you have not committed. A clean working tree means there are no uncommitted changes for Git to report. If you have work in progress, finish and commit it on its current branch before following the next steps.
git switch main
git pull --ff-onlyswitch selects your local main branch. pull downloads changes and updates it. --ff-only allows an update only when your branch can move forward without combining divergent histories. If it refuses, use the sync troubleshooting steps below.
2. Make a branch for the task
git switch -c add-usage-notesThis creates and selects a branch called add-usage-notes, starting at your current commit. Choose a new descriptive name for each task, such as fix-login-link. Your changes will belong to this branch when you commit them.
3. Edit, inspect and commit
Open README.md in your editor, make a change and save it. Then inspect what changed:
git status
git diffstatus lists the files; diff shows unstaged changes to tracked files. A new, untracked file appears in status but is not shown by this diff command. If Git opens a scrolling view, press q to leave it.
git add README.md
git diff --staged
git commit -m "Explain how to use this repository"add stages the file. diff --staged shows exactly what the next commit will include. commit -m records those changes with the message you supply. Replace the filename and message to match your task; stage each intended file explicitly.
Run git status again. Any remaining changes have not been included in that commit. To inspect recent commits, use git log --oneline -5.
4. Share the branch on Pillion
git push -u origin add-usage-notesThis publishes the branch. The -u option remembers the matching remote branch, called its upstream. Later pushes from this branch can use git push alone.
Open a pull request on Pillion to propose merging it into main. To address review feedback, edit, stage, commit and push on the same branch. The existing pull request updates with those commits.
5. Bring the merged change back
After the pull request is merged, check that your working tree is clean, then update your local default branch:
git switch main
git pull --ff-onlyYou should now see the merged change in your local files. Create a fresh branch from this updated main for your next task. Deleting a branch on Pillion does not delete the corresponding branch on your computer; keeping an old local branch is harmless.
When a push or pull is refused
A rejected push can mean someone else has pushed to the same branch since you last updated. A fast-forward-only pull can be refused when your local branch and its remote have different new commits. Your local commits are still there.
git status
git fetch origin
git log --oneline --graph --all -12Fetch downloads remote history without changing your working files or merging it. The log shows recent commits on your branches. Check the branch name, the rejection message and the graph before deciding what to combine.
If you deliberately share a feature branch, first commit your work, stay on that branch and merge its remote version: for example, git merge --no-edit origin/add-usage-notes. Resolve any conflicts, check the result and push. If your local main has unexpected commits, ask a teammate to help preserve them on a feature branch before updating it. Do not use force push to make an unexplained rejection disappear.
Resolve a merge conflict
To bring the latest default-branch changes into your feature branch, first commit your edits and check that git status is clean. Then, while on the feature branch, run:
git fetch origin
git merge --no-edit origin/mainIf the merge finishes without conflicts, check the result, run your project’s tests and use git push to share the updated branch.
If Git reports conflicts, use git status to find the affected files. Open them in your editor. A text conflict usually marks the alternatives with <<<<<<<, ======= and >>>>>>>. Edit the file to the intended final result and remove the markers. Sometimes the right result includes parts of both versions.
After resolving every listed conflict, check the files and run your project’s tests. For a conflict in README.md, finish with:
git add README.md
git commit -m "Merge main and resolve the README conflict"
git pushStage each resolved file if more than one conflicted. If you need to stop an unfinished merge and start again, git merge --abort attempts to return to the state before it began. Starting with a clean working tree makes that recovery more reliable. The Git merge manual explains the details.
Fix a mistake without losing work
Staged the wrong file? In a repository with a commit, git restore --staged README.md removes it from the staging area while keeping your edits in the working file. See the Git restore manual.
Committed the wrong text? Edit it, stage it and make another commit. If the branch is already on Pillion, push the correction to the same branch. This leaves an understandable record of the fix.
Need to undo a whole shared commit? Git’s revert command records a new commit that reverses an earlier change. Ask a teammate for help with merge commits or conflicts, and propose the correction through a new pull request when changing a protected branch.
Keep generated files and credentials out of commits
A .gitignore file lists untracked files Git should ignore, such as local settings and generated output. For example:
.env
node_modules/
dist/Use patterns that fit your project and commit the .gitignore file itself. Ignore rules do not remove files already tracked or erase earlier commits. If you accidentally share a token or password, revoke or rotate it first; deleting the file in a later commit leaves the old value in history.
For more about updating a local branch, see the Git pull manual.