GIT
GIT
Git is a popular version control system. It was created by Linus Torvalds in 2005, and has been maintained by Junio Hamano since then.
It is used for:
- Tracking code changes
- Tracking who made changes
- Coding collaboration
What does Git do?
- Manage projects with Repositories
- Clone a project to work on a local copy
- Control and track changes with Staging and Committing
- Branch and Merge to allow for work on different parts and versions of a project
- Pull the latest version of the project to a local copy
- Push local updates to the main project
Working with Git
- Initialize Git on a folder, making it a Repository
- Git now creates a hidden folder to keep track of changes in that folder
- When a file is changed, added or deleted, it is considered modified
- You select the modified files you want to Stage
- The Staged files are Committed, which prompts Git to store a permanent snapshot of the files
- Git allows you to see the full history of every commit.
- You can revert back to any previous commit.
- Git does not store a separate copy of every file in every commit, but keeps track of changes made in each commit!
Why Git?
- Over 70% of developers use Git!
- Developers can work together from anywhere in the world.
- Developers can see the full history of the project.
- Developers can revert to earlier versions of a project.
What is GitHub?
- Git is not the same as GitHub.
- GitHub makes tools that use Git.
- GitHub is the largest host of source code in the world, and has been owned by Microsoft since 2018.
- In this tutorial, we will focus on using Git with GitHub.
GitHubBitbucketGitLab
ADVANTAGES OF GIT
Free and open source
Git is released under GPL’s open source license. It is available freely over the internet. You can use Git to manage property projects without paying a single penny. As it is an open source, you can download its source code and also perform changes according to your requirements.
Fast and small
As most of the operations are performed locally, it gives a huge benefit in terms of speed. Git does not rely on the central server; that is why, there is no need to interact with the remote server for every operation. The core part of Git is written in C, which avoids runtime overheads associated with other high-level languages. Though Git mirrors entire repository, the size of the data on the client side is small. This illustrates the efficiency of Git at compressing and storing data on the client side.
Implicit backup
The chances of losing data are very rare when there are multiple copies of it. Data present on any client side mirrors the repository, hence it can be used in the event of a crash or disk corruption.
Security
Git uses a common cryptographic hash function called secure hash function (SHA1), to name and identify objects within its database. Every file and commit is check-summed and retrieved by its checksum at the time of checkout. It implies that, it is impossible to change file, date, and commit message and any other data from the Git database without knowing Git.
No need of powerful hardware
In case of CVCS, the central server needs to be powerful enough to serve requests of the entire team. For smaller teams, it is not an issue, but as the team size grows, the hardware limitations of the server can be a performance bottleneck. In case of DVCS, developers don’t interact with the server unless they need to push or pull changes. All the heavy lifting happens on the client side, so the server hardware can be very simple indeed.
Easier branching
CVCS uses cheap copy mechanism, If we create a new branch, it will copy all the codes to the new branch, so it is time-consuming and not efficient. Also, deletion and merging of branches in CVCS is complicated and time-consuming. But branch management with Git is very simple. It takes only a few seconds to create, delete, and merge branches.
https://www.tutorialspoint.com/git/git_quick_guide.htm
GIT BASICS
What is Version Control?
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. So ideally, we can place any file in the computer on version control.
Here’s Why:
A Version Control System (VCS) allows you to revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. And sometimes you just want to know “who wrote this”, and having access to that information is worthwhile ?.
So What is Git?
Git is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people. Git is a Distributed Version Control System. So Git does not necessarily rely on a central server to store all the versions of a project’s files. Instead, every user “clones” a copy of a repository (a collection of files) and has the full history of the project on their own hard drive. This clone has all of the metadata of the original while the original itself is stored on a self-hosted server or a third party hosting service like GitHub.
Git helps you keep track of the changes you make to your code. It is basically the history tab for your code editor(With no incognito mode ?). If at any point while coding you hit a fatal error and don’t know what’s causing it you can always revert back to the stable state. So it is very helpful for debugging. Or you can simply see what changes you made to your code over time.
A simple example of version history of a file.
In the example above, all three cards represent different versions of the same file. We can select which version of the file we want to use at any point of time. So I can jump to and fro to any version of the file in the git time continuum.
Git also helps you synchronise code between multiple people. So imagine you and your friend are collaborating on a project. You both are working on the same project files. Now Git takes those changes you and your friend made independently and merges them to a single “Master” repository. So by using Git you can ensure you both are working on the most recent version of the repository. So you don’t have to worry about mailing your files to each other and working with a ridiculous number of copies of the original file.
GIT WORKFLOW
What is a Repository ?
A repository a.k.a. repo is nothing but a collection of source code.
There are four fundamental elements in the Git Workflow.
Working Directory, Staging Area, Local Repository and Remote Repository.
If you consider a file in your Working Directory, it can be in three possible states.
- It can be staged. Which means the files with the updated changes are marked to be committed to the local repository but not yet committed.
- It can be modified. Which means the files with the updated changes are not yet stored in the local repository.
- It can be committed. Which means that the changes you made to your file are safely stored in the local repository.
-
git add
is a command used to add a file that is in the working directory to the staging area. -
git commit
is a command used to add all files that are staged to the local repository. -
git push
is a command used to add all committed files in the local repository to the remote repository. So in the remote repository, all files and changes will be visible to anyone with access to the remote repository. -
git fetch
is a command used to get files from the remote repository to the local repository but not into the working directory. -
git merge
is a command used to get the files from the local repository into the working directory. -
git pull
is command used to get files from the remote repository directly into the working directory. It is equivalent to agit fetch
and agit merge
.
Assuming you already have a file the you want to place under version control. If not create a sample folder named ‘MuskCult’ and place some sample code files in it.
Step 0: Make a GitHub Account. Duh.
If you don't already have one, you can make one here.
Step 1: Make sure you have Git installed on you machine.
If you are on a Mac, fire up the terminal and enter the following command:
$ git --version
This will prompt open an installer if you don’t already have git. So set it up using the installer. If you have git already, it’ll just show you which version of git you have installed.
If you are running Linux(deb), enter the following in the terminal:
$ sudo apt install git-all
If you are on Windows:
Go to this link
Step 2: Tell Git who you are.
Introduce yourself. Slide in. Seriously, mention your Git username and email address, since every Git commit will use this information to identify you as the author.
$ git config --global user.name "YOUR_USERNAME"
$ git config --global user.email "[email protected]"
$ git config --global --list # To check the info you just provided
Step 3: Generate/check your machine for existing SSH keys. (Optional)
Using the SSH protocol, you can connect and authenticate to remote servers and services. With SSH keys, you can connect to GitHub without supplying your username or password at each visit.
Follow
thislinkto
learn more about SSH.
Go
hereto check if you have an existing SSH key.
Go
here to generate a SSH Key.
Go
hereto add the SSH key to your GitHub account.
And finally go
here to test its connection.
If you did setup SSH, every git command that has a link you replace it by:
Instead of : https://github.com/username/reponame
You use : [email protected]:username/reponame.git
Note : You can use both ways alternatively
I’ll be using SSH protocol in this tutorial.
Step 4: Let’s Git
Create a
new repository on GitHub. Follow this
link.
Now, locate to the folder you want to place under git in your terminal.
$ cd Desktop/MuskCult
Initialize Git:
And to place it under git, enter:
$ touch README.md # To create a README file for the repository
$ git init # Initiates an empty git repository
Now go edit the README.md file to provide information about the repository.
Add files to the Staging Area for commit:
Now to add the files to the git repository for commit:
$ git add .
# Adds all the files in the local repository and stages them for commit
OR if you want to add a specific file
$ git add README.md
# To add a specific file
Before we commit let’s see what files are staged:
$ git status # Lists all new or modified files to be committed
Commit Changes you made to your Git Repo:
Now to commit files you added to your git repo:
$ git commit -m "First commit"
# The message in the " " is given so that the other users can read the message and see what changes you made
Uncommit Changes you just made to your Git Repo:
Now suppose you just made some error in your code or placed an unwanted file inside the repository, you can unstage the files you just added using:
$ git reset HEAD~1
# Remove the most recent commit
# Commit again!
Add a remote origin and Push:
Now each time you make changes in your files and save it, it won’t be automatically updated on GitHub. All the changes we made in the file are updated in the local repository. Now to update the changes to the master:
$ git remote add origin remote_repository_URL
# sets the new remote
The git remote command lets you create, view, and delete connections to other repositories.
$ git remote -v
# List the remote connections you have to other repositories.
The git remote -v command lists the URLs of the remote connections you have to other repositories.
$ git push -u origin master # pushes changes to origin
Now the git push command pushes the changes in your local repository up to the remote repository you specified as the origin.
And now if we go and check our repository page on GitHub it should look something like this:
And that’s it. You’ve just added the files to the repository you just created on GitHub.
See the Changes you made to your file:
Once you start making changes on your files and you save them, the file won’t match the last version that was committed to git. To see the changes you just made:
$ git diff # To show the files changes not yet staged
Revert back to the last committed version to the Git Repo:
Now you can choose to revert back to the last committed version by entering:
$ git checkout .
OR for a specific file
$ git checkout -- <filename>
View Commit History:
You can use the git log command to see the history of commit you made to your files:
$ git log
Each time you make changes that you want to be reflected on GitHub, the following are the most common flow of commands:
$ git add .
$ git status # Lists all new or modified files to be committed
$ git commit -m "Second commit"
$ git push -u origin master
Now if we go and see our repo, we can identify whether the commit was successful by looking at the commit message for each file.
Step 5 : That’s all well and good… But How do I download and work on other repositories on GitHub?
Cloning a Git Repo:
Locate to the directory you want to clone the repo. Copy the link of the repository you want and enter the following:
$ git clone remote_repository_URL
Feel free to go ahead and clone the repo I created above using: https://github.com/Gothamv/MuskCult
Pushing Changes to the Git Repo:
Now you can work on the files you want and commit to changes locally. If you want to push changes to that repository you either have to be added as a collaborator for the repository or you have create something known as pull request. Go and check out how to do one here and give me a pull request with your code file.
Collaborating:
So imagine you and your friend are collaborating on a project. You both are working on the same project files. Each time you make some changes and push it into the master repo, your friend has to pull the changes that you pushed into the git repo. Meaning to make sure you’re working on the latest version of the git repo each time you start working, a git pull command is the way to go.
Now below is an example of a project my friend and I are collaborating on:
There has just been a commit on the repo
So to make sure those changes are reflected on my local copy of the repo:
$ git pull origin master
Here’s two more useful git commands:
$ git fetch
AND
$ git merge
In the
simplest terms,
git fetch
followed by a
git merge
equals
a
git pull
.
But then why do these exist?
When you
use
git pull
,
Git tries to automatically do your work for you. It is context sensitive,
so Git will merge any pulled commits into the branch you are currently working
in.
git pull
automatically
merges the commits without letting you review them first.
When you
git fetch
,
Git gathers any commits from the target branch that do not exist in your current
branch and stores them in your local repository. However,
it does not merge them with your current branch. 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
.
One More Thing:
.gitignore
So what is it?
.gitignore
tells git which files (or patterns) it should ignore. It's usually used to avoid
committing transient files from your working directory that aren't useful to
other collaborators, such as compilation products, temporary files IDEs create,
etc.
So in the
above example, files like __pycache__, .DS_Store are used by the system to store
information for faster access. This is not useful for other collaborators. So we
can tell git to ignore them by adding a
.gitignore
file.
Use the
touch command to create the
.gitignore
file:
$ touch .gitignore
And you can add the following patterns to tell git to ignore such files.
/*.cmake
/*.DS_Store
/.user
/build
etc. depending upon the files you want git to untrack
by Gowtham Venkatesan Basics-of-git
Step 1: Install Git and Create a GitHub Account
There are several different ways to install Git.
- Install Git on Windows
- Install Git on Mac
- Install Git on Ubuntu
- Install Git on CentOS 7
- Install Git on CentOS 8
Note: If you already have Git installed on your machine, it's best to update to the latest version available.
After installing Git on your machine, the next step is to create a free GitHub account.
1. Visit the official account creation page: Join GitHub
2. Pick a username, enter your email address, and choose a password.
3. Opt for or opt out of receiving updates and announcements by checking/unchecking the Email preferences checkbox.
4. Verify you're not a robot by solving the Captcha puzzle.
5. Click Create account.
6. GitHub sends a launch code to the specified email address. Copy-paste the code in the designated field.
7. Optionally, enter account personalization details when asked or Skip, and click Continue.
Step 2: Create a Local Git Repository
After installing or updating Git, the next step is to create a local Git repository. Git repository
1. Open a Git Bash terminal and move to the directory where you want to keep the project on your local machine. For example:
cd ~/Desktop
mkdir myproject
cd myproject/
In this example, we changed the directory to Desktop and created a subdirectory called myproject.
2. Create a Git repository in the selected folder by running the git init command. The syntax is:
git init [repository-name]
Step 3: Create a New Repository on GitHub
GitHub allows you to keep track of your code when you're working with a team and need to modify the project's code collaboratively.
Follow these steps to create a new repository on GitHub:
1. Log in and browse to the GitHub home page.
2. Find the New repository option under the + sign next to your profile picture, in the top right corner.
3. Enter a name for your repository, provide a brief description, and choose a privacy setting.
4. Click the Create repository button.
GitHub allows you to add an existing repo you have created locally. To push a local repository from your machine to GitHub, use the following syntax:
git remote add origin https://github.com/[your-username]/[repository-name.git]
git push -u origin master
Step 4: Add a File to the Repository
Git notices when you add or modify files in the folder containing the Git repository but doesn't track the file unless instructed. Git saves the changes only for the files it tracks, so you need to let Git know you want to track changes for a specific file.
You can check which files Git is tracking by running:
git status
Git notifies you if you have any untracked files. If you want Git to start tracking a file, run the following command:
git add [filename]
Rerunning the git status command shows that Git is tracking the specified file.
Step 5: Unstage Files on Git
Working with Git usually involves adding all the files to your index to prepare them for a commit. If you want to remove some files from the index before committing, you have to unstage the files in Git.
One way to unstage files on Git is to run the git reset command. The syntax is:
git reset [commit] -- [file_path]
Note:
You can also use the
rm
command to unstage files on Git.
The syntax is:
git rm --cached
[file-name].
Step 6: Create a Commit
After adding the specified files to the staging environment, instruct Git to package the files into a commit using the git commit command. Git then stores that file version.
The syntax is:
git commit -m "Notes about the commit"
Add a message at the end of the commit to state whether it's a new feature, a bug fix, or anything else. Commits remain in the repository, and they are rarely deleted, so an explanation of what you changed helps other developers working on the project or help you keep track of all the changes.
Step 7: Undo Last Commit
Important: Git allows users to revert the last commit. However, other developers could have already retrieved the updated project, and deleting updates from one system could cause conflicts for other team members.
Use the revert and reset commands to undo changes and revert to a previous commit.
To undo a published commit, use the following syntax:
git revert [hash]
A hash is a code that identifies each commit. Obtain a commit hash by running:
git log
first ran the git log command to obtain the commit hash and then reverted the last commit by running git revert with the commit hash we obtained.
Step 8: Create a New Branch
The first branch in a git repository is called master, and it is the primary branch in a project.
Creating a new Git branch means creating a copy of the project from a specific point in time. Branches in Git allow users to make new features without applying the changes to the main branch while the feature is in development.
The common method for creating a new branch is by running:
git branch [new_branch_name]
Step 9: Switch Branches
Having several branches of a Git project provides a test environment for developers to track progress without affecting the production version of an application. Git allows you to switch between branches with the checkout command easily. The syntax is:
git checkout [branch_name]
Replace [branch_name] with the branch name you want to access.
Step 10: Rename a Local or Remote Git Branch
In Git, you can rename a local or remote Git branch.
The syntax for changing a local Git branch name is:
git branch -m new-name
Since there isn’t a way to directly rename a remote Git branch, you first need to delete the old branch name, then push the new branch name to the remote repository.
Step 11: Delete a Local or Remote Git Branch
You may decide to delete a Git branch after merging the changes with the master branch or if the branches become corrupted.
You can delete local and remote Git branches.
Deleting a local branch doesn't affect a remote branch. To delete a local Git branch, run:
git branch -d [branch_name]
Use the following syntax to delete a remote Git branch:
git push [remote_project] --delete [branch_name]
Step 12: Set Upstream Branch
Sending something upstream in Git means that you are sending it back to the repository owner.
Using the git set upstream command, you can choose the flow direction of your current local branch. The command also allows you to change the default remote branch.
The tutorial on What Is Git Upstream and How to Set an Upstream Branch deals with the different methods for setting an upstream branch and gives a detailed explanation on the topic.
Step 13: Remove a Git Remote
A git remote is a connection to a repository hosted on a remote server – GitHub, BitBucket, GitLab, or any other remote location.
However, over time, the remote repository may move to another host, or a team member may stop working on the project. The remote in question is then no longer needed.
There are several ways to remove a Git remote. One of the ways is to delete a remote using the command line. The syntax is:
git remote remove [remote name]
In the following example, running git remote -v shows the available remotes, 'origin' and 'test-remote.' After removing 'test-remote' and rerunning git remote -v to list available remotes, we see that the only available remote is 'origin.'
Step 14: Git Merge
Git merge unifies multiple commit sequences into a single commit. It can combine two branches, thus integrating the independent development lines into a single branch.
After merging two branches, Git updates the current branch to reflect the merge, but the target branch isn't affected. That means you have to use the git branch -d command to delete the obsolete target branch.
For example, you may want to merge a new feature branch into the main branch. Follow the steps below:
1. Run the git status command to ensure that HEAD is pointing to the correct merge-receiving (master) branch. If it is not, run git checkout master to switch to the master branch.
2. Run git fetchto pull the latest remote commits and git pull to ensure the main branch has the latest updates.
3. Run git merge X where X is the name of the branch you want to merge into the receiving branch.
Step 15: Resolve Merge Conflicts
Merge conflicts usually occur when multiple developers work on the same code of a project or when they work with several development branches. Git merge warns the user about these conflicts.
Although most merge conflicts resolve automatically, there are cases when git merge cannot resolve an issue.
Note: The detailed guide on How To Resolve Merge Conflicts in Git offers tips for preventing merge conflicts, as well as ways to resolve existing merge conflicts.
Step 16: Create a Pull Request
Create a pull request (PR) to inform a repository owner that they should review the changes you've made to their code. Then the owner can approve the pull request and merge the changes into the main repository.
If you are the co-owner or owner of a repository, you don't have to create pull requests to merge your changes. However, you can still do it to keep track of your feature updates and history.
For this guide, we will create a readme file for our repository locally and make a pull request on GitHub to illustrate the process.
Follow the steps below:
1. In Git Bash, create an empty readme file by running touch readme.md.
2. Create and switch to a new branch on which to modify the file. Run:
git checkout -b create-readme-file
3. Open the readme file in a text editor and add the text you want it to contain. In this example, we will use the Nano text editor to modify the file within the command line window. Run nano readme.md.
4. After you save the file, track it by running git add readme.md.
5. Create a commit.
git commit -m "Added a readme file"
6. Push the changes to GitHub.
git push origin create-readme-file
7. Log in to your GitHub page. There is now a Create pull request option in your repository with the branch name we created in the command line. Click the Compare & pull request button.
8. GitHub states if you can merge the branches and apply the changes. Optionally, add a comment about your pull request and click Create pull request.
Now the repository owner, in this case, you, can review the changes and accept or reject them.
You can accept the changes in the Pull requests tab on GitHub. When you merge the branches, delete the obsolete branch by clicking Delete branch to keep the repository clean.
Step 17: Synchronize Changes on GitHub and Locally
When you merge changes on GitHub, they don't appear automatically in your local repository. You have to pull the changes to your local repository to see the updates.
Synchronize your local repository with GitHub by running:
git pull origin master
The command updates your local repository to match the one on GitHub, and states the changes.
In the following example, we first switched to our master branch, and Git warned us that we should update our local repository:
Conclusion
Download Git commands cheat sheet to have all Git commands in one place for future use.
By Bosko Marijan How-to-use-git
|
|
Home/ Info/ Products/ BIG TECH Metaverse Metaverse Vs. Virtual Reality PC Buyers Guide/ IEEE 802 Standards Social Media Platforms Technology Videos/ Computer & IT Certifications Processor Generations Memory SSD Vs. HDD HTML JAVA Python Angular.js Venus Project/ Computer Security and Law Glossary Contact
Certified Enterprise Blockchain Professional (CEBP) Web 3.0 Satoshi Nakamoto Cryptocurrency Ethereum NFT Merkle Tree El-Salvador eNaira
AWS Certification Google Certification Oracle Certifications cisco certifications Huawei Certification Microsoft Certifications Linux Certification Business Certifications
Google-Cloud-Platform-Guide Amazon-Web-Services-Guide Global-Cloud-Infrastructure-Of-AWS Amazon-Web-Services-Cli-Guide AWS-Cloudformation Devops Microsoft-Azure Oracle-Cloud Digitalocean-Cloud Openstack-Cloud
Active Components Passive Components Test Electrical Components Electronics Classification
Copyright BICT Solutions Privacy Policy. | Terms and Conditions apply | All rights reserved.