Amending
Branches
Reseting
Rebasing
git amend
allows the last commit to be fixed
This is very useful to rewrite commits that were done too soon
Greatly helps with keeping a clean history
git commit --amend
:
→ adds all newly staged items into the latest commit
→ calls the editor to write the new commit message
For short, you can use:
git commit --amend -m "MESSAGE"
git
allows development to take place in multiple branches
Branches allow different teams to work on different tasks in parallel - alternate realities
Branches also allow for quickly dumping out bad ideas
Working on the main branch is not a great idea
You can create branches with:
git branch BRANCH_NAME
Move to a new branch with:
git checkout BRANCH_NAME
or git switch BRANCH_NAME
You can merge the changes from one branch into another:
→ First, checkout or switch to the branch that should receive the changes
→ Second, merge all changes with the command:
git merge BRANCH_NAME
→ Third, delete obsolete branches with: git branch -d BRANCH_NAME
You merge the contents of one branch into another
I.e., you need to first move to the branch that will receive the changes
Than, you merge the branch that contain the changes
Two different branches changing the same lines of code: CONFLICT
Git will let you know when conflicts happen
You can review all conflicts prior to commiting a merge
git reset --hard
Sets working directory and staging area back to latest commit
Very dangerous command!
For a specific file: git restore FILENAME
git reset
or git reset --mixed
Unstage changes; does not change working directory
For a specific file: git reset FILENAME
git reset --soft
Simply updates the HEAD pointer
No change to the working directory or staging area
Normally used to combine commits: git reset --soft HEAD~3
git revert
is a safe way of undoing things
It adds a new commit, undoing the changes of a previous commit
Examples: git revert 32a2d
or git revert HEAD~2
Rebasing can be used to achieve two different goals:
→ Maintain a linear project history
→ Rewriting past history
It is normally a bad idea to rebase public history!
Merging can make a project history harder to follow
Rebase can be used to keep a linear history using the commands:
git checkout branch_name
git rebase main
See Introduction Sequence #4 from this link
You rebase the base (starting point) of a given branch
I.e., you need to first move to the branch that will be rebase
Than, you provide its new base (starting point)
Rebasing can be done interactively to rewrite past history:
git rebase -i STARTING_POINT
You can invert the order of commit, squash commits together, rewrite comments, etc.