What is Git and why is it useful
Let’s suppose a software Engineer is working as a front end developer and working on some of the features of front end like a “Buy Now” button and all of a sudden the customer comes back and asks the developer to change the requirements and since they are not using a Version control system the developer will be really frustrated. Now he has to change his code and what if the customers comes back tomorrow and asks him to change another feature.
That is the reason why it is best to use a version control system while developing code, if the developer is working on a certain feature and commits the code, that version of the code is saved with a unique commit ID and the developer can always go to that particular version very easily even if the customer changes the requirement every week, the developers will not be frustrated and they will have different versions of code available to work on.
Git is a distributed version-control system with a central repository for tracking changes in source code during software development. It is designed for coordinating work among programmers, it can be used to track changes in any set of files.
What is a Local Repository?
The Local Version control system is present on the local desktop of the developer. Developers make changes in their private workplace and after commit, git provides a local or a private copy of the whole repository. Users can perform many operations with this repository such as add file, remove file, rename file, move file, commit changes, and many more.
((basically in this diagram or explanation you have to explain that)) “suppose this is the desktop of the developer which has git installed on it and the developer is working on the html file, there are 3 different workspaces on the desktop, the working directory is where the developer is actively developing the code, the html file has to move through the staging area in order to be committed and moved to the local repository. Then it moves from the local repository the remote or central repository so that different developers can access the code you are working on
What is a Working Directory and Staging Area
Whenever a developer commits the code, Git looks for the files present in the staging area. Only the files present in the staging area are considered for commit and not all the modified files.
Let us see the basic workflow of Git.
1 − You modify a file and add these files from the working directory.
2 − You add these files to the staging area.
3 − You perform commit operation that moves the files from the staging area. After push operation, it stores the changes permanently to the Git repository.
If suppose you want to add the web.html file from working directory to staging area is
# Git Add web.html
Git command used to add the web.html file from staging to Local repository is
# Git Commit web.html
Life cycle of Git.
You clone the Git repository as a working copy.
- You modify the working copy by adding/editing files.
- If necessary, you also update the working copy by taking other developer’s changes.
- You review the changes before commit.
- You commit changes. If everything is fine, then you push the changes to the repository.
- After committing, if you realize something is wrong, then you correct the last commit and push the changes to the repository.
((Please change the diagram below))
Shown below is the pictorial representation of the work-flow.
What is Git Branching
Git lets you branch out from the original code base. This lets you more easily work with other developers, and gives you a lot of flexibility in your workflow.
Here’s an example of how Git branches are useful. Let’s say you need to work on a new feature for a website. You create a new branch and start working. You haven’t finished your new feature, but you get a request to make a rush change that needs to go live on the site today. You switch back to the master branch, make the change, and push it live. Then you can switch back to your new feature branch and finish your work. When you’re done, you merge the new feature branch into the master branch and both the new feature and rush change are kept!
When you merge two branches (or merge a local and remote branch) you can sometimes get a conflict. For example, you and another developer unknowingly both work on the same part of a file. The other developer pushes their changes to the remote repo. When you then pull them to your local repo you’ll get a merge conflict. Luckily Git has a way to handle conflicts, so you can see both sets of changes and decide which you want to keep.
Some Git commands.
- To install git on the server
# yum install git
2. To initialize git repository
# git init
3. To check the current status of Git repository, It lets you see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.
# git status
4.To commit a file with the description of “first commit”
# git commit -m “first commit”
5. To add a new remote repository, use the git remote add command on the CLI, in the directory your repository is stored at.
A remote name, for example, origin for easy access so that you don’t have to type the url every time you import the repository.
A remote URL, for example, https://github.com/user1/myrepo.git
# git remote add origin https://github.com/user1/myreo.git
- git push command updates the remote repository with local commits.
# git push origin master
To pull the code from Remote to Local Repository
#git pull https://github.com/user1/myrepo.git
- To clone a git repository, use the “git clone” command with the URL of your Git repository.
# git clone https://github.com/username/project.git Cloning into ‘project’
- # Git fetch
git fetch command really only downloads new data from a remote repository – but it doesn’t integrate any of this new data into your working files
- Git pull command directly integrates it into your current working copy files
#Git pull
