Branching in git :
Branching in git is a clone or copy of original repository which can be used to worked upon in such a manner that no matter if we add, modify or delete the whole clone repository, the main branch (also called master branch) remains safe for production use further.
These clone are then used to work on separate features of the same product by different individuals in such a manner that once all features are set to desired standards, all the branches are then merged to be worked.
Whenever a new branch is created, all data from the master (root) branch is copied to the new branch.
In above snip, we can see that as soon as we created a new branch via "git checkout -b dev" ; HEAD now points to a new branch named as dev .
Note: HEAD is the pointer that points towards the latest commit.
Let's take an example of how HEAD works, will start by making some changes to our text file then we will be comparing the before and after results of git log, let's have look before committing the changes:
In above snip we can see that HEAD is currently pointing to both master and dev branches but now since we have made a new branch dev, from the next commit, HEAD will be pointing to dev; let's have a look:
Now, suppose we what to be working on master node again (we can do so via git checkout <branch_name\> ; here -b will not given as it creates a new branch altogether
)
So what happens to the changes made in one of the clone branch? Will it be reflected to the other?
The answer is no, each branch will then act as an independent one; let us understand it with an example below:
When in dev branch, as we can see the last command was added only in dev node not present in master.
Also, before all that, just we want to check which brach are we on currently
GitHub:
GitHub is an online software development platform which is used for storing, tracking, and collaborating on software projects. It makes it easy for developers to share code files and collaborate with fellow developers on open-source projects.So basically GitHub is practical platform that uses Git in background as version control system.
Now that we have an insight on GitHub; let us now cover some of the very practical uses of it.
Starting first, we have to make a profile on GitHub which might just look like:
Of all the times we have used the word clone; let us check how do we clone a repository from GitHub to our local machine. For that, we first will be creating a new repository on GitHub name Git_forBlogs by clicking on the New button present on the above snip in green colour.
As soon as we create the repository; we can clone it to our local machine by copying the url shown in above snip ; also, we create a new repository by clicking on "creating a new file" and adding a name to it further:
Note: When cloning the repository; we can only clone the repository which are public.
Now let's make changes to our newly made repository "Blogs"
New we will see how can we implement these changes to our local machine, let's have a look:
As we can see in above snip, all the changes made on GitHub repository was evident here as well, just by cloning it, how crazy it that !!
Now that we have seen how clone works, let's stage the Blogs file and see where the head now points!
As shown in below snip, the head now points to the main (default repository for GitHub) this is because of the latest commit done on Blogs.
Remote in git:
Remote in git allows the user to establish any connections between local repository to GitHub. It is more like a bookmark rather than the direct link to the repository which can allow us to view, add, delete or modify to any other repository which is present on application. Let us have a look on how it's used (-v is used to view the connections).
Access tokens:
In above snip origin is the access token needed to establish remote connections. We can also change it via generating personal access tokens from the application (GitHub). Let us see how can we generate a token via GitHub:
Once we have generated token, we can now use it to further to push changes from GitHub to local. This access token is used because the repository present on GitHub is a private one and needs permission from the owner of repository present on GitHub .
In below snip the origin mentioned is the url token for remote of the repository. We have now made some changes in GitHub repository and want it to reflect on our local machine - this called pull function. Git pull is used when we want all the changes made on the GitHub be implemented on a particular repository of our local device, let us see the status of git before doing git pull (We have added one more command to Blogs which is not reflecting currently)
Now that we have pulled the changes from repo to local, let us check the status of it now, the highlighted command is now added post the git pull :
Now that we are through with git pull, let's check git push. Git push is turning over all the changes made to a particular branch to GitHub. According to GitHub: "When you want to share a branch with the world, you need to push it up to a remote to which you have write access. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on."
To explicitly use git push, we need to push the personal access token from the private repo on our local machine:
This way now we have established connection between the local machine and application, lets make some changes now on local and try pushing it to GitHub:
Fetch: Git fetch is pull command followed by a merge command.To synchronize your work with a given remote, you run a git fetch <remote>
command . This command looks up which server “origin” is , fetches any data from it that you don’t yet have, and updates your local database, moving your origin/master
pointer to its new, more up-to-date position.
Next up we will take about day to day uses of Git in industry .
Stay tuned folks!!