Git Get Go - Training Through Tales

It’s an era of the 1800s. A small group of developers is working on a major project in a software company. There is a lot of chaos in the office as everyone is shouting their heads off about which files they are working on, what lines they are coding at, and in the meantime worrying about the tedious process of exporting the codebase as plain text, manually figuring out the changes line by line and copy-pasting them in their local machine while sharing their work files by some sort of removable disk packs or mailing system. Just then one of a developer finds out a potential bug in the codebase. Everything halts in the production till the time that bug is fixed and what if during that period the whole codebase gets lost? Neither a way to store the current version nor a way to go back to a previous one.

This whole process involving manual backups, storing multiple versions of large files locally, and whatnot was indeed dreadful and time-consuming. Luckily, the manifested annoyance of developers tackled this mind-numbing issue by creating the first version control system in the late 1900s, and ever since, there is no going back. 🙂

With the help of modern version control systems, now the group of ardent developers can simultaneously work on a single project, record changes in the codebase, and keep track of the modified code, thereby maintaining different versions of the same project. It is as simple as taking snapshots of code, saving them, and whenever there is an issue with the new changes then referring to the previous snapshot to get an earlier version of the file.

To understand the terms in a better way, let’s consider a team of four people comprising developers A, B, C, and D living in distant places from each other who have to collaborate on a web application. Developer A initializes the project and the git takes its snapshot. Followed by that, Developer B writes some lines of code, and git again stores a second snapshot of how the files look at that moment. Now, Developer C desires to make certain modifications in the codebase, so referenced the previously-stored snapshots and reverts the changes to fix them whereas Developer D joins the team late and he prefers to first go back and check the history of which developer contributed to what part of the project.

This whole source code management is done with a help of a tool known as Git, the most commonly used distributed version control system. Git is basically, software running on local machines of A, B, C, and D to store their files.

Now, the questions arise about how to upload those changes and where to store the contents. To remotely collaborate, it is necessary to host the files online, and one example of such a centrally located place that stores the copy of those files is GitHub — a collaborative platform where millions of developers shape the future of software, together. (P.S. GitHub is love ❤)

Getting started

The virtual stage containing the collection of files and saving the different versions of a project is known as the Git repository. When Developer A initialized a project that primarily meant that he/she/they took the required local folder and informed Git to consider this as a repository, in simpler terms, consider it as a folder in a computer where all project files reside. Any changes to this file will be tracked via the version control system.

• To initialize a git repository:

  cd [directory-path-of-required-folder]
  git init
  

Now, comes one of the most important topics in the version control system: the Three Stages of Git. The files in a project can reside at three different levels: modified, staging, and committed.

Developer A made certain changes to his copy of the project but did not store it in the database yet. This stage is known as modified since some additional modifications have been done to the original project.

• To check at what stage the files are in a three-tree scheme:

  git status
  

Thereafter, apply the modifications to the remote repository as well. Before the actual implementation of changes, the git has to track them and the place where it is done is known as staging. In layman’s terms, one can refer to staging as an area where files are all set to be joined to the remote repository.

• To add files to the staging area:

  git add [file-name]
  

The final stage where the changes are ultimately applied to the remote repository is committed.

• To permanently store the snapshot of the changed file:

  git commit
  

• To add a git commit message:

  git commit -m “[add-message]”
  

While recording the contributions, it is a good practice to give a human-readable explanation of the modifications.

Now, Developer A must store this copy of the repository online so that Developer B can download it and collaborate with A. Such a repository in a distant place, for example, on GitHub, is called a remote repository.

But how a remote repository is created? Dev A navigates to the upper-right corner of his/her/their GitHub account, selects the New repository option, adds a short and crisp name, sets the repository visibility, initializes it with a README, and finally creates the repository on GitHub. Yay!

Note: README files are used to communicate important information about the project. A README, along with a repository license, citation file, contribution guidelines, and a code of conduct, communicates expectations for the project and helps the maintainers to manage contributions.

• To set up a remote repository:

  git remote add [remote-name] [remote-repo-url]
  

• To push the changes to the remote repository:

  git push -u [remote-name] [branch-name]
  

Hey, hold on! What’s meant by the term branch over here? 😕

By default, there is only a branch known as the master/main. We’ll dive deeper into branches at a later stage, for now, consider branches in Git as pointers that point to the snapshots of changes.

After the remote repository has been set up, Developer A adds Developer B as a collaborator to make further contributions. Since the repository exists remotely, Dev B as well as Dev C fork 🍴 the repository to make an instance of the entire repository on their accounts and then clone it to their respective machines for working with it locally.

• To clone a repository:

  git clone [repo-url]
  

Oh, snap! Developer C finds an unrelated error in the code that must be fixed at the earliest but Developer B is still working on some files.

In such a case, Developer C creates a new branch. This spawning of a new branch will indeed serve two major purposes:

• It allows both developers to work parallelly.

• It does not affect the master branch containing the main source code.

• To create a new branch:

  git branch [new-branch-name]
  

• To move inside the specific branch for making the required changes:

  git checkout [branch-name]
  

• To create a new branch and switch to it simultaneously:

  git checkout -b [branch-name]
  

After putting in rigorous efforts, Developer C was successful in fixing the bug and now adds, commits, and pushes those changes to the new branch using the git commands.

git add .
git commit -m "[message]"
git remote
git push [remote-name] [branch-name]

Attention, Attention! Before navigating to the repository on GitHub for submitting a pull request, Dev C needs to sync it with the original one to get the latest version of the project.

• To check the current branch:

  git branch
  

• To switch to the master branch:

  git checkout master
  

Well, well, how to pull the changes from the original repository into the forked one? Yes, the remote repository needs to be added.

• To add the original repository as an upstream repository:

  git remote add upstream [remote-repo-url]
  

• To fetch the changes from the original repository:

  git fetch upstream
  

• To merge the changes from upstream/master into the local master branch:

  git merge upstream/master
  

Note: The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content. This command is actually a combination of git fetch followed by git merge.

• To pull from a remote repository:

  git pull [remote]
  

• To update the GitHub repository:

  git push origin master
  

Woah, Kudos to Dev C and you, by all means, for learning Git and GitHub so far. In view of the fact that the bug has been fixed, there is no need for that branch anymore.

• To delete an unnecessary branch:

  git branch -d [branch-name]
  

• To delete the branch’s version on GitHub:

  git push origin --delete [branch-name]
  

Meanwhile, let’s take a look at what our awesome Developers A and B are up to. Wait, what? Upon invoking one of the merge commands, Dev B finds that the merging process failed. Ah, sad life :(

Unable to figure out the problem on his own, he/she/they raise an issue on GitHub and assigns it to the tech-savvy Developer D.

GitHub Issues are discussion threads where developers can keep a track of ideas, feedback, tasks, or bugs for work on GitHub.

After referencing all the modifications done in the file previously, Dev D informs the team that a merge conflict has been created in the file models.py and further explains that since Dev A and B were working simultaneously and might have not synced the codebase, B added a new model field date = models.DateTimeField() at line 15 in the new-feature branch and A who was also working with the same file, added a new model field date = models.TextField() at line 15 in master branch.

As the changes were done in the same line on both the branches, the git was unable to handle this on its own while merging the branches and thereby, threw a merge conflict. To resolve the conflict, Developer D had to manually look into the file and keep and discard the changes according to the requirements for a successful merge. Thereafter, Dev D hosts the stunning website on GitHub pages free of charge directly from the GitHub repository.

Claim your GitHub Student Developer Pack right now and get access to more than 100 premium developer tools for free.

Here you Git Get Go! 🚀