GitHub
The “Git” in GitHub
To understand GitHub, you must first have an understanding of Git. Git is an open-source version control system that was started by Linus Trovalds – the same person who created Linux. Git is similar to other version control systems – Subversion, CVS, and Mercurial to name a few.
Version control systems
So, Git is a “version control system,” what’s that mean? When developers are creating something (an application, for example), they are making constant changes to the code and releasing new versions, up to and after the first official (non-beta) release.
Version control systems keep these revisions straight, and store the modifications in a central repository. This allows developers to easily collaborate, as they can download a new version of the software, make changes, and upload the newest revision. Every developer can see these new changes, download them, and contribute.
Similarly, people who have nothing to do with the development of a project can still download the files and use them. Most Linux users should be familiar with this process, as using Git, Subversion, or some other similar method is pretty common for downloading needed files, especially in preparation for compiling a program from source code (a rather common practice for Linux geeks).
In case you are wondering why Git is the preferred version control system of most developers, it has multiple advantages over the other systems available, including a more efficient way to store file changes and ensuring file integrity. If you’re interested in knowing the details, check out this page to read a thorough explanation on how Git works.
The “Hub” in GitHub
We’ve established that Git is a version control system, similar but better than the many alternatives available. So, what makes GitHub so special? Git is a command-line tool, but the center around which all things involving Git revolve – effectively, the Hub, is GitHub.com, where developers can store their projects and network with likeminded people.
Let’s go over a few of the main reasons that geeks like to use GitHub, and learn some terminology along the way.
Repository
A repository is a location where all the files for a particular project are stored, usually abbreviated to “repo.” Each project will have its own repo, and can be accessed by a unique URL.

Forking a repo
“Forking” is when you create a new project based off of another project that already exists. This is an amazing feature that vastly encourages the further development of programs and other projects. If you find a project on GitHub that you’d like to contribute to, you can fork the repo, make the changes you’d like, and release the revised project as a new repo. If the original repository that you forked to create your new project gets updated, you can easily add those updates to your current fork.
Pull requests
You fork a repository, make a great revision to the project, and want it to be recognized by the original developers, maybe even included in the official project/repository. You can do so by creating a pull request, so the authors of the original repository can see your work, and then choose whether or not to accept it into the official project. Whenever you issue a pull request, GitHub provides a perfect medium for you and the project’s maintainer to communicate.
Social networking
The social networking aspect of GitHub is probably its most powerful feature, and is what allows projects to grow more than anything else. Each user on GitHub has their own profile, which can act like a resume of sorts, showing your past work and contributions to other projects via pull requests.
Project revisions are able to be discussed publicly, so a mass of experts can contribute knowledge and collaborate to advance a project forward. Before the advent of GitHub, developers interested in contributing to a project would usually need to find some means of contacting the authors, probably by email, and then have to convince them that their contribution is legit and they can be trusted.
Changelogs
When multiple people are collaborating on a project, it’s really hard to keep track of who changed what, and to keep track of the revisions that took place. GitHub takes care of this problem by keeping track of all the changes that have been pushed to the repository.
GitHub isn’t just for developers
All this talk about how GitHub is ideal for programmers may have you believing that they are the only ones who will find it useful. Although it’s a lot less common, GitHub can actually be used for any types of files – so if you have a team that is constantly making changes to a word document, you can actually use GitHub as your version control system. This practice isn’t common as there are better alternatives, but keep it in mind.
Now that you know what GitHub is all about, are you ready to get started? Head over to GitHub.com and be sure to check out their help pages after signing up.
Git VS SVN:
Git is not better than Subversion. But is also not worse. It's different.
The key difference is that it is decentralised. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.
With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.
With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.
Distributed vs Centralised
The main point in Git vs SVN debate boils down to this: Git is a distributed version control system (DVCS), whereas SVN is a centralized version control system. The difference between these two is that in distributed version control system, every developer has their own local copy of the full version history, whereas in centralised version control systems the version history is stored in a server-side repository.
In order to make changes, each peer checks out the files they want to modify and commits changes to the central location. The main advantages in distributed version control system (Git in this case) are the speed of local operations and enhanced collaboration. Since the majority of the operations are done locally, you do not need a constant connection to the server where a central repository is located. As a result, operating a distributed version control system is a lot faster. To Read more : https://deveo.com/git-vs-svn/
Set-up GitHub in Ubuntu
Follow the steps to Set-up GitHub in Ubuntu-
Step 1. Download the GitHub-
sudo apt-get install git
Step 1. Download the GitHub-
sudo apt-get install git
Step 2. To check if it is successfully installed-
git --version
git --version
Step 3. Configured GitHub with your GitHub account credentials
git config --global user.name "xyz"
git config --global user.email "xyz@domain.com"
To check if it is successfully configured or not enter command-
git config --list
If your GitHub credentials successful configured then it will be show following as -
user.name= xyz
user.email= xyz@domain.cm"
git config --global user.name "xyz"
git config --global user.email "xyz@domain.com"
To check if it is successfully configured or not enter command-
git config --list
If your GitHub credentials successful configured then it will be show following as -
user.name= xyz
user.email= xyz@domain.cm"
Step 4. Now create a folder say like - local_repo
Step 5. Now create a new local Git repository using following command-
git init local_repo
git init local_repo
Step 6. Now go into this dir- cd local_repo
Step 7. Now create any repository in GitHub server and copy the url of this repostory
Step 8. Now check out the GitHub Server repository in your local_repo by-
git remote add origin (url of GitHub server repositort-http://github.com/user_name/repository.git)
git remote add origin (url of GitHub server repositort-http://github.com/user_name/repository.git)
Step 8. Now add any files or modified something in this local repo and add this file on git using command-
git add filename or git add -A ( it will be added all files)
git add filename or git add -A ( it will be added all files)
Step 9. Now check the status by command-
git status
git status
Step 10. Now committed the changes-
git commit -m "any comment suggested"
git commit -m "any comment suggested"
Step 11. Now it's time to push your changes on github server so go first in remote- git remote
Step 12. Before pushing any thing take update-
git pull origin master
git pull origin master
Step 13. So now push your changes-
git push origin master
git push origin master


Comments
Post a Comment