git commands

[RaenonX]

Concepts

You are working at your local computer. The code is also stored remotely at the origin.

You pull the code from the server / origin; you push your code from the local to the origin.

The most recent commit at the current branch is HEAD.

It's recommended to either commit or stash before you execute any of these commands except git commit, so you may save time on solving conflictions (if any) and/or reduce the risk of losing your work.

I personally recommends PyCharm as it provides some robust git controls. Despite of this, there are still many cases that you will find terminal/cmd/shell/bash useful than the IDE. So I will say, get an IDE for commit, solving conflictions; use terminal for other things.

• Create a JetBrains account with school email, and apply for the educational license, then you can use most of their IDEs for FREE.
• Also, if you are trying to play with the commands around, you won't need to be afraid of losing your works, because you can use its Local History feature to restore your code to almost any point of time. (I still recommend you to create a dummy history to play this fire though)

Basic Commands

Commit

git commit -m "YOUR_MESSAGE"

• Refer to #7 to see the preferred commit message format.
• Don't contain a lot of changes in a single commit. Once you've done implementing a feature and passed the tests, commit it.
• Do things listed in #11 to reduce the need of amending your commits (will be mentioned later)

Push

git push

• Push your code to the origin.
• Before I automated the process in #11, I used to commit some locally without pushing it. Once I think that I am ready to go without any errors and possible changes, I will push all of them at once.
  • If you automated the process in #11, you may not need to stage the commit locally.
  • git push pushes all not-yet-pushed commits.

Pull

git pull

• Pull the code from the origin.
• Recommended before you start your work to avoid wasting time on fixing conflicts.
• If you're using PyCharm, you can download this plugin called GitToolBox to auto fetch for you.
  • The auto-fetch mentioned above runs git fetch, which only check and download the progress of the origin, instead of overwriting your code, which git pull does. You can check this link for a better/clearer/detailed explanation.

Advanced Commands

Force push

git push -f

• Force update your commit history at the origin. Once you've executed this, the commit history at the remote side will be completed overwritten by your local commit history. Be careful when you execute this!

Rebase interactively

git rebase -i <REF>

<REF> can be (not limited to):

• HEAD~#: count of commits counting from and including the head.

  • For example, HEAD~2 means 2 commits from the head and including the head.

• <SHA>: commit hash. Preferably a short commit with 7 or 8 characters would be sufficient.

  • For example, 3508c81 will start the rebase from the initial commit of this repo.

• After you executed this message, your default text editor will pop up, check the comments inside.

  • The commits are listed with the oldest at the top.
  • Only commit hashes matter. If you apply squash (merge commits) or reword (edit commit message) command, you will be prompt to enter the new commit message once the rebasing process reaches there.
  • That is, if you want to squash the commits (merge 2 to be 1), the first line will be pick command, and the second line will be squash command.

Amend commit

git commit --amend

• This is similar to squash in interactive rebase git rebase -i, except that you don't need that complicating process for merging commits under this situation.

• Amend your previous commit, which means your new change will be merged into the last commit.

  For example, say you have the following changes and the commit message:
  
  ADD - New feature
  =================
  + feature.py
  + feature_base.py
  
  If I added a file called feature_adv.py and did some changes in feature.py, and it should be in the same commit of ADD - New feature:
  M feature.py
  + feature_adv.py
  
  Then once I execute this command, the change will then be
  
  ADD - New feature
  =================
  + feature.py
  + feature_base.py
  + feature_adv.py

• Commit message can be changed after you executed the command.
• This command is especially useful if I accidentally commit something that is a halfway work and I've done it and want to commit my whole work as one commit.
• Kinda alternative to the above. I can commit and push my halfway work as a "backup," then to amend and force push the commit once I've complete my works.

Rebase

git rebase <BRANCH_NAME>

• This might be used if you checked out from master at the 1st commit, but a commit was made to the master branch, and you haven't done working on your branch, but you want to synchronize the change on master into your dev branch.
  • Execute git rebase master if this happens.
  • Be sure that your working tree is clean (no files changed, the current status is as same as the origin) before you execute this to minimize the time on solving conflictions if any.
  • If you want to save your work, you may use PyCharm's shelf function or use git stash.
  • An IDE is recommended under this case (PyCharm again!) because you will find it easier to merge your changes when you're solving conflictions if any.

Usual Workflow

Modify the commit that you've already pushed

(This could happen quite frequently)

Scenario

You pushed a commit, and found that despite you passed the tests locally, GitHub Actions tests did not pass, and it's clear that you are the one responsible for it. After you applied some fixes, you want to amend the pushed commit.

Command

git commit --amend
git push -f

Explanation

• You, as usual, amend the commits locally first. (git commit --amend)
• Then, because that your local history differed from the one on the origin, you want to overwrite it, because your local version of the commit history is the real one. (git push -f)
• If you simply push it (git push), you'll find that you need to either commit your changes first then pull, then push, or to stash your changes first, then pull, then push. You'll find that eventually you are creating 2 commits instead.

Squash old commits

Scenario

You find that after you committed A, B and C, A and B are actually the same thing, and it should be squashed into A. However, all of these commits were already being pushed to the origin.

Command

git rebase -i HEAD~3

Then after your text editor pops up with the rebasing commands, change it from:

pick aaaaaaa A
pick aaaaaab B
pick aaaaaac C

to:

pick aaaaaaa A
squash aaaaaab B
pick aaaaaac C

Save the file, close the editor, then the text editor will pop up again, prompting you for the new commit message of aaaaaaa with something similar to this:

# 1st commit message

A

# 2nd commit message

B

Change it to what you want. Assuming we are going to change the new commit message as "AAAAA":

AAAAA

Save it then close the editor.

The rebase will then continue.

After you completed the rebase, run this:

git push -f

Explanation

• You initiate an interactive rebase, and rewrite the storyline of the commit. (git rebase -i)
• You typed in the new outcome you desired (changes in 2 pop ups of the text editor)
• Then, because that your local history differed from the one on the origin, you want to overwrite it, because your local version of the commit history is the real one. (git push -f)
• If you simply push it (git push), you'll find that you need to either commit your changes first then pull, then push, or to stash your changes first, then pull, then push. You'll find that eventually you are creating 2 commits instead.