A gentle introduction to Git and GitHub — the ELI5 way A software development team generally comprises of two or more individuals working on the same codebase for a particular project. This makes it important for a developer to be aware of the new changes made by the rest of the team over time in an easy to understand and hassle-free manner. This where the concept of a comes in handy. Git is a widely used VCS for software development. Version Control System (VCS) Through this powerful yet simple mechanism, all the team members are able to work on a single code base (a.k.a. the master branch) through a well-documented approach. xkcd ❤ btw git isn’t complicated at all What is a Git Repository? A Git repository refers to an online container where your source-code can be stored, contributed to, and managed over time. It is analogous to a smart folder on your workstation which keeps track of all the changes that has been made to it ever since its initiation. If you have a proper understanding of the structure of your repository, you can build on top of your existing code, rather than starting from scratch and running it by others in a weird manner. How to set-up a Git Repository on GitHub GitHub landing page after logging in After clicking on , you are given the following fields to fill and initialize your new repository. The repository could either be (restricted to contributors only) or (freely available to all). New Private Public The file is one of the most important markdown files in your repository. As a best practice, you should always populate it with text that is indicative of your progress, debugging information, or as a general (or comprehensive) guide to how visitors can run your project on their personal workstations. Once done, you are greeted with the repository. README GitHub Repository landing page Basic Workflow of a GitHub Repository Cloning (downloading) your repository Cloning a repository You could either simply download your repository using the option or introduce yourself to a world of limitless possibilities by using the for Git. If you don’t already have Git installed on your system, you may refer to this amazing guide . Download ZIP Command Line Interface (CLI) here Cloning a GitHub repository using CLI CLI Command: git clone <repository-url> <destination-directory> The following example illustrates a simple cloning of the repository using just the URL. But in case you want to put the entire structure into a folder name of your choice, you could add the destination directory parameter as well. What are Remotes? In contrast to a local repository (offline), a remote is a reference to a repository which is hosted on a cloud platform used by GitHub. is an example of such a repository we have created previously and can be referenced using the URL. https://github.com/ss-is-master-chief/MyGitHubRepository.git But it is tedious to use the entire URL every time we need to perform an operation via git. This is where we could assign an to the repository URL for our convenience. By default, the URL is referred to as and can be changed if necessary. alias origin refers to obtaining/downloading the changes/data from the server which houses our repository. Fetch refers to uploading the changes/data from our local machine to the server which houses our repository. Push For demonstration purposes, let’s say we wish to add another remote called which is an alias to the same URL — upstream https://github.com/ss-is-master-chief/MyGitHubRepository.git It is a good practice to use the remote to fetch files from our main repository (might be someone else’s version) and push to our own repository called . upstream origin Let’s talk about Branches If you head over to your GitHub Repository and click on , you’ll be shown a list of branches which you (or contributors) have created. Currently, since we have just set up the repository, you’d be shown only one i.e. . The branch is the main branch on which your final code is supposed to exist. Branch the master master Now, what if you have a feature in mind which is yet in its experimental phase? This is where creating and working on a new branch comes into the picture. A `Branch` is a new track which starts off with the current master code as it’s base code. It has been demonstrated via the following diagram. You may work on the new branch called BigFeature, without affecting your main code-base. The two branches master and BigFeature can be worked on independently. In the command line, we can use the command git branch to return all the branches we currently have. The * refers to the branch we are currently working on. We use the git checkout -b <Branch-Name> to create a new branch. CLI Command: We can also switch to another branch using the command git checkout <Branch-Name> If we wish to delete a branch, we may use git branch -D <Branch-Name> . Let us set up a branch using the Git CLI. The above changes have been carried out locally. This means that nothing has yet been reflected back to our GitHub (online) repository. Let us create another branch called test, make some changes to it and upload it to our main repository. What are Git States? Git States refer to which state your modified files are currently in. For example, once you have made some changes to the `README.md` file, the file is now `modified`. But this doesn’t mean, we can upload the changes to the repository right away. To ensure a procedure which confirms your changes, we have to add the files to the . modified staging area Consider an example of 10 students sitting in an auditorium. Out of them, 5 of them are told to dress up i.e. and asked to go up to the stage. This means that the 5 students are in the . Now, the students are ready to perform i.e. to the play. modified staging area commit Let’s represent this scenario via Git. We will make some changes to the . We have added the line “ to the end of the file. README.md These are some changes” We can check what the changes were using the git diff CLI Command: To check which files were changed, we can use the git status. It will return the status of the staging area. In the following demonstration, we notice that `README.md` is tagged as `modified` and represented in color `RED` (in your terminal window). CLI Command: Now we shall add the changes (of our choice) to the staging area. Basically, we are trying to curate the changes (but maybe not all) we want to upload to the repository. We will use the git add <file-name>. The modified tag will now be changed to `GREEN` (in your terminal window). CLI Command: Once we have added the files, we will (upload) the changes to the of our repository. commit master branch Merging Let us create a new branch called new_branch and make some changes to it by creating a new file called new_branch_file.txt. We have added the line “This is a new branch file” to the new_branch_file.txt. The two branches master and new_branch are independent of each other. Changes in the new_branch will not be reflected in master until we want it to. Independence has been demonstrated in the following snippet. Your repository landing page shall indicate if there are any changes between the master and any other branches created by you or any of the other contributors to your project. Through the Pull Request mechanism, you can review the changes proposed by a developer. Moving on, you could either let it slide or merge it into the destination repository. Merging the CLI way Phew.. that was a lot. Thank you for reading my attempt at explaining how you could get started with Git and GitHub. Please feel free to comment on how I should improve my writing, and Clap-n-Share if you loved it!
