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.

  1. Check which branch you're on and whether you have any uncomitted files or merge conflicts

    git status
    
  2. 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
    
  3. 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
    
  4. 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.

  5. 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 into upstream, your fork's main branch becomes outdated.

    git checkout main
    git pull upstream main
    git push
    
  6. 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.

  7. 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
    
  8. Delete a branch

    Local

    git branch -d new-feature
    

    Remote

    git push -d origin new-feature
    
  9. 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.

  10. 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
    
  11. 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
    
  12. 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

  1. Evaluate the correct workflow for your team. Different strategies suit different kinds of projects and teams.

  2. 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.

  3. 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

Last Updated -