Here is a summary of the Git-related content I’ve learned.
1. Installation
- Installing Git on Windows
Download and install from the official Git website: https://git-scm.com/download/win
Run Git Bash once after the installation is complete.
- Installing Git on Linux
Debian: sudo apt-get install git
Fedora: dnf install git
CentOS: yum install git
Other references: https://git-scm.com/download/linux
- Installing Git on Mac OS X
Method 1: Install Homebrew, then install Git via Homebrew. Refer to the Homebrew documentation for details: http://brew.sh/
Method 2: Install Xcode directly from the App Store. Xcode includes Git, but it’s not installed by default. Open Xcode, go to Xcode - Preferences, find the Downloads tab, select Command Line Tools, and click Install.
Xcode is Apple’s official IDE. It’s powerful, essential for Mac and iOS app development, and free.
2. Configuration
After installation, configure your identity.
| |
Replace Your Name with your name and email@example with your email address.
3. Creating a Repository
You can create a new Git repository locally or clone it from a remote source.
Local Repository
Select a folder and execute the command:
| |
This folder is now a repository managed by Git. Do not modify the files in the ./.git directory (usually hidden). This directory is where Git tracks and manages the version history.
Cloning Your Own Repository
Add your SSH public key to your personal settings: SSH and GPG keys . Then you can clone directly using SSH, for example:
| |
Cloning a Repository You Have Access To
If the owner invites you as a collaborator or adds your key to the repository’s Deploy keys, you have write access. Use SSH to clone, modify, and push:
| |
Contributing to Major Projects
Generally, you fork the repo first, make changes locally, and then submit a Pull Request. For details, see:
How to use GitHub to contribute to big projects - idealclover
Cloning Public Repositories (No Write Access)
Just use HTTPS to clone:
| |
You can find the repo link on the project page by clicking the Code button.
4. Committing Files
Once you’ve added some files, it’s time to commit them to the repository.
Add files to the staging area:
| |
Then commit the changes:
| |
Describe what this commit does in the some details section.
Commit Conventions
While you can write anything in the commit message, it’s best to follow a convention. Here are some common prefixes:
| Prefix | Scenario |
|---|---|
| feat | Introducing a new feature (e.g., a new API for uploading avatars) |
| fix | Fixing a bug |
| refactor | Code refactoring that neither fixes a bug nor adds a feature |
| chore | Mundane tasks like updating .gitignore or Maven dependencies |
| docs | Documentation only changes (README, JavaDoc, etc.) |
You can add the specific module after the prefix, for example:
| |
Ignoring Files
If there are files you don’t want to track in Git, create a .gitignore file and list the filenames or patterns (one per line).
| |
You can force add an ignored file with: git add -f test.pyc
Check out some ready-made templates here: https://github.com/github/gitignore
If you modify
.gitignoreand need it to take effect immediately, you need to clear the cache:
1 2 3 4 5 6# Clear cache git rm -r --cached . # Re-add files git add . # Commit the changes git commit -m "update .gitignore"
5. Logs and Undoing
Use git status to see the current state of the repository.
Use git diff to see what changed since the last commit.
Use git log to see the history. Add the --pretty=oneline flag for a cleaner view with commit IDs.
If you see HEAD -> master next to a commit ID, that’s the latest commit (the current version). Git uses HEAD to represent the current version. The previous version is HEAD^, the one before that is HEAD^^, and 60 versions back is HEAD~60.
Roll back to the previous version: git reset --hard HEAD^
Roll back to a specific version:
| |
If you rolled back by mistake, don’t close your terminal. Run git reflog to find the version ID you just came from and reset back to it.
6. Remote Pushing
To push code to a remote repo, you need to link them. If you cloned from a remote, it’s already linked.
Linking a Remote Repository
If you created a local repo and want to upload it to GitHub, create a new repo on GitHub and link it locally:
| |
Pushing Code
Use the push command:
| |
This pushes to the master branch of the remote repository.
Changing Branch Names
Note that local Git repos usually default to master, while GitHub defaults to main. To keep them consistent, rename your local branch:
| |
You can also set the global default for new repos to main:
| |
Default Branch Tracking
Set the default upstream for the current branch:
| |
After this, you can just use:
| |
Managing Remotes
Check remote info:
| |
If you made a mistake linking the repository, remove it:
| |
The default name is usually origin, so: git remote rm origin.
7. Branch Management
Git branches allow you to develop features, fix bugs, or experiment without affecting the main codebase.
List branches: git branch
Create a branch: git branch new_branch
Switch to a branch: git checkout new_branch
Switch to a branch (modern command): git switch new_branch
Push to a specific branch: git push origin branch_name
Example Workflow (Adding a search feature):
First, create and switch to a new branch:
| |
Modify and test your code on the search branch, then commit:
| |
Switch back to the main branch:
| |
Merge the search branch:
| |
(Optional) Delete the search branch:
| |
8. Creating a Server
Reference: Building a Git Server and Syncing to a Specific Directory
9. Others
Using GitLab and GitHub simultaneously: document-library/Git-study.md
References
Git Tutorial - Liao Xuefeng’s Website
How to Connect a Local Repository to GitHub - CSDN Blog