Git commands I use regularly as a Software Engineer
There are possibly thousands of "Git cheatsheets" floating all over the internet. Those have never worked for me since you never really need to remember 50 different commands to get everyday work done.
Here are git commands I use regularly in my daily work.
-
Check which branch you're on and whether you have any uncomitted files or merge conflicts
git status
-
Update master branch (or the branch you want to create a feature branch from)
git checkout master git fetch origin git reset --hard origin/master
-
Create new feature branch from current branch
git checkout develop git checkout -b feature/new-feature
If you want to specify which branch should the new branch be based on, add it as the last parameter.
git checkout -b new-feature master
To get a new branch from a remote source, specify the remote as well.
git checkout -b new-feature origin/new-feature
-
Push your local changes to a remote branch
Stage
git add --all
I personally like using the VSCode Git UI to preview changes and stage files one by one instead of using the above command. But if you're sure you want to push all your changes, then above command is useful to stage everything instantly.
Commit
git commit -m "Add new-feature"
Push
git push -u origin new-feature
Above push command is needed only once. This is used to create a new branch in the origin remote repository and link it to your local one. Afterwards, you can use
git push
without any parameters.You can create a Pull Request after this step.
-
Update your fork's
main
branch with new merged feature. This is typically required in open-source contributions. After your feature branch pull request is merged intoupstream
, your fork'smain
branch becomes outdated.git checkout main git pull upstream main git push
-
Pull changes from a branch into existing branch
git pull --rebase origin master
This might give merge conflicts. To solve merge conflicts, check the files which have conflicts using
git status
, make the changes, then continue applying remaining commits for the pull.git add filename.tsx git rebase --continue
If at any point during the rebase you don't know how to solve the conflicts, you can cancel the rebase to reset everything and get back to where you started.
git rebase --abort
If you're just trying to get a Pull Request merged, doing a regular
git pull
instead of rebase would often give you lesser code conflicts. But it messes up the git history so make sure you complete that Pull Request with a Squash Merge. -
Merge a feature branch locally. It's recommended to create a Pull Request to the target branch instead and syncing with the remote repository. Merging branches locally avoids the review process.
git checkout develop git merge new-feature
-
Delete a branch
Local
git branch -d new-feature
Remote
git push -d origin new-feature
-
Resolve merge conflicts in a Pull Request
git checkout feature/new-feature git pull origin develop
Use
git status
to see which files have conflicts. Edit files to resolve conflicts. Then push changes.git add . git commit -m "Resolve PR #12 merge conflicts" git push origin feature/new-feature
If you're comfortable with the concept of rebase, prefer that way instead as shown in point 6 above.
-
Roll back to a commit. This will remove changes from both local and remote.
git reset --hard old-commit-id git push -f remote-name branch-name
-
Undo last commit. This will effectively reverse the last
git commit
and you won't lose the new changes you made.git reset --soft HEAD~1
-
View last n commits. If you work with a remote repository then you can just see the commits from the UI but this is helpful when doing rebases with merge conflicts to make sure you're at the right place before you make the force push.
git log -n
Tips
-
Evaluate the correct workflow for your team. Different strategies suit different kinds of projects and teams.
- Gitflow Workflow when working in a team and there's a need of testing large features not ready for release.
- Feature Branch Workflow when working individually and rapidly pushing new features to production.
- Forking Workflow when contributing to open-source.
-
Enforce a branch policy for your
master
/main
&develop
branches that allows only squash merges. Regular and Rebase merges work fine when everyone in the team knows how to correctly write a git history but more often than not people are just trying to get their code merged one way or the other. A squash merge strategy is one that stays out of your way the most and creates the least problems in a team of developers with varying expertise levels. -
Always make changes in feature branches. Never directly commit to the project's primary branches used for releases and user acceptance tests.
Have questions? Discuss on Twitter