Git gives you many commands to understand the state of your repository before you act. Used well, they prevent most conflicts at push time. This tutorial explains the key commands, their main parameters, and concrete examples.<\/p>\n\n\n\n
A safe routine before every push:<\/p>\n\n\n\n
git fetch origin # 1. update your view of the remote (does not touch your code)\ngit status -sb # 2. current state + ahead\/behind counters\ngit log --oneline HEAD..@{u} # 3. what others added that you don't have\ngit log --oneline @{u}..HEAD # 4. what you have that is not pushed yet\ngit pull --rebase # 5. integrate cleanly\ngit push<\/code><\/pre>\n\n\n\nTip: @{u}<\/code> (or @{upstream}<\/code>) is the remote branch tracked by your current branch. You no longer need to type origin\/feature\/my-branch<\/code>.<\/p>\n\n\n\n
\n\n\n\n2. Commands to Observe<\/h4>\n\n\n\ngit fetch<\/h5>\n\n\n\n
Downloads new data from the remote without modifying your working files.<\/p>\n\n\n\n
Main parameters:<\/p>\n\n\n\n
--all<\/code>: fetch from all remotes<\/li>--prune<\/code> (-p<\/code>): remove local references to remote branches that were deleted<\/li>--tags<\/code>: also fetch tags<\/li><\/ul>\n\n\n\ngit fetch --all --prune<\/code><\/pre>\n\n\n\ngit status<\/h5>\n\n\n\ngit status -sb<\/code><\/pre>\n\n\n\n-s<\/code>: short format<\/li>-b<\/code>: show the branch and its difference with the remote<\/li><\/ul>\n\n\n\nExample output:<\/p>\n\n\n\n
## feature\/my-branch...origin\/feature\/my-branch [ahead 1, behind 2]<\/code><\/pre>\n\n\n\nahead 1<\/code>: you have 1 commit that is not pushed<\/li>behind 2<\/code>: the remote has 2 commits you don’t have<\/li>- ahead AND behind means the branches have diverged, so a conflict is possible<\/li><\/ul>\n\n\n\n
git log<\/h5>\n\n\n\n
The most powerful command for observing history.<\/p>\n\n\n\n
Main parameters:<\/p>\n\n\n\n
--oneline<\/code>: one commit per line<\/li>--graph<\/code>: draw the branch structure<\/li>--decorate<\/code>: show branch and tag names<\/li>--all<\/code>: include all branches<\/li>-n 10<\/code> or -10<\/code>: limit to 10 commits<\/li>--author=\"Marek\"<\/code>: filter by author<\/li>--since=\"2 days ago\"<\/code>: filter by date<\/li>--stat<\/code>: show files changed per commit<\/li>-p<\/code>: show the full diff of each commit<\/li>-- <file><\/code>: history of a single file<\/li><\/ul>\n\n\n\ngit log --oneline --graph --decorate --all -15\ngit log --author=\"Marek\" --since=\"1 week ago\" --stat\ngit log -p -- estaTektonPipeline.json<\/code><\/pre>\n\n\n\nThe .. and \u2026 notations<\/h5>\n\n\n\nA..B<\/code>: commits that are in B but not in A<\/li>A...B<\/code>: commits that are in A or B, but not in both (symmetric difference)<\/li><\/ul>\n\n\n\ngit log --oneline HEAD..origin\/feature\/my-branch # what you don't have yet\ngit log --oneline origin\/feature\/my-branch..HEAD # what you haven't pushed\ngit log --oneline --left-right HEAD...@{u} # both sides at once<\/code><\/pre>\n\n\n\nWith --left-right<\/code>, <<\/code> means your side and ><\/code> means the remote side.<\/p>\n\n\n\ngit show<\/h5>\n\n\n\ngit show 72a6c875b # full commit\ngit show 72a6c875b --stat # only the changed files\ngit show 72a6c875b:estaTektonPipeline.json # the file as it was at that commit<\/code><\/pre>\n\n\n\nNote for Windows cmd: do not add a trailing # comment<\/code> on the command line. Windows cmd does not treat #<\/code> as a comment, so Git will fail with “ambiguous argument ‘#'”.<\/p>\n\n\n\ngit diff<\/h5>\n\n\n\ngit diff<\/code>: working directory vs index (unstaged changes)<\/li>git diff --staged<\/code>: index vs last commit<\/li>git diff HEAD<\/code>: working directory vs last commit<\/li>git diff A..B<\/code>: compare two commits or branches<\/li>git diff A...B<\/code>: compare B against the common ancestor (ideal to review a pull request)<\/li>--stat<\/code>: summary of changed files<\/li>--name-only<\/code>: list file names only<\/li><\/ul>\n\n\n\ngit diff @{u} --stat\ngit diff origin\/master...HEAD --name-only<\/code><\/pre>\n\n\n\ngit blame<\/h5>\n\n\n\n
Shows who last modified each line, and when.<\/p>\n\n\n\n
git blame -L 4,8 estaTektonPipeline.json # only lines 4 to 8<\/code><\/pre>\n\n\n\n
\n\n\n\n3. Commands to Avoid Conflicts<\/h4>\n\n\n\ngit pull: three strategies<\/h5>\n\n\n\ngit pull<\/code>: fetch + merge (may create a merge commit)<\/li>git pull --rebase<\/code>: fetch + rebase (linear history)<\/li>git pull --ff-only<\/code>: refuses if branches diverged (the safest option)<\/li><\/ul>\n\n\n\ngit pull --ff-only<\/code><\/pre>\n\n\n\nIf there is a divergence, it fails cleanly and you decide what to do.<\/p>\n\n\n\n
Make your preferred behavior the default:<\/p>\n\n\n\n
git config --global pull.rebase true\ngit config --global fetch.prune true<\/code><\/pre>\n\n\n\ngit rebase<\/h5>\n\n\n\n
Replays your commits on top of another branch.<\/p>\n\n\n\n
git fetch origin\ngit rebase origin\/master<\/code><\/pre>\n\n\n\nMain parameters:<\/p>\n\n\n\n
--continue<\/code>: continue after resolving a conflict<\/li>--abort<\/code>: cancel everything and return to the initial state<\/li>--skip<\/code>: skip the problematic commit<\/li>-i HEAD~3<\/code>: interactive mode (squash, reword, drop)<\/li><\/ul>\n\n\n\nGolden rule: never rebase commits that are already pushed and used by other people.<\/p>\n\n\n\n
git merge<\/h5>\n\n\n\n
Main parameters:<\/p>\n\n\n\n
--ff-only<\/code>: accept only a fast-forward<\/li>--no-ff<\/code>: force a merge commit<\/li>--abort<\/code>: cancel a merge in progress<\/li><\/ul>\n\n\n\nA dry run to preview conflicts before a real merge:<\/p>\n\n\n\n
git merge --no-commit --no-ff origin\/master\ngit merge --abort<\/code><\/pre>\n\n\n\nSafe git push<\/h5>\n\n\n\ngit push<\/code>: normal push, rejected if the remote has moved forward<\/li>git push --force<\/code>: dangerous, can overwrite other people’s work<\/li>git push --force-with-lease<\/code>: refuses if someone pushed in the meantime (much safer)<\/li>git push --dry-run<\/code>: simulates the push without sending anything<\/li><\/ul>\n\n\n\ngit push --dry-run\ngit push --force-with-lease # only after rebasing your own branch<\/code><\/pre>\n\n\n\ngit stash: set work aside<\/h5>\n\n\n\ngit stash push -m \"wip: side panel\" # stash with a name\ngit stash list # list stashes\ngit stash pop # restore and delete the stash\ngit stash apply # restore and keep the stash\ngit stash push -u # also include untracked files<\/code><\/pre>\n\n\n\nUse it before git pull --rebase<\/code> if your working tree is not clean. Shortcut: git pull --rebase --autostash<\/code>.<\/p>\n\n\n\n
\n\n\n\n4. Commands to Undo Things<\/h4>\n\n\n\n
Choose the command according to the situation:<\/p>\n\n\n\n
- Unpushed commit, keep changes staged:
git reset --soft HEAD~1<\/code><\/li>- Unpushed commit, keep changes as modified files:
git reset --mixed HEAD~1<\/code> (default)<\/li>- Unpushed commit, delete everything:
git reset --hard HEAD~1<\/code> (destructive)<\/li>- Already pushed commit:
git revert <hash><\/code><\/li>- Discard changes in a file:
git restore <file><\/code><\/li>- Unstage a file:
git restore --staged <file><\/code><\/li>- Fix the last unpushed commit:
git commit --amend<\/code><\/li><\/ul>\n\n\n\nThe safety net: git reflog<\/h5>\n\n\n\n
Even after a bad reset --hard<\/code>, you can usually recover your commits.<\/p>\n\n\n\ngit reflog # history of all HEAD movements\ngit reset --hard HEAD@{2} # go back to the state 2 moves ago<\/code><\/pre>\n\n\n\n
\n\n\n\n5. Resolving Conflicts<\/h4>\n\n\n\ngit status # lists files marked \"both modified\"\n# edit the file and remove the <<<<<<<, =======, >>>>>>> markers\ngit add <file>\ngit rebase --continue # or: git merge --continue<\/code><\/pre>\n\n\n\nUseful tools:<\/p>\n\n\n\n
git checkout --ours <file> # keep your version (during a merge)\ngit checkout --theirs <file> # keep the other version\ngit mergetool # open the configured tool (VS Code, IntelliJ)\ngit config --global merge.conflictstyle zdiff3 # also show the original version<\/code><\/pre>\n\n\n\nRebase pitfall: during a rebase, ours<\/code> and theirs<\/code> are inverted. ours<\/code> is the branch you rebase onto, and theirs<\/code> is your own commits.<\/p>\n\n\n\n
\n\n\n\n6. Handy Aliases<\/h4>\n\n\n\ngit config --global alias.st \"status -sb\"\ngit config --global alias.lg \"log --oneline --graph --decorate --all -20\"\ngit config --global alias.incoming \"log --oneline HEAD..@{u}\"\ngit config --global alias.outgoing \"log --oneline @{u}..HEAD\"\ngit config --global alias.sync \"pull --rebase --autostash\"<\/code><\/pre>\n\n\n\nThen you can run:<\/p>\n\n\n\n
git fetch && git st && git incoming && git outgoing<\/code><\/pre>\n\n\n\n
\n\n\n\n7. Searching the History<\/h4>\n\n\n\ngit log -S\"buildTaskName\" --oneline # commits that add or remove this string\ngit log -G\"password\" --oneline # commits whose diff matches this regex\ngit log --grep=\"fix(ci)\" --oneline # search commit messages\ngit log --grep=\"ITOP-9220\" --oneline # find all commits of a Jira ticket\ngit log --since=\"2 days ago\" --until=\"1 hour ago\" --oneline<\/code><\/pre>\n\n\n\n
\n\n\n\n8. Git in a DevOps Context<\/h4>\n\n\n\n- CI\/CD (Tekton, OpenShift): each push can trigger a pipeline run. Using
git push --dry-run<\/code> and a clean rebase avoids useless and expensive runs.<\/li>- GitOps (ArgoCD): the Git branch is the source of truth. A force push can desynchronize a deployment, so prefer
git revert<\/code>.<\/li>- Traceability (Jira, Confluence): keep the ticket key (for example
ITOP-1234<\/code>) in every commit message.<\/li>- Secrets (Vault): use
git log -p -S\"secret\"<\/code> or git log -G\"password\"<\/code> to detect a secret committed by mistake.<\/li>- Monitoring (Splunk): correlate an error spike with
git log --since=\"...\" --until=\"...\"<\/code>.<\/li><\/ul>\n\n\n\n
\n\n\n\n9. Best Practices<\/h4>\n\n\n\n- Make small, atomic commits: one logical change per commit.<\/li>
- Use conventional commit messages:
feat:<\/code>, fix:<\/code>, chore:<\/code>, revert:<\/code>.<\/li>- Always fetch first: look before you act.<\/li>
- Rebase your own branch, merge shared branches.<\/li>
- Never use
--force<\/code>: use --force-with-lease<\/code> instead.<\/li>- Keep pull requests short to reduce conflict risk.<\/li><\/ol>\n\n\n\n
\n\n\n\n10. Recommended Workflow<\/h4>\n\n\n\ngit fetch --all --prune\ngit lg # graph view (alias)\ngit incoming # what do I need to receive?\ngit outgoing # what am I about to send?\ngit pull --rebase --autostash # integrate\ngit push --dry-run # simulate\ngit push # send<\/code><\/pre>\n\n\n\n
\n\n\n\n11. Going Further<\/h4>\n\n\n\ngit bisect<\/code>: automatically find the commit that introduced a bug<\/li>git cherry-pick <hash><\/code>: apply a single commit from another branch<\/li>git worktree<\/code>: work on two branches in parallel without stashing<\/li>git rerere<\/code>: remember how you resolved conflicts and reuse the resolution<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"Git gives you many commands to understand the state of your repository before you act. Used well, they prevent most conflicts at push time. This tutorial explains the key commands, their main parameters, and concrete examples. 1. The Principle: Look Before You Act A safe routine before every push: Tip: @{u} (or @{upstream}) is the […]<\/p>\n","protected":false},"author":1,"featured_media":807,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[60],"tags":[1188,1185,1187,1124,1186,1135,1123],"_links":{"self":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4530"}],"collection":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=4530"}],"version-history":[{"count":1,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4530\/revisions"}],"predecessor-version":[{"id":4531,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4530\/revisions\/4531"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media\/807"}],"wp:attachment":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=4530"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=4530"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=4530"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}