- Change Control (add/restore)
- Version Control (Commits)
- Collaboration (parallel development)
- git is a version control software
- It keep track of code changes
- It helps to collaborate in a project
- It is installed and maintained locally
- It provides Command Line Interface (CLI)
- Released in April 7, 2005
- Developed by Linus Torvalds & Junio C Hamano
- GitHub is a hosting service where we can keep our git repositiory/folders
- It is maintained on cloud/web
- It provides Graphical User Interface (GUI)
- Founded in 2008
- go to this site and register with a valid email address.
- Download and install git on your pc: https://git-scm.com/
- check git version: open terminal or cmd then use the command
git --version
to find out whether git is installed or not. if git is installed it will return a version number of git.
git commandName -help
-
directoy/folder
-
dir/ls/ls – List directory contents.
-
cd – Change directory.
-
cd/Get-Location/pwdShow current directory
-
mkdir – Create a new directory. Example: mkdir directory
-
rmdir/Remove-Item/rm – Remove a directory.
Example:
rmdir /S /Q directory
Remove-Item -Recurse directory
rm -r directory
-
-
File
-
copy/New-Item/touch- Create file. Example: copy nul filename.txt / New-Item -ItemType File -Name "filename.txt" / touch filename.txt
-
echo Your content here > filename.txt / "Your content here" | Out-File -FilePath "filename.txt" / echo Your content here > filename.txt - Writing in a file.
- in mac
cat > filename.txt Your content here Another line of content Ctrl + D or printf "Your content here\n" > filename.txt to append printf "Additional content\n" >> filename.txt
-
type/Get-Content/cat - View file contents. Example: type file / Get-Content file / cat file
-
copy/Copy-Item/cp – Copy files. Example: copy source destination / Copy-Item source destination/cp source destination
-
del/Remove-Item/rm– Delete files. Example: del file / Remove-Item file / rm file
-
-
cls/Clear-Host/clear – Clear the screen.
-
echo – Display a message or turn command echoing on or off. Example: echo text / Write-Output text / echo text
Git configuration is an important part of setting up and managing your Git environment. Configuration settings in Git can be set at three different levels: local, global, and system.
- Local configuration applies only to a specific repository.
- Global configuration applies to the user across all repositories on the system.
- System configuration applies to all users on the system (rarely used).
To view configuration settings:
git config --list
git config --local --list (view local configuration settings)
git config --global --list (view global configuration settings
git config --system --list (view system configuration settings)
If you want to remove a specific configuration setting in Git, such as a user name set with git config
, you can use the git config --unset
command. Here’s how to remove a configuration setting:
cd /path/to/your/repository
git config --local --unset user.name
git config --global --unset user.name
sudo git config --system --unset user.name
Local configuration settings are stored in the .git/config
file within a specific repository. Use .git/config
commad to see what you have inside the file.
To set local configuration options:
cd /path/to/your/repository
git config --local user.name "Your Name"
git config --local user.email "your.email@example.com"
Global configuration settings are stored in the ~/.gitconfig
file (or ~/.config/git/config
depending on the system). Use open ~/.gitconfig
commad to see what you have inside the file.
To set global configuration options:
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
System configuration settings are stored in the /etc/gitconfig
file.
To set system configuration options (requires administrative privileges):
sudo git config --system core.editor "nano"
Here are some commonly used Git configuration options:
-
User Information
- Set the name and email address that will be used for your commits.
git config --global user.name "Your Name" git config --global user.email "your.email@example.com"
-
Default Editor
- Set the default text editor for Git.
git config --global core.editor "nano" # or "vim", "code --wait", etc.
-
Line Endings
- Configure how Git handles line endings between different operating systems.
git config --global core.autocrlf input # Use "true" on Windows, "input" on macOS/Linux
-
Merge Tool
- Set the default merge tool for resolving conflicts.
git config --global merge.tool "meld"
-
Diff Tool
- Set the default diff tool for viewing differences.
git config --global diff.tool "meld"
-
Aliases
- Create shortcuts for commonly used Git commands.
git config --global alias.co "checkout" git config --global alias.br "branch" git config --global alias.ci "commit" git config --global alias.st "status"
You can also directly view and edit the configuration files if needed:
-
Global configuration file:
nano ~/.gitconfig
-
Local configuration file:
nano .git/config
-
System configuration file (requires administrative privileges):
sudo nano /etc/gitconfig
Here is an example of what a typical global configuration file (~/.gitconfig
) might look like:
[user]
name = Your Name
email = your.email@example.com
[core]
editor = nano
autocrlf = input
[merge]
tool = meld
[diff]
tool = meld
[alias]
co = checkout
br = branch
ci = commit
st = status
By configuring Git at the local and global levels, you can customize your Git environment to suit your preferences and workflow. Local configuration settings are specific to individual repositories, while global settings apply across all repositories for a user. Understanding and managing these settings will help you streamline your Git operations and improve your productivity.
-
SSH, or Secure Shell, is a cryptographic network protocol used for secure communication between devices over an unsecured network. It provides a secure way to access remote systems, execute commands, transfer files, and manage network infrastructure.
-
SSH allows users to securely log into remote systems and execute commands as if they were sitting in front of the machine.
-
go to your github account
-
- type in terminal
for generating SSH Key: ssh-keygen -t ed25519 -C "your email goes here"
- type in terminal
cat ~/.ssh/id_ed255519.pub
- copy the ssh and add to github
- type in terminal
The command ssh-keygen -t ed25519 -C "your email goes here"
is used to generate a new SSH key pair (a public and private key) for secure authentication. Here’s a detailed breakdown of the command:
-
ssh-keygen
:- This is the command-line tool used to generate, manage, and convert authentication keys for SSH.
-
-t ed25519
:- The
-t
option specifies the type of key to create. ed25519
refers to the Ed25519 algorithm, which is a modern and secure elliptic-curve algorithm for SSH keys. It is known for its high security, performance, and small key size compared to older algorithms like RSA.
- The
-
-C "your email goes here"
:- The
-C
option adds a comment to the key. This comment is typically used to identify the key. "your email goes here"
is the comment that will be added to the key. It's common to use your email address here, so you can easily identify the key later.
- The
-
Prompt for a File Location:
- After running the command, you will be prompted to specify a file to save the key. By default, it will suggest a location such as
~/.ssh/id_ed25519
. - If you press Enter without specifying a location, it will use the default path.
- After running the command, you will be prompted to specify a file to save the key. By default, it will suggest a location such as
-
Prompt for a Passphrase:
- You will be asked to enter a passphrase. This is an optional step, but adding a passphrase provides an additional layer of security. If you choose to set a passphrase, you’ll need to enter it whenever you use the private key.
- If you do not want to set a passphrase, you can press Enter without typing anything.
-
Key Generation:
- The tool generates a new Ed25519 key pair and saves it to the specified file. The private key is stored in the file you specified (e.g.,
~/.ssh/id_ed25519
), and the public key is stored in a file with the same name but with a.pub
extension (e.g.,~/.ssh/id_ed25519.pub
).
- The tool generates a new Ed25519 key pair and saves it to the specified file. The private key is stored in the file you specified (e.g.,
When you run the command, the interaction might look like this:
$ ssh-keygen -t ed25519 -C "your_email@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourusername/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourusername/.ssh/id_ed25519.
Your public key has been saved in /home/yourusername/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:examplefingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| ..o. |
| .+ + |
| . o* . |
| o.O |
| .=S o |
| . + . = . |
| + o + . o |
| + o + . |
| o o.. |
+----[SHA256]-----+
-
Add the Public Key to the Remote Server:
-
Copy the contents of the public key file (e.g.,
~/.ssh/id_ed25519.pub
) to the~/.ssh/authorized_keys
file on the remote server you want to access. -
You can use the
ssh-copy-id
command for this:ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote_host
-
-
Connect Using SSH:
-
Use the SSH command to connect to the remote server. SSH will use your private key for authentication.
ssh user@remote_host
-
- Repositories
- Staging Area
- Working Directory
- Local Repositories
- Remote Repositories
- Commits
- Branches
- Merging
-
creating a git folder
-
ls -a : list all files inside of a directory
mkdir DIRECTORY_NAME_HERE cd DIRECTORY_NAME_HERE git init Example: mkdir notes cd notes git init ls -a
-
-
adding new files in git folder
-
git status : displays the state of the working directory and staging area
ls -a touch fileName.extension open fileName.extension git status Example: touch day1.txt open day1.txt write something inside the file
-
-
Git is aware of the file but not added to our git repo
-
Files in git repo can have 2 states – tracked (git knows and added to git repo), untracked (file in the working directory, but not added to the local repository)
-
To make the file trackable stagging or adding is required
-
Adding files to stagging area:
git add fileName
add a file in staging area / indexgit add .
add all files of directory to stagging area not subdirectorygit add -A
add all files of directory and subdirectory to stagging areagit rm --cached fileName
unstage a file from staging areagit diff
- checking the differences of a staged filegit restore fileName
- restore the file
git commit -m "message"
move the file to local repository from stagging areagit log
check the commit historygit reset --soft HEAD^
uncommit the commit in HEAD and move to staging areagit reset HEAD^
uncommit the commit in HEAD and move to unstaging / working areagit reset --hard HEAD^
uncommit the commit in HEAD and delete the commit completely with all the changes
- git init: Initialize a new Git repository.
- git clone: Clone an existing repository.
- git status: Check the status of your repository.
- git add: Add files to the staging area.
- git commit: Commit changes to the repository.
- git log: View commit history.
- create a .gitignore file and add the things you do not want to add in the stagging area
- Inside .gitignore we can keep secret files, hidden files, temporary files, log files
secret.txt
secret.txt will be ignored*.txt
ignore all files with .txt extension!main.txt
ignore all files with .txt extension without .main.txttest?.txt
ignore all files like test1.txt test2.txttemp/
all the files in temp folders will be ignored
- Creating a GitHub account
- Creating a new repository
- creating a readme.md
- Forking a repository
- Cloning a repository from GitHub
- Basic GitHub web interface overview
- Connecting local and remote repo
- Push and pull
- Pull Requests
- Issues
- Basic repository settings
- sign in to your github account
- create a git repo
- check remote connection:
git remote
orgit remote -v
git remote add name <REMOTE_URL>
example: git remote add origin http://...- to clone a remote repository:
git clone <REMOTE_URL>
- push a branch
git push -u origin branch_name
- push all branches
git push --all
- pull from a repo:
git pull
which is equivalent to git fetch + git merge
Working with remotes in Git involves interacting with repositories hosted on a remote server. These remote repositories can be on platforms like GitHub, GitLab, Bitbucket, or your own server. Here are key concepts and commands for working with remotes:
- Remote Repository: A repository hosted on a server, which can be accessed via URLs (HTTPS, SSH).
- Origin: The default name given to the remote repository from which you cloned your local repository.
- Fetch: Download commits, files, and references from a remote repository into your local repository.
- Pull: Fetch changes from a remote repository and immediately merge them into your local branch.
- Push: Upload your local commits to a remote repository.
- Remote Branches: Branches in a remote repository that your local repository is aware of.
To add a new remote repository, use the git remote add
command:
git remote add <name> <url>
Example:
git remote add origin https://github.com/yourusername/your-repo.git
To view the remotes you have set up:
git remote -v
This command will list the short names (like origin
) and the URLs of the remote repositories.
To fetch changes from the remote repository without merging them into your local branch:
git fetch <remote>
Example:
git fetch origin
To fetch and merge changes from the remote repository into your current branch:
git pull <remote> <branch>
Example:
git pull origin main
To push your local commits to a remote repository:
git push <remote> <branch>
Example:
git push origin main
To rename a remote:
git remote rename <old-name> <new-name>
Example:
git remote rename origin upstream
To remove a remote:
git remote remove <name>
Example:
git remote remove origin
To view detailed information about a remote:
git remote show <name>
Example:
git remote show origin
When you clone a repository, Git automatically adds the remote for you, named origin
.
git clone https://github.com/yourusername/your-repo.git
If you want to add another remote, for example, to contribute to another repository:
git remote add upstream https://github.com/anotheruser/another-repo.git
To fetch changes from the upstream
remote:
git fetch upstream
After fetching changes, you can merge them into your current branch:
git merge upstream/main
If you pull changes and there are conflicts, Git will prompt you to resolve them manually. After resolving conflicts:
-
Stage the resolved files:
git add <resolved-file>
-
Continue the merge or pull process:
git commit
After making commits locally, push them to the origin
remote:
git push origin main
- Regularly Fetch and Pull: Keep your local repository up-to-date by regularly fetching and pulling changes from the remote repository.
- Push Often: Push your changes frequently to share your progress and avoid large merges.
- Use Branches: Work on feature branches and push them to the remote repository to keep the
main
branch stable and clean. - Collaborate with Pull Requests: Use pull requests to review and discuss changes before merging them into the main branch.
Working with remotes is an essential part of collaborating with others in Git. By understanding and using these commands effectively, you can manage and integrate changes smoothly in your projects.
- Everything you need to know about README.md is discussed in the video.
- 6 heading levels: number of hashes define heading levels. check the following examples:
# heading 1 level text is here
## heading 2 level text is here
- bold syntax:
**text goes here**
- italic syntax:
_text goes here_
- bold and italic syntax:
**_text goes here_**
- strikethrouh syntax:
~~this is~~
- single line code syntax: `` place code inside backticks
- multiple line code syntax: ``` place code inside three open and closing backticks
- multiple line code syntax language specific: ```html for specific lanaguage use language name when starting; not closing
- Ordered List syntax
1. HTML
2. CSS
1. Fundamental
2. CSS Architecture - BEM
3. CSS Preprocessor - SASS
3. JS
-
Unordered List syntax ->
- html - css - Fundamental - CSS Architecture - BEM - CSS Preprocessor - SASS - js
-
Task List
- [x] Task1 - [x] Task2 - [x] Task3
-
adding link
<!-- automatic link --> http://www.studywithanis.com <!-- markdown link syntax --> [title](link) [studywithanis](http://www.studywithanis.com) [studywithanis][websitelink] <!-- all link is here --> [websitelink]: http://www.studywithanis.com
-
adding image syntax ->
![alt text](imageURL)
![1800 milestone](https://i.postimg.cc/qvZpmxKF/1-800-Uploads-Milestone.png)
-
adding emoji
emoji src ### Smileys 😀 😃 😄 😁 😆 😅 😂 🤣 🥲☺️ 😊 😇 🙂 🙃 😉 😌 😍 🥰 😘 😗 😙 😚 😋 😛 😝 😜 🤪 🤨 🧐 🤓 😎 🥸 🤩 🥳 😏 😒 😞 😔 😟 😕 🙁☹️ 😣 😖 😫 😩 🥺 😢 😭 😤 😠 😡 🤬 🤯 😳 🥵 🥶 😱 😨 😰 😥 😓 🤗 🤔 🤭 🤫 🤥 😶 😐 😑 😬 🙄 😯 😦 😧 😮 😲 🥱 😴 🤤 😪 😵 🤐 🥴 🤢 🤮 🤧 😷 🤒 🤕 🤑 🤠 😈 👿 👹 👺 🤡 💩 👻 💀 ☠️ 👽 👾 🤖 🎃 😺 😸 😹 😻 😼 😽 🙀 😿 😾- Gestures and Body Parts 👋 🤚 🖐 ✋ 🖖 👌 🤌 🤏 ✌️ 🤞 🤟 🤘 🤙 👈 👉 👆 🖕 👇 ☝️ 👍 👎 ✊ 👊 🤛 🤜 👏 🙌 👐 🤲 🤝 🙏 ✍️ 💅 🤳 💪 🦾 🦵 🦿 🦶 👣 👂 🦻 👃 🫀 🫁 🧠 🦷 🦴 👀 👁 👅 👄 💋 🩸
-
adding table
table syntax
| heading1 | heading2 |
| ----- | ----- |
| data1 | data2 |
| data3 | data4 |
| data5 | data6 |
GitHub Issues is a feature within GitHub that allows users to track and manage work on a project. It's a powerful tool for managing bugs, tasks, feature requests, and other project-related activities. Here's a detailed explanation of GitHub Issues:
GitHub Issues provides a way to:
- Report bugs
- Suggest enhancements
- Ask questions
- Manage tasks
- Track project milestones
Each issue serves as a discussion thread where collaborators can comment, provide feedback, and attach files or code snippets.
-
Creating Issues
- Users can create an issue by clicking on the "Issues" tab in a repository and then selecting "New issue."
- Each issue requires a title and description. The description can include text, markdown, images, and code snippets.
-
Labels
- Labels are used to categorize issues. For example, labels can indicate the type of issue (bug, enhancement, question) or its priority.
- Custom labels can be created to suit the project's needs.
-
Assignees
- Issues can be assigned to one or more collaborators who are responsible for resolving the issue.
-
Milestones
- Milestones group issues into larger goals or releases. This helps in tracking progress toward significant project objectives.
-
Projects
- GitHub Projects is a feature that allows users to organize issues into boards, similar to Kanban boards, for better project management.
-
Comments and Mentions
- Collaborators can comment on issues to provide updates, feedback, or solutions.
- Users can mention others using
@username
to draw their attention to specific comments or issues.
-
References and Links
- Issues can be cross-referenced with other issues, pull requests, and commits using their respective IDs (e.g.,
#123
for issue 123).
- Issues can be cross-referenced with other issues, pull requests, and commits using their respective IDs (e.g.,
-
Closing Issues
- Issues can be closed manually by maintainers or automatically when a related pull request is merged using keywords like "fixes #123" in commit messages.
-
Templates
- Repository maintainers can create issue templates to guide users in providing necessary information when opening new issues.
-
Opening an Issue
- A user opens an issue describing a bug, feature request, or task.
- Labels and milestones can be assigned at this stage.
-
Discussion
- Collaborators discuss the issue in the comments, providing insights, feedback, and potential solutions.
- The issue can be updated based on the discussion.
-
Assigning and Prioritizing
- The issue is assigned to one or more developers.
- The priority is set using labels or by placing the issue within a milestone.
-
Working on the Issue
- Developers work on the issue, often linking commits and pull requests to the issue for tracking progress.
-
Closing the Issue
- Once the issue is resolved, it is closed manually or automatically via a merged pull request.
-
Reviewing Closed Issues
- Closed issues can be reviewed for historical reference and to ensure that similar issues do not arise again.
- Centralized Tracking: All issues related to a project are tracked in one place.
- Collaborative Problem-Solving: Issues facilitate discussion and collaboration among team members.
- Transparency: The status and progress of issues are visible to all project collaborators.
- Efficient Workflow: Issues integrate seamlessly with other GitHub features like pull requests and project boards, making it easier to manage the development lifecycle.
- Use Descriptive Titles and Descriptions: Ensure issues are clear and concise.
- Label Appropriately: Use labels to categorize and prioritize issues.
- Stay Organized: Regularly review and update issues, milestones, and projects.
- Encourage Participation: Invite team members to comment, contribute, and collaborate on issues.
- Close Issues Promptly: Close resolved issues to keep the repository clean and up-to-date.
GitHub Issues is a versatile tool that enhances project management and collaboration, making it easier to track, discuss, and resolve tasks and bugs in software development projects.
Undoing changes in Git can be done in several ways, depending on what you need to achieve. Here are some common scenarios and the Git commands you can use to undo changes:
If you have modified files but haven't staged them yet and want to discard these changes:
git checkout -- <file>
To discard changes in all files:
git checkout -- .
If you have staged changes but haven't committed them yet and want to unstage them:
git reset HEAD <file>
To unstage all changes:
git reset HEAD .
If you want to discard all local changes, both staged and unstaged:
git reset --hard HEAD
If you want to change the most recent commit (e.g., to add a missing file or correct a commit message):
git commit --amend
If you want to undo a specific commit but keep the history (create a new commit that reverses the changes):
git revert <commit>
If you want to move the branch pointer to a previous commit, effectively discarding all commits that came after:
git reset --hard <commit>
For example, to reset to the commit abcd1234
:
git reset --hard abcd1234
To undo a commit that has already been pushed to a shared repository without rewriting history:
git revert <commit>
git push
To forcefully rewrite the history of a branch that has already been pushed (use with caution):
git reset --hard <commit>
git push --force
- Modify a file (
example.txt
).
echo "some changes" > example.txt
- Discard the changes.
git checkout -- example.txt
- Stage a file.
git add example.txt
- Unstage the file.
git reset HEAD example.txt
- Make a commit.
git commit -m "Initial commit"
- Amend the commit to include a missed file.
echo "missed content" > missed.txt
git add missed.txt
git commit --amend
- Make a commit.
echo "bad change" > bad.txt
git add bad.txt
git commit -m "Bad commit"
- Revert the commit.
git revert HEAD
- Make a series of commits.
echo "commit 1" > file1.txt
git add file1.txt
git commit -m "Commit 1"
echo "commit 2" > file2.txt
git add file2.txt
git commit -m "Commit 2"
echo "commit 3" > file3.txt
git add file3.txt
git commit -m "Commit 3"
- Reset to the first commit.
git reset --hard HEAD~2
These commands provide powerful ways to undo changes in Git, but they should be used carefully, especially when working with shared repositories, to avoid disrupting other collaborators.
-
Branch is a new and separate branch of the master/main repository, which allows you parallel development.
-
Branching allows you to diverge from the main line of development and continue working on a separate line of code without affecting the main codebase. When you create a branch, you essentially create a copy of the code at a certain point in time, and you can make changes to this copy independently of other branches. Branches are often used for developing new features, fixing bugs, or experimenting with changes.
-
Merging is the process of combining the changes from one branch (the source branch) into another (the target branch). This allows you to incorporate the changes made in one branch back into the main codebase or another branch. When you merge branches, Git automatically integrates the changes, resolving any conflicts that may arise if the same part of the code was modified in both branches.
-
create a branch
git branch branch_name
-
List branches
git branch
-
List all remote branches
git branch -r
-
List all local & remote branches
git branch -a
-
move to a branch
git checkout branch_name
-
create and move to a branch
git checkout -b branch_name
-
delete a branch:
git branch -d branch_name
-
merge branches:
git checkout branchName git merge branchName
-
git log --oneline --all --graph
- Reeference:
- git reset
- git revert
- git stash
- git tag
- git checkout
- git remote
In GitHub, "tags" typically refer to Git tags. Git tags are a way to mark specific points in a Git repository's history as being important or significant. They are often used to label specific commits, such as releases or version numbers, to make it easier to reference those commits in the future.
Here's how Git tags work:
-
Creating a Tag: You can create a Git tag by running a command like
git tag <tag-name>
, where<tag-name>
is the name you want to give to the tag. For example, you might create a tag for a release like this:git tag v1.0.0
. -
Tagging Commits: Tags are typically associated with specific commits. When you create a tag, it's linked to the current commit, but you can also specify a different commit if needed.
-
Listing Tags: You can list all the tags in a Git repository using the
git tag
command. -
Annotated vs. Lightweight Tags: Git supports two types of tags: annotated and lightweight. Annotated tags are recommended for most use cases because they store extra metadata like the tagger's name, email, date, and a tagging message. Lightweight tags are just a name for a specific commit and don't include extra information.
-
Pushing Tags: By default, when you push changes to a remote Git repository, tags are not automatically pushed. You need to use
git push --tags
to push tags to a remote repository. This is important when you want to share tags, especially when creating releases on GitHub. -
Using Tags on GitHub: On GitHub, you'll often see tags associated with releases. When you create a release on GitHub, it typically creates a Git tag behind the scenes to mark the specific commit associated with that release. Users can then download or reference that release by its tag name.
GitHub also has its own concept of "releases" that are closely related to Git tags. A release on GitHub is a way to package and distribute software versions, and it often corresponds to a Git tag. When you create a GitHub release, you can upload release assets (e.g., binaries, documentation) and provide release notes.
In summary, GitHub tags are essentially Git tags, and they are used to mark important points in a repository's history, often associated with releases or significant commits. They help users easily reference and work with specific versions of a project.
- GitHub Pages
- GitHub Actions (CI/CD)
- Managing access permissions
- Using templates
- Webhooks
Git Flow GitHub Flow Trunk-Based Development Rewriting History
git cherry-pick git filter-branch git reflog Performance and Optimization
Partial clone Handling large repositories Git LFS (Large File Storage) Advanced GitHub Features
GitHub API Integrations with third-party tools Security best practices (code scanning, dependency checks) Collaboration and Workflow Automation
Continuous Integration/Continuous Deployment (CI/CD) with GitHub Actions Automating tasks with GitHub Apps and bots Git Internals
How Git stores objects and commits The Git object model Pack files and garbage collection