Pros:
- Lower barrier of entry for beginners as compared to CLI
- Some people prefer visual experience althought they know CLI.
Cons:
- Inner workings are hidden away with GUI.
- Leads to dependence on a particular s/w.
- When things go wrong, very challenging to fix without CLI.
- Different tools, different GUIs.
Git CLI
Pros:
- All docs & resources are written for CLI as Git is a CLI tool at its core.
- Commands are always same, irrespective of the machine.
- Advanced features are available only for CLI users.
- CLI will be faster once you're comfortable with it.
-
Repository / Repo
Workspace tracking & managing files within a directory.
All repos have separate history & contents.
To make a folder a git repo, it needs to be initialized with git init
Untracked file is a newly created file present inside a repo and tracked by Git but not added to SA.
Verifying before settting up a new repo:
Always check satus of directory & ensure that its not an existing repo before initizaing a repo with git init.
Avoid nested repo. Only have 1 repo per project.
git --version
git status : current status of directory whether its a git repo or not. Also tells about the branch we are on.
Initializing & Setting up a new repo:
Ensure you're not inside an existing repo.
'git init' is done only once per project at the top-level folder. It creates a .git directory with subdirectories for HEAD, hooks, refs, config, info, description, objects.
.git is hidden such that we don't screw up the project by accessing it.
Git watches everything inside the repo directory irrespective of nesting level.
git init : initialize a git repo
rm -rf .git : delete entire git history of the project incase its initialized inside an already tracked repo.
Commits
Its a checkpoint or snapshot of the project or feature we are working over time.
Commits can be undo, deleted, merged etc. A trail of checkpoints is formed.
Multiple saved files can all be grouped together to form a single commit.
Commit will have specific changes which we want to include in that commit. First select them, then commit them.
git add highlights the changes to be included in upcoming commit.
Always be surgical while making commits instead of using git add .
WD ---(git add)---> SA ---(git commit)---> Repo
git add : Adds content from WD to SA, ready to included in upcoming commit.
git add <file-name> : Add single file to SA
git add <file1> <file2> : Add multiple files to SA
git add . : Stage all changes at once.
git add <director>/ : Will add the entire directory to SA.
git rm --cachced <file> : Unstage file from SA, without deleting from WD. File won't be tracked by Git. Usage: Use this when you want to stop tracking a file but keep it in your local working directory.
git restore --staged <file> : to unstage a file that has been added to the SA, reverting it to its state in the last commit. The file is removed from the SA but remains tracked by Git. It resets the file's state in the SA to match the last commit, without affecting the WD. Usage: Use this when you’ve staged changes with git add, but you want to undo that staging (i.e., move it out of the staging area), effectively “unstaging” the changes without modifying the working copy.
Key Differences:
Tracking vs. Staging:
git rm --cached stops tracking a file (i.e., it will be removed from version control).
git restore --staged unstages a file, meaning it simply removes the changes from the staging area, but the file is still tracked.
File Removal:
git rm --cached stages the file for deletion in the next commit (effectively removes it from the repository).
git restore --staged does not delete the file from the repository; it only moves it out of the staging area.
Commit
Record changes to the repo.
Need to provide a commit message summarizing the work included in the commit.
Avoid running just git commit as it will commit all staged changes. At the same time, opens the text editor, prompts for commit message.
git commit -m "commit-message" : -m allows us to pass a commit message inline rather than launching the text editor
How to write commits:
Make atomic commits i.e single purpose.
A commit should encompass a single feature, change or fix.
Try to keep a commit focussed on a single thing. Make it easier to undo or rollback changes if required.
Also makes easier to review code of the project.
Present tense or Orgs conventional style you're working for consistency.
We are allowed to write multiple lines of commit message also. For long commits, first line is summary of the entire commit.
Vim editor:
i = insert mode
:wq = to write & quit i.e exit after saving.
Setting VS Code as Editor instead of vim:
- git config --global code.editor "code --wait"
global = for all repos
"code --wait" = keyword for opening the editor
--wait = until editing is complete, don't close the editor
Working Directory, Staging Area, Repository:
Working Directory: Normal directory which we have. Changes made to files here will be tracked by git.
Staging Area: Intermediate step,
Repository: Actual git repo, which gets changed whenever we make a commit.
Colors in Git:
Red: Untracked file in WD || Modified file in WD [changed after committing]
Green: Tracked file in SA || Modified file in SA
Seeing older commits:
--oneline is short for --pretty=oneline--abbrev-commit
git log
git log --oneline : <commit-hash> <commit-msg>
git log --abbrev-commit : shows shorter value of commit-hash
Top comments (0)
Subscribe
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (0)