How to Use GitHub Like a Pro
Josh Anderson provides an excellent primer on how to use GitHub like a professional.
Join the DZone community and get the full member experience.Join For Free
let’s begin today’s post with a fact: as of right now (at the time of writing), github has 21 million repositories and 9 million users— which isn’t too bad at all! for developers, github offers an enormous range of tools, wikis, and information, so we want to help show you how to use it like a pro.
before understanding what github is, the first thing to do is understand what git is. git is an open source version control developed by the founder of the linux, linus trovalds. like any other version control, git manages and stores the different versions of a project.
github is developed over the git version control so that it brings your project on the web for social networking and shares your code with other developers, inviting them to extend or improve your code. it provides collaboration features like wikis, project information, version releases, contributors to the repository, open and closed issues, and more. all this allows developers to easily download the new version of an application, make changes, and upload it back to the repository.
git is a command based tool to perform version controlling for the source code. it also provides a graphical user interface which lets you contribute to projects. you can download the desktop version of github here .
getting started with github
repository – repository is a directory or storage space where all your project related files are stored. this can include source code files, user documentation, or installation documentation; everything can be stored in the repository. each project will have its own repository along with a unique url on github. you can create either a private repository—which is a paid version—or a public repository, which is free and open source.
to create a repository, go to the repository tab and click on ‘create new repository’, where you can then fill in details like the repository name and description.
forking – the process of forking a repository lets you create a copy of an original project as a repository in your github account, allowing you to work locally on the source code. you can make changes to the source code (such as fixing bugs) and commit these to your repository.
in order to fork a repository, you can navigate to the repository url and click on ‘fork the repository’ to create a repository in your local account.
commit – commit is when an individual makes changes to source code. every time you save code it creates a unique id to identify what changes to the files were submitted for the particular commit. it also takes up the title and description of the commit to specify what changes were made and what this commit signifies.
once you have forked a repository, you can make changes in the file. let’s make changes to the readme.md file. i have updated the readme.md file by adding a second line as shown below.
to update this file, go to the ‘commit changes’ section located at the bottom of the file and update the title of the commit as well as the description:
upon clicking the 'propose file change' changes will be committed in the new branch.
pull request - once you are done with making changes, you can submit a ‘pull request’ to the original project owner. if your fix or changes are approved after testing, he/she can pull your changes in the original project. all pull requests are managed from the self-titled tab which shows every pull request submitted by each contributor. it will compare the updated source code with the original source code, and will provide the list of files that are changed and committed. the owner of the project will have a comprehensive view of all the updated changes in each file, along with the comparison view.
once you’re done committing changes in the new branch, you’ll be taken to a pull request screen to generate the pull request for your new file changes.
click on the create ‘pull request’ button. a pull request will be created and will be visible to the project owner under the pull request section.
merging pull request – once the changes in the pull request are reviewed and approved, now is the time to merge the changes in the original source code. in order to merge the request into the original repository, you need to have a push access on the repository.
the project owner can select the submitted pull request and review any changes from the ‘files changed’ tab. clicking on each file will show you what has been changed, added, or deleted.
once the project owner verifies and approves the changes, the new project is ready to merge into the original project.
click on ‘merge pull request’ to merge it into the original branch.
github visual studio extension
github is a powerful open source version control, and provides many capabilities through both git console and the github desktop version. but, like every source control, it requires direct integration into your developer tool. fortunately, microsoft and github recently announced the availability of github enterprise in azure, and they have also launched the github visual studio extension, allowing developers to easily connect and work with github projects directly from visual studio. team explorer support for git allows you to do commits, branching, and conflict resolution. you can download the extension here .
github is not just another version control to keep track of changes. instead it is a distributed version control which allows users to share code with developers across the globe.
other key benefits of github include:
- support from the open source community
- a distributed version control system
- social networking features like wikis
- manage code with multiple options
- show off! if you’ve created something fancy, github provides the easiest way to share it with the open source community.
github also offers social networking capabilities to help you increase your network so that your code can be updated by various developers. as the saying goes, many hands make light work, and for that reason alone you should be using it.
Published at DZone with permission of Josh Anderson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.