| Nov | DEC | Jan |
| 05 | ||
| 2021 | 2022 | 2023 |
COLLECTED BY
Collection: Common Crawl
.git Directory
●Git Objects
●Git Deep
●GitHub
●What is GitHub?
●GitHub Repositories
●Contributor Friendly Repository
●README.md
●CONTRIBUTING.md
●License
●Code of Conduct
●Issues
●Terms
●Repository
●Untracked Files
●Added Files
●Modified Files
●.gitignore file
●Staging (staging area/index)
●Working Tree
●SHA1
●Aliases
●HEAD
●Branches
●Collaborators
●Contributors
●Misc
●Open Source Programs
●Resources
|
Git and GitHub sessions by the author: |
|
One might want to familiarize themselves with some terms before starting, although they will be linked at places where they are required as well. |
|
|
'main' vs 'master' #1:
GitHub is gradually renaming the default branch of repositories from 'master' to 'main'. The name of the default branch for new repositories on GitHub is now 'main'. Existing repositories on GitHub are not impacted by this change, but they can now rename their branches if they wish to. For more details, please check the renaming repo by GitHub. Changing the default branch of the local Git client is also possible. |
touch
To create a file in the directory to which the bash is pointing.
touch <file_name.ext>
Eg: touch create_this_file.txt
|
|
A local repo does not need to have a remote repo. |
git remote command.
It can be of two types
Local repo
Remote repo
For more information on remote repos, refer to Repository (repo) section.
Related
Repository (repo)
GitHub
git <flags> <options>
--all or `-a`is given then all available commands are printed.
git help <options>
git help add
git config <flags>
git config --global user.name "<name>"
Set user’s e-mail: git config --global user.email "<e-mail_id>"
|
|
Please enter the e-mail ID registered with the concerned GitHub/GitLab/BitBucket account and the full name. This is the name and e-mail ID that will be associated with each commit. The global name and e-mail need to be set just once, ie, when Git is used for the first time ever on a computer (but can be modified if need be). |
git init command: git config --global init.defaultBranch "<branch_name>"
|
'main' vs 'master' #2: This only applies to GitHub repositories. New GitHub repositories have the name of their default branch as 'main' instead of 'master', while the local Git client still uses 'master' as the name of the default branch when initializing repositories. This mismatch in the names of the default branches causes pushes to new remote repositories to fail.
To combat this change on GitHub, it would be advisable to change the name of the default branch of the local Git client to 'main' using the command NOTE: Cloned repositories will not be impacted unless the remote repository’s default branch is changed on GitHub after cloning (in which case GitHub will provide commands to rename the local branch on visiting the repository page on GitHub for the first time after the renaming). |
git config --global core.editor "<editor_name>"
Some editor options
Vim: vim
VS Code: code --wait
Sublime Text: subl --waitor\"full/path/to/subl.exe\" -w
Aliases can also be set using this flag.
git config --list
git init
.git is created in the directory. None of the commands below will work if there is no local git repo initialized.
|
If the remote repository is/is going to be located on GitHub, please be aware of the mainvsmaster default branch issue which might cause git push to fail.
|
./.git.
git init <new_folder_name>
Initializes a new repo in ./<new_folder_name>.
Creates ./<new_folder_name>/.git.
git add <flags> <file_name.ext> where `ext`stands for the extension of the file.
directory_name/<file_name.ext>
Multiple file names in one command are allowed with a whitespace in between them.
Eg: git add dir/dir1_file.txt
git add .
Recursive command to send all untracked and modified files to the staging area (except for the file names in the .gitignore file).
y (yes): Stage the hunk.
n (no): Not stage the hunk.
q (quit): Quit the process and not stage the current hunk or the remaining ones. (Hunks in order can be left undecided temporarily as seen in the options below.)
a (all): Stage the current hunk all the ones that follow.
d (delete): Not stage the current hunk all the ones that follow.
g (goto): Go to a particular hunk. (It will display a list with a hunk number to go to a particular hunk if there are more than 1 hunks.)
/: Search for a hunk matching the given regex.
j: Leave the current hunk undecided and see the next undecided hunk.
J: Leave the current hunk undecided and see the next hunk.
k: Leave the current hunk undecided and see the previous undecided hunk.
K: Leave the current hunk undecided and see the previous hunk.
s (split): Split the current hunk into smaller hunks.
e (edit): Manually edit the current hunk in an editor.
?: Print help.
Eg: git add -porgit add -p <file_name.ext>
git add -n .
Shows files that will be added, but does not add them.
Run other git add commands to actually add files to the staging area.
git rm)
Unstage Files Staged/Added by Mistake
git status
?? implies an untracked file, ie, a file that has never been staged.
A implies a newly staged (added) file, ie, a file that is now staged, but has never been staged before.
M (red) implies unstaged modifications in a committed file.
M (green) implies staged modifications in a committed file (but the new modifications have not been committed yet).
AM (green and red respectively) implies new modifications in a newly staged uncommitted file.
MM (green and red respectively) implies new modifications in a committed file that has been staged with modifications, without committing the previous changes.
D (red) implies the renaming/moving/both (renaming and moving)/deletion of a staged file that has not been staged again.
D (green) implies the deletion of a staged file.
R (green) implies the renaming/moving/both of a staged file.
AD (green and red respectively) implies the renaming/moving/both (renaming and moving)/deletion of a newly staged uncommitted file that has not been staged again.
|
|
If |
git commit <flags_&_options>
git add before this command.
Every commit has a unique SHA1 associated with it.
Use git log & git show commands to get information on commits.
|
|
Always pull before committing & pushing. |
|
|
Commit related changes. |
|
|
Commit changes frequently. This makes it easier to revert back to older versions to correct mistakes. |
|
|
Don’t commit half-done or incomplete work. |
git merge.
Another way to think about commit messages is to write them such that the codebase is being instructed to do something.
Eg: git commit -m ":truck: feat: Implement Debouncing for search box"
General commit message structure below
:sparkles: feat: add hat wobble (#26)
^--------^ ^---^ ^------------^ ^---^
| | | |
| | | +----> PR or issue resolved (if any).
| | |
| | +----> Summary in present tense.
| |
| +----> Type:- chore, docs, feat, fix, refactor,style, test, etc.
|
+----> Emoji:- :tada: :bookmark: :sparkles: :bug: :books: :wrench: :truck:|
|
More on types and emojis. |
git commit will launch a text editor prompting you for a commit message.
After you’ve entered a message, save the file and close the editor using :wq or just save and exit the editor to create the actual commit.
git commit -a -m "<commit_message>"orgit commit -am "<commit_message>"
git commit --amend -m "<new_commit_msg>" -m "<new_commit_description>". (Commit description is optional.)
|
|
This command will change the commit message of the latest commit only. Refer to git rebase for changing older commit messages.
|
|
|
Any amend command re-writes the history of the repository as it entirely replaces the previous latest commit with the new one, so use this only for commits that are not pushed. |
git add and then amend the last commit with the --no-edit option.
Eg: git commit --amend --no-edit
git commit --amend --author="Harsh Kapadia <contact@harshkapadia.me>
If both, the author and the committer of the last commit need to be changed, edit the local or global Git config and then amend the last commit using the git commit --amend --no-edit command.
git commit --allow-empty -m "<commit_message>".
Signed-off-by: Author Name <author@email.com> at the end of the commit message.
The meaning of a signoff depends on the project being contributed to.
Eg: The Git and Linux Kernel projects use the signoff as a way to certify that the committer agrees with the Developer’s Certificate of Origin.
git log <options_&_flags>
git log HEAD.
git show.
--oneline or/and --decorate flags.
Eg: git log --graph --oneline --decorate
git rm <flags> <file_name.ext> where `ext`stands for the extension of the file.
"" if the file name has spaces in between.
git rm -r --cached .
Recursive command to remove all files from the staging area.
Related
Add files to staging area (git add)
git pull <remote_repo_alias> <remote_branch_name>
Eg: git pull origin master
git pull and git fetch
In simple terms, git pull does a git fetch followed by a git merge.
git pull automatically merges commits without letting you review them first. If you don’t closely manage your branches, you may run into frequent conflicts.
Related
git fetch
git merge
git fetch <remote_repo_alias> <branch_name>
git fetch, Git gathers any commits from the target branch that do not exist in the current local branch and stores them in the local repository. However, it does not merge them with the current branch (unlike git pull).
This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files.
To integrate the commits into your master branch, you use git merge.
Related
git pull
git merge
git clone <remote_repo_url>.git
Eg: git clone https://github.com/HarshKapadia2/git_basics.git
cd(change directory) into that directory to start using it.
git clone https://github.com/HarshKapadia2/git_basics.git
Cloning a local repository: git clone x:/coding/git/local_repo
git clone -b main https://github.com/HarshKapadia2/git_basics.gitorgit clone -b main --single-branch https://github.com/HarshKapadia2/git_basics.git
--single-branch is assumed.
--single-branch (default) or in all branches (--no-single-branch).
Specify the branch name using -bor--branch for --single-branch. The main (previously called master) branch is assumed, if not specified.
Eg: git clone -b v2 --depth 1 https://github.com/HarshKapadia2/attendance_manager.git
With --no-single-branch, use git branch -a to view the fetched branches and git switch <branch_name> to use it.
Eg: git clone --no-single-branch --depth 1 https://github.com/HarshKapadia2/attendance_manager.git
|
Shallow clones cannot be pushed to a new repository. The shallow clone will either have to be [unshallowed] or the .git directory will have to be deleted (start afresh by initializing a new repository).
|
-b reference
Shallow clone reference
git merge <branch_name>
git merge command’s primary responsibility is to combine separate branches and resolve any conflicting edits.
Merging is Git’s way of putting a forked history back together again.
The git merge command lets you take the independent lines of development created by git branchorgit checkout and integrate them into a single branch.
Preparing to merge:
Make sure to be in the branch (git checkout <receiving_ranch>) you want to merge another branch into (let this branch be called receiving_branch).
Make sure the receiving branch and the merging branch are up-to-date with the latest remote changes.
Merge using git merge <merging_branch>
Eg: If you want to merge the 'feature' branch into the 'master' branch, run git checkout master (if you aren’t already in the master branch, ie, if your HEAD points to another branch) and then run git merge feature.
|
|
This does not create a new commit signifying the merge. |
|
|
The branch can be safely deleted. |
|
|
git push is allowed only if you have a fast forward merge.
|
|
|
This is useful for documenting all merges that occur in a repository, as a merge without this flag does not create a new commit. |
git branch <flags> <options>
git branch command lets the user create, list, rename and delete branches.
It doesn’t let the user switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
Further details.
git switchorgit checkout to check out (view/switch to) the new branch.
|
|
If the currently checked out branch is to be deleted, switch to a different branch and then run the above command. |
|
|
This is a safe operation as Git prevents the deletion of the branch if it has unmerged changes. |
|
|
If the currently checked out branch is to be deleted, switch to a different branch and then run the above command. |
new_branch_name.
git checkout <flags> <options>
git branch.
Further details.
new_branch_name.
Eg: git checkout feature_branch
|
|
git switch can also be used to achieve the same result.
|
|
|
The new branch is created from the curent HEAD. |
|
|
The new branch is created from the last commit of the existing_branch_name.
|
|
|
This condition will land you in a detached HEAD state. |
|
|
git restore can also be used to achieve the same result.
|
git remote <options_&_flags>
git remote add origin <link_to_repo>.git
git remote add origin https://github.com/HarshKapadia2/git_basics.git
To connect to a local repo: git remote add origin x:/coding/git/local_repo
git remote rm origin
|
|
This command only removes the connection between two repos. It does not delete any data. |
git push -u <remote_repo_alias> <remote_branch_name>
git remote and [creating a repo on GitHub].
|
|
If the push is to a newly created empty repository on GitHub, the mainvsmaster default branch issue might cause it to fail.
|
|
|
From the two pictures above, it can be inferred that Git will allow pushing only if the push results in a fast-forward merge. |
git show <options>
git log to get the SHA1 of the required commit.
git log <commit’s_SHA1> shows.
git show :test_file.txt
Related
git log
git stash
git switch <branch_name>
git checkout.
Related
git checkout
git restore <file_name.ext>
git checkout.
Related
git checkout
|
|
The GUI has buttons to directly do it (as shown in the image below, Fetch upstream → Fetch and merge). The changes in the synced forked repo only have to be pulled to reflect locally.
|
git remote -v to list all the remote repos connected to the local forked repo.
Add the original (remote) repo as a remote to the local forked repo using %20git remote add originalRepo <link_to_original_repo>.git.
The alias for the original remote repo is assumed to be originalRepo here.
Run git remote -v again to check whether it has been added.
The original repo is now connected to the local forked repo.
Get the latest changes in the original repo and push the to your forked (remote) repo.
Run git pull originalRepo <branch_name> to get the latest changes from the original repo.
If there are merge conflicts, they have to be handled.
Push the changes to the remote forked repo using git push -u origin <branch_name>.
The alias for the remote forked repo is assumed to be origin here.
|
|
The git pull step can be split into git fetch & git merge as well.
|
$ git remote add originalRepo <link_to_original_repo>.git
$ git pull originalRepo <branch_name>
$ git push -u origin <branch_name>originalRepo = original remote repo alias & origin = remote forked repo alias)
Related
Reference article
Two branches in the remote repository
Only one branch in the local repository
In such a situation, the remote branch needs to be fetched locally and then checked out to be used locally.
There are two possibilities
The remote branch has already been fetched locally, but not checked out.
The remote branch has not been fetched.
To check whether the remote branch has been fetched locally or not, run git branch -a. If the branch is listed in red, then it has been fetched locally.
'br_1' (in red) has already been fetched
Run git checkout <fetched_branch_name>orgit switch <fetched_branch_name> to switch to the fetched remote branch.
Successfully switched to 'br_1'!
'br_1' has been not been fetched (not in list)
Fetch the branch using git fetch <remote_repo_alias> <branch_to_be_fetched>.
Run git branch -a to check whether it appears as a fetched branch in red.
Run git checkout <fetched_branch_name>orgit switch <fetched_branch_name> to switch to the fetched remote branch.
Successfully switched to 'br_1'!
|
|
The commands below will simply unstage added files and will NOT result in data loss. |
git reset HEAD -- "<files/folders/patterns>"
Files
For a single file, use git reset HEAD -- "<file_name.ext>".
For multiple files, use git reset HEAD -- "<file_1.ext>" "<file_2.ext>"….
For files with the same extension, use git reset HEAD -- "<*.ext>".
Directories/folders
For a single directory, use git reset HEAD -- "<path/to/dir>".
For multiple directories, use git reset HEAD -- "<path/to/dir_1>" "<path/to/dir_2>"….
To unstage everything in the staging area, use git reset HEADorgit reset HEAD -- *.
.git Directory
README.md
CONTRIBUTING.md
LICENSE
CODE_OF_CONDUCT.md
Issues
They are discussed below.
|
|
A good place to get to know how a repository compares with the recommended community standards and add the missing files is the 'Community' tab in the 'Insights' section of a repository. |
README.md file is where all the details of the project are written.
md stands for 'Markdown', which is a lightweight and very easy to learn markup language to create rich text using a plain text editor.
Video to learn the syntax.
Markdown cheat sheet.
AREADME.md file usually includes a brief description of the project with its features, a link to the CONTRIBUTING.md file, a link to the CODE_OF_CONDUCT file, a link to the LICENSE file and any other section that the repository owner wants to add.
Sample template
# repo name (or logo/picture)
<Add badges (shields) here>
<Hosting URL of project (if any)>
<Tag line>
Description of project
## Features
Describe the features of your project.
## Technologies used
List all the technologies used
## Installation
Give steps to install and use your software/project. (Not for contribution purposes.)
## Contributions
Welcome all contributions & add a link to the `CONTRIBUTING.md` file.
## Code of Conduct
Add a link to the `CODE_OF_CONDUCT.md` file.CONTRIBUTING.md file explains how a contributor should do things like format code, test fixes, and submit patches. It can also include instructions for contributors to set up a local environment.
md stands for 'Markdown', which is a lightweight and very easy to learn markup language to create rich text using a plain text editor.
A video to learn the syntax
Markdown cheat sheet
Asample template
LICENSE (without an extension) can be created and the content of the license can be pasted in it. (The contents can be found at https://choosealicense.com/.)
|
|
If certain software doesn’t have a license, that generally means that there is no permission from the creators of the software to use, modify or share the software. Although a code host such as GitHub may allow viewing and forking the code, this does not imply that anyone is permitted to use, modify, or share the software for any purpose. The options are
Don’t use the software. Negotiate a private license with a lawyer. |
CODE_OF_CONDUCT.md can be created and the content of the CoC can be pasted in it.
More information on CoC.
#. Every issue and pull request has a number associated with it (usually mentioned at the top of the issue/PR, beside the title.) So #69or#420 are examples of how issues/PRs can be referred to, in commit messages, PRs or issues.
Refer to GitHub’s guide for more on issues.
.gitignore and that have been added to the staging area of the repository.
The files are in their latest version (ie, they have not been modified since they were last added).
They are also called 'staged files'.
Related
git add
Staging
#.
Ignored file names to be written in the format file_name.ext. eg: test.txt
*.ext ignores all files with the extension .ext.
If a file is in a directory, use dir_name/file_name.ext.
If all the files in a directory need to be excluded, use relative/path/to/dir.
A resource for .gitignore file templates for different programming languages
.gitignore
.gitignore by adding a pattern in .git/info/exclude.
The syntax is the same as for .gitignore.
This is useful if you want to keep a local TODO list, but don’t want to commit it to the repository, and don’t want to modify .gitignore for everyone.
Related
git add
git add
git rm
git commit
Related
git commit
git log
git show
git config. Here are a couple of examples you may want to set up:
git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st statusThis means that, for example, instead of typing
git commit, you just need to type git ci. As you go on using Git, you’ll probably use other commands frequently as well; don’t hesitate to create new aliases.
An alias can be given to the remote repo as well, to make pulling and pushing easier.
You can set custom aliases if you add a remote (ie, remote repo) using git remote.
If you clone a repo using git clone, the default alias of the remote repo is origin.
Related
git config
git pull
git push
git remote
git clone
git fetch
|
|
HEAD is contextual. It will point to the latest commit in the current branch. |
To check where the current HEAD is pointing, run cat .git/HEAD in the root directory.
Eg:
# in the 'main' branch $ cat .git/HEAD ref: refs/heads/main $ git switch test_branch Switched to branch 'test_branch' $ cat .git/HEAD ref: refs/heads/test_branchWhen the HEAD points to a commit that is not the latest commit in a branch, that is a detached HEAD. A specific commit can be referred to, using
git checkout.
Related
git checkout
git commit
git log
git merge
In Git, branches are a part of everyday development process.
Git branches are effectively a pointer to a snapshot of changes.
When a new feature is to be added or a bug — no matter how big or how small has to be fixed, a new branch is created to encapsulate the changes.
This makes it harder for unstable code to get merged into the main code base, and it gives the chance to clean up the future history before merging it into the main branch.
git clone.
All pull requests are opened against this base branch unless any other branch is explicitly specified.
Any branch can be made the default branch, but by default it is the 'master' (or 'main') branch.
The default branch can be changed at any time on GitHub from the repository’s settings and GitHub will point all open pull requests to the new default branch.
Changing the default branch of the local Git client (using git config) is also possible. If this is done, whenever a new repository is initialized locally, the default branch will be the new branch name entered in the git config command.
Related
git branch
git checkout
git restore
git switch
git merge
settings/manage access section in the repo (there is a limit to the number of invites in 24 hrs).
|
|
Acontributor is a collaborator only if he is chosen to be a collaborator by the owner. So a collaborator is a contributor, but the vice versa is not always true. |
|
|
A contributor is a collaborator only if he is chosen to be a collaborator by the owner. So a collaborator is a contributor, but the vice versa is not always true. |
CONTRIBUTING.md].
|
|
Follow correct commit message structure. Eg: :bug: fix: Login button position corrected (#26, #32, #33)
|
Google Summer of Code (GSoC) is a global open source program where students can contribute to projects of organisations participating in Google Summer of Code for 10 weeks to gain exposure in the Software Development field and the participant will be paired with a mentor and get to learn various things in the domain of their interest. GSoC also provides a stipend to the participants.
To participate in GSoC, it is recommended to contribute to an organisation of interest 2 to 3 months before the GSoC applications start.
GSoC
GSoC Organisations
Google Season of Docs (GSoD) provides support for open source projects to improve their documentation and gives professional technical writers an opportunity to gain experience in open source.
GSoD
Beginners Guide to GSoD
Outreachy is a three month long paid and remote internship for people who are underrepresented in specific fields. It is conducted twice a year.
|
|
Students whose university lies in the Northern Hemisphere are eligible to apply only for the first application round and those whose university lies in the Southern Hemisphere are eligible only for the second round. Those whose university lies near the Equator are eligible to apply in both the application rounds. |
Major League Hacking (MLH) Fellowship is a 12 week internship program designed to level up Tech Skills. The Program is divided into three tracks
Open Source
This track is about contributing to some great open source projects that are used by thousands of companies around the world.
Software Engineering
This track is about working on real-world Software Engineering problems by collaborating on projects by real companies and Government partners.
Prep Program
THis track is about building out one’s portfolio and experimenting with new technologies by collaborating in a short hackathon sprint.
MLH Fellowship
Beginners Guide to MLH Fellowship
The Linux Foundation Mentorship Program gives one an opportunity to learn from open source contributors and contribute to open source projects.
Current mentorship programs include
Linux Kernel
LF Networking
Hyperledger
CNCF
OpenHPC
Open Mainframe Project
GraphQL
Linux Foundation
Beginners Guide to the Linux Foundation Mentorship Program
| Name | Timeline | Links | Eligibility |
|---|---|---|---|
Google Summer of Code (GSoC) |
Oct-Aug |
For Students: Age should be at least 18 years. Should be enrolled in a Post-Academic Program. Student must be eligible to work in the residing country for the duration of the program. Should should not be an Organisation Administrator or Mentor in the program. |
|
Google Season Of Docs (GSoD) |
Feb-Nov |
||
Outreachy |
May-Aug Dec-March |
Students who have participated in GSoC are not eligible for Outreachy. Students whose university lies in the Northern Hemisphere are eligible to apply only for the first application round and those whose university lies in the Southern Hemisphere are eligible only for the second round. Those whose university lies near the Equator are eligible to apply in both the application rounds. |
|
MLH Fellowship |
Spring batch: Jan-April Summer batch: May-Aug Fall batch: Sept-Dec |
Age should be above 18 yrs. Student should be able to spend the hours required by the program. |
|
Linux Foundation Mentorship Program |
Spring term: March-May Summer term: June-Aug Fall term: Sept-Nov |
good-first-issue and first-timers-only issues on GitHub in the language/library/framework of choice.
'first-timers-only' issues on GitHub
'good-first-issue' issues on GitHub
Privacy policy | Created
using
Asciidoctor Jet.