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 which 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:
Depending on your preference head over to the desired section.
Before we can move to the advanced stuff, you must know the basic terms and their meaning. You can skip if you’re lazy like me. Let’s talk about them:
- Repository – It is a place where the history of your work is stored. It is usually inside
.gitdirectory. It is generated whenever you run git init command inside a directory. I’ll also call this “repo” now onwards.
- 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!
- Clone – It actually creates a copy of the repository. One can run the command git clone <repository_address> in order to clone a repository. You’ll often use this to make a local copy of your forked repository from GitHub.
- 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.
- Master – It is often the main branch of any repository.
- 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.
- 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 new commit.
- 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 which is present on your computer.
- 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 gymkhana repository.
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.
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.
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 change to the remote branch. You can do this by the following command.
git push origin new_branch
Now you should be able to see the
Compare & pull request button on 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
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.
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:
- Merge – It merges the code from one branch into the other. You can consider this as merging two branches into one.
- 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.
- 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.
- Remote – A copy of the original branch. You can add multiple remote branches. Example:
- 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.
- Upstream – This is the remote branch where you finally push your changes. It is mostly used to fetch the latest code. In our case
I’ll show you now how to incorporate the changes in
upstream to your local branch and then push those changes to
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
In order 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
Fetch changes, rebase and push the updated branch
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.
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 any one of them or both the changes. You’ll have to remove
>>>>>>> 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 version control system. You might want to have a look at svn(Apache Subversion) also, it’s less popular though. But let’s just leave that for some other day.
Leave your doubts/questions/thoughts in comments section below.