Git | GitHub and Version Control
Tags: github, git, opensource, beginners
Published: 2020-05-29 13:50:05

# Content

- Introduction (Terms)
- Understanding the GitHub Work-Flow
- What's Open Source
- Bingo 🥳🥳. You Made your first Contribution.
- Important Perks and Links.

---

# **Introduction**

# 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**. Git does rely on a central server to store all the versions of a project's files. Instead, every user "Clones" a copy of a repository and has the full history of the changed that had been tracked before.

# GitHub

GitHub is a core hosting platform for version control collaboration. GitHub is a company that allows you to host a central repository in a server.

I think you are now pretty clear about.

- What is git.
- What is GitHub. and how it is different from git.
- Version Control.

---

# **Understanding the GitHub Work-Flow**
### (Dive into how GitHub works?)

Let me Explain you with some UML Diagrams...

### **Create a Branch**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cenfqns8p51k27onsi2g.png)

When you have one project and different ideas, Branch creation comes into play you can work with different ideas in Different branches.

When you create a branch in your project, you're creating an environment where you can try out new ideas. Change you make into the current working branch do not affect the `master` branch i.e `base` branch. The current working branch is safe to be modify and use and will not be merge until the maintainer of that project reviews and merge it with master branch.

**Creating a branch when raising PR's** ```git checkout -b <Your username>/<Branch-name>```


### **Add commits**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zj9cn3a0rsdc8abl7ua8.png)

When you have successfully created your branch, you can now make changes. whenever you make a change like deleting, modification, additions etc. you make a commit, and adds the changes to the working branch. This commit addition keeps track of the changes you make on the working branch.

Most interesting part is whenever you dealt with `Bugs 🐛🐛` , You can roll back to previous committed changes. and can decide easily in which direction you want to move on. See such an easy project management dope level stuff it is.

**Command for Commit** ```git commit -m "<Your message Goes Here>"```

### **Open Pull request**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kk0vmxfzmt58a9pxrxqd.png)

Pull request is somewhat saying that `Hey maintainer may I contribute to your project, I have made some changes which is good to merge into your project, Kindly have a look`.

So, Here you can open a Pull Request at any point during the development. and when you make your pull request and compare it you dealt with a message block. It's a good practice to make it more confirming by Commenting maintainer, that what's in it? and how one can overcome the Bug, or any issue.. Mention the GitHub's User by `@<Username>` and You done here...

### **Discuss | Review code** (Best practice is to interact)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zspajhlkhv25n0rv4608.png)

Once a Pull Request has been opened, the person or team reviewing your changes may have questions. might be possible that the coding style doesn't match project's guidelines, the changes missing unit tests. Pull Requests are designed to encourage and capture this type of conversation.

If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change back to fire. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.

### **Deploy**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/u60lpgq5qj6z10ya6v0b.png)

With GitHub, you can deploy from a branch for final testing in production before merging to master.

Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
As mentioned earlier...

### **Merge**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/9p27bdchf2evo5ytber3.png)

Now that your changes have been verified in production, it is time to merge your code into the master branch.

Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how the changes were made.

---

# ***Bingo 🥳🥳. You Made your first Contribution.***

---

# **Important Ending Perks and Link** (for Beginners)

- [GitHub Markdown Cheat Sheet](https://guides.github.com/features/mastering-markdown/)
- [GitHub Blogs](https://github.blog/)
- [GitHub Products](https://github.blog/category/product/)
- [Follow me (Let's Improve Together)](https://github.com/Uyadav207)

---
   
#                   **I 🧡 Open Source**

- Contribute to My Blog [Here](https://utkarsh-blog.netlify.app/)

<a href="https://github.com/Uyadav207/Utkarsh-Blog/issues"><img alt="Bitbucket open issues" src="https://img.shields.io/bitbucket/issues/Uyadav207/Utkarsh-Blog"></a>

<a href="https://github.com/Uyadav207/Utkarsh-Blog/blob/master/LICENSE"><img alt="GitHub" src="https://img.shields.io/github/license/Uyadav207/Utkarsh-Blog"></a>

---
Thanks for reading, 🙏🏻
Happy coding...
[Utkarsh Yadav](https://www.linkedin.com/in/utkarsh-yadav-37242b17b/)