Some notes for git for better memory

Git is open source control management or what's referred to as SCM.

• Working file: your editable files
• Track: keep an eye of the files
• Stage: ready for commit
• Commit: take a snap shot

Git

Basics

Initialize a git project:

git init

• Track and Stage: git add fileName.

  Track or stage all the files: git add . or git add --all or git add -A

• Untrack: git rm --cached fileName, git will not track it anymore

• Unstage: git resotre --staged fileName, retrieve from the stage

• Ignore: .gitignore

  # ignore files
  *.txt
  # ignore folder in root
  /folder/
  # ignore folder names
  any_folder/

• difference from last commit: git diff

• Commit: taking a snapshot of your repository at this point in time

  git commit -m 'your_message' or just git commit and enter the message in vim.

  Edit last commit: git commit --amend , it will not create a new commit, just edit the last one.

• Restore:

  Restore from stage: git restore fileName

  Restore from last commit: git restore --cached fileName

  Restore from specific commit git restore --source <commit> fileName

• Reset:

  git reset hashCommitTag

  --soft: Reset Head to that commit with staging not changed.

  --mixed (default): Reset Head and staging. Useful to retrieve to specific commit while not changing the Working Files.

  --hard: Reset Head, staging and Working Files. Completely reset to that stage.

• History:

  git log

  brief view git log --oneline

  see what have been changed: git log -p

Git Operations:

• git mv: automatically updates git tracking , while mv will only delete the old file and create a new file, you still have to delete the old file in git and track the new file.
• git rm: remove the file from working files and git. While rm only removes the working file, you still have to remove the git file.

Branch

• Create a new branch: git branch newBranchName

  Create a new branch based on the commit of current Head.

  Confirm how many branch we have: git branch

• Rename branch: git branch -m newName

• Switch branch: git switch newBranchName

  Switch and create a new branch: git switch -c newBranchName

  Go back to main branch: git switch main

• Merge branch to current branch: git merge -m 'message' newBranchName

  If main have been changed, there will be a merge conflict. We have to manually edit the file and commit.

• Delete branch: git branch -d newBranchName

Git for GitHub

git config --global user.name username

git config --global user.email email

• create a new repository on the command line

  echo "# git_test" >> README.md
  git init
  git add README.md
  git commit -m "first commit"
  git branch -M main  # force rename, overwrite if exists

• add origin

  git remote add origin [email protected]:Xingfu-Yi/git_test.git

• push

  Push current branch to the main branch in github

  git push -u origin main

  Push all branches to GitHub: git push --all

  git push --all -u origin main

• fetch:

  git fetch origin
  git log origin/main
  git merge origin/main

  git pull equals to git fetch && git merge

GIT LFS

Install Git LFS in git repository: git lfs install,

Ff don't want to download LFS file by default when cloning the repository, run:

git lfs install --skip-smudge
# or set when cloning
GIT_LFS_SKIP_SMUDGE=1 git clone ***

Track LFS file:

git lfs track "*.bin"
git lfs track "*.safetensors"

[Optional: clean git file after git reset --hard]

git reset --hard HEAD~1
git reflog expire --expire-unreachable=now --all
git gc --prune=now --aggressive

Clone:

git clone <url>
git checkout -b <branch-name>
git checkout <tag>

git lfs pull
# or only pull one folder
git lfs pull --include="folder_name/**"

Standard Version

Process

Install standard-version:

npm install -g standard-version

Initialize package.json:

npm init -y
# modify package.json as you want
git add package.json
git commit -m "chore: add package.json"

Generate Version:

npx standard-version --first-release
# or
npx standard-version

Push:

git push origin main --follow-tags
# or
git push origin main
git push origin main --tags

Conventional Commits

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• type
  • fix: bug fix
  • feat: new feature
  • chore: system and tools built that does not affect the code logic
  • docs: change the documentation
  • style: code style
  • refactor: code refactor that does not affect the code logic
  • perf: improve the performance of code
  • test: add test
  • build: like webpack, npm etc.
• scope
  • An optional field representing the sphere of influence, for example feat(auth): add login feature represents the authentication module.
• description
  • the first letter should be in lower case and do not add . in the end
• body
  • detailed description, can be written in multiple lines
• footer
  • BREAKING CHANGE: will increase the version from n.x.x to n+1.x.x
  • Issue/Task Reference: cite the reference. Fixes #commit_id

Benefits

Using the Conventional Commits specification brings several advantages:

1. Automatic Changelog Generation: Since commit messages are structured clearly, tools like standard-version or conventional-changelog can automatically generate a changelog, eliminating the need for manual editing.
2. Automated Version Management: By parsing commit messages for feat and fix, tools can automatically determine the version increment according to semantic versioning. For example:
   • BREAKING CHANGE increases the major version (e.g., from 1.0.0 to 2.0.0).
   • A feat commit increases the minor version (e.g., from 1.0.0 to 1.1.0).
   • A fix commit increases the patch version (e.g., from 1.0.0 to 1.0.1).
3. Clear Commit History: With standardized commit messages, team members can quickly understand the purpose and content of each change.
4. Easier Collaboration and Code Review: When team members follow a consistent format for commit messages, reviewing code and locating issues becomes more efficient.