Working with GitHub and Git

So someone told you to use version control or Git, something which has become a dictionary word just like you say ‘Google it!’. Yes, Git is a tool that enables us to track changes that we make to our code. I won’t go over its pros/cons, and I am assuming you’ve done your homework on this. You can head over to Wiki to learn about it. This article will be about using git via the command line and how to work with GitHub repositories.

I’ll divide this article into two parts:

1. Beginner
2. Advanced

Depending on your preference, head over to the desired section.

Beginner

Before we can move to the advanced stuff, you must know the basic terms and their meaning. Let’s talk about them:

1. Repository — It is a place where the history of your work is stored. It is usually inside .git directory. It is generated whenever you run git init command inside a directory. I'll also call this "repo" now onwards.
2. Fork — To fork a project means to clone or copy another repository so that you can make your changes without affecting the original repository. You’ll see this on GitHub!
3. Clone — It creates a copy of the repository. One can run the command git clone <repository_address> to clone a repository. You’ll often use this to make a local copy of your forked repository from GitHub.
4. Branch — It is a version of the repository that diverges from the main working project. A branch can be a new version of a repository, experimental changes, or simple patches. The usual practice is to branch and then make changes to the code.
5. Master — It is often the main branch of any repository.
6. Commit — It is the action of making changes to the current branch. You should commit your changes after they are final. I’ll talk about commits more in this article.
7. HEAD — This is a pointer to the latest commit in your working branch. When you make a new commit, this HEAD will move to the latest commit.
8. Pull — Updates the local branch with the commits made to the remote branch. You are literally “pulling” the changes into the local branch.
   Note: Remote is a branch, not your computer, and local is the branch that is present on your computer.
9. Push — Updates a remote branch with the commits made to the current branch. You are literally “pushing” your changes onto the remote.

Enough with the boring words/terminologies. Let’s do a walkthrough of the actual thing! I’ll do this walkthrough on the gymkhana repository.

Fork it

The first step is to fork the repository from devlup-labs to my own GitHub account. I can do this by the simple press of a fork button on the top right of the project page, and it is forked.

Source Repo > Select Location > Forked Repo

Clone your forked repo

The next step is to clone your forked repo onto your local computer. Run the following command to clone.

git clone https://github.com/ajatprabha/gymkhana_portal.git

Branch and start making changes

Now create a new branch and head over to your favorite editor and start making changes to the project.

cd gymkhana_portal
git checkout -b new_branch

-b creates a new branch and checkout switches to your new branch, so if you already have a branch (like master), you just run git checkout master while on a branch other than master.

Try checking the status of your repo now. Note: You can do this at any point in time; it provides current information about the repo.

git status

Add files and commit changes

Once you’re done with making the changes, add the files which you want by their path, or you can add all files in the current directory by the following command.

git add .

And then finally commit the changes and provide a meaningful commit message too.

git commit -m "commit message"

Push your local changes to the remote branch

Finally, you’ve to push these changes to the remote branch. You can do this by the following command.

git push origin new_branch

Terminal Output > Editing README.md in nano > GitHub project page after push

Now you should be able to see the button on the GitHub project page. Click on it to create a pull request.

Create the pull request

Follow the instructions shown via GitHub to create the pull request. The usual steps are giving a title, adding a description(follow the PR template if present) and click Create pull request

PR Details > Created PR > See Changes

You can see your created PR and the details associated with it. Sometimes, a CI build may run, which checks your pull request for errors. It is up to the remote repo owner whether he/she accepts/rejects the PR or asks for further modification. See, this was simple, right?

Now, what if someone asks for changes? You do your changes and then push them to origin new_branch, they'll get reflected in your PR.

This was not that difficult. Let’s talk about little-advanced stuff.

Advanced

Well, Git is pretty good at tracking files, but the real world is not that awesome. You’ve to face difficulties! What happens when more than one person makes changes to the same file? Let’s talk about such issues. A few terminologies:

1. Merge — It merges the code from one branch into the other. You can consider this as merging two branches into one.
2. Rebase — It is essentially re-writing the branch. When rebasing a single commit or multiple commits, you can edit the commit, drop it, squash it if unwanted, or effectively combine two branches that have diverged from one another.
3. Fetch — This is used to download and copy a branch’s files to your computer from remote repo. Multiple branches can also be fetched at once.
4. Remote — A copy of the original branch. You can add multiple remote branches. Example: origin and upstream
5. Stash — It un-stages your changes from git history but doesn’t drop them. You can stash your changes, do a rebase of your branch, and then apply your stashed changes again.
6. Upstream — This is the remote branch where you finally push your changes. It is mostly used to fetch the latest code. In our case devlup-labs is upstream.

I’ll show you now how to incorporate the changes in upstream to your local branch and then push those changes to origin.

State of origin

If you look at the origin(your forked repo), and there are commits in the original repo, then GitHub will show a message that your branch is # commits behind the devlup-labs:master.

Add remote upstream

To merge/rebase changes from devlup-labs:master we need to add it as a remote branch. I’ll name it upstream. The following command does exactly that.

git remote add upstream https://github.com/devlup-labs/gymkhana_portal.git
git remote -v

Here, you can use any other name instead of upstream; it’s just a convention. You can see all the remotes with -v flag.

Fetch changes, rebase and push the updated branch

The next step is to fetch the changes from upstream(i.e. original repo) and then rebase our origin branch on top of upstream.

git fetch upstream
git checkout master
git rebase upstream/master
git push -f origin master

Run the following commands, and if no conflicts occur then everything will succeed. Note: use -f flag while pushing else the push will fail.

If you had uncommitted changes, then the rebase will fail! In that case, run these commands before and after the rebase.

git stash
git rebase upstream/master
git stash apply

And you should be golden if there are no conflicts with upstream/master.

Conflicts!

If there are conflicts, then rebase will pause and ask you to resolve the conflicts; it’ll also specify the files. You resolve conflicts by editing the file having conflicts and manually selecting which code to keep. After that, add the file to the staging area and repeat if more conflicting files are present. Finally, continue the rebase.

You can keep any one of them or both the changes. You’ll have to remove <<<<<<< HEAD, ======= and >>>>>>> 58326...cc5, these lines are added while rebasing.

git add conflicted_file_1.ext
git add conflicted_file_2.ext
git rebase --continue

And this much knowledge should get you started working with GitHub and Git for now. Of course, there is more to the version control system. You might want to have a look at svn(Apache Subversion); also, it’s less popular. But let’s just leave that for some other day.

Read more:

1. A visual guide here.
2. Pro-git e-book here.

Leave your doubts/questions/thoughts in the comments section below.

Originally published at https://students.iitj.ac.in/blog/ on May 16, 2018.