Get Good with Git
To make things easier, I want to introduce you to my childhood friend, Jacob. As you may already expect, he is a software engineer in my town. Jacob has this particular fear of messing up someone’s life. It’s easy for him to ignore himself, to not do something best for his life. But, when it comes to someone else, he just feels the urge to not disappoint them and not messing up their life. That’s why when Jacob found out about git, about how they work, he wishes he had git for real life.
But what is a git? And why Jacob wants to have git for real life? What does that even mean?
To answer all your question let’s just imagine that Jacob and 5 other people working on the same project. Jacob is responsible for the transaction. One of his coworkers is responsible for payment. Payment and transaction are two things that can’t be separated. This is where the problem arises. If they want to integrate their works, what can be done?
“Oh, it’s easy! Let just do our own part and after that, I will give you all the file that I’ve been working on”
Okay. That makes sense. But what if Jacob wants to change his works after he gives his file to his coworker.
“Well, I will just give him the file again.”
Fine. It will work. But what if Jacob other’s coworker want to integrate with his work, but not with the one who works on payment? What if Jacob payment’s coworker wants to change his work after Jacob has already given his works to his other coworker?
See? Even my sentence was complicated. You can’t expect to give your own works manually to each other. It is just so complicated. That’s where git comes in rescue.
What is Git
Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files.
Version control is a tool that helps you control every change you make. To put it simply, it is a way to help you collaborate with other people, especially your team so they could see what changes you make in your works. A popular version control, such as Git, also provides more helpful features that will help you work fluently in teams.
In my faculty project, we are using GitLab which provide Git-repository manager. Why do we need version control? From my own perspective, I believe that git really helps our works. Everybody in my team is able to work freely on their works without worry. If there is a conflict on our project, let just say me and my friend both change the same file at the same time, it could be easily fixed using git.
How to Use Git
There exist the holy 5 commands of git.
git clone
git status
git add
git commit -m “ “
git push
That’s it! Those are the only things you need to know when you are new! If you have a handle of those, you’re good to go. You can start working on your projects immediately!
Actually, there is only one command of git you need to remember to help you use a git. That command is :
It is seriously useful if you’re just starting out!
Now let’s take a look at an actual git command you must use first before anything else, ‘git init’. Just go to your terminal and in your project directory run the command
If you want to initialize your project with all of the files in your project directory, run
to include everything. Now you have a new hidden directory called .git in your project directory. This is where Git stores what it needs so that it can track your project. Now you can add files to the staging area one by one with
to add a particular file you want. Or if you are like me who like simple things,
will add every change you made in your current project directory where .git is resided. To add all of your files to the staging area. You can commit these changes with the command
Notice that all your added files are committed with a single commit command. If you make any changes again after commit, you need to add and commit those files again with another message. Those two commits are different. If you are happy with your current commit, do type
to push your changes through to GitLab.
Learning to collaborate using git-flow
Let’s say you have a project going and you maybe have a lot of different features. Some features might be ready to go, but some might not. This is where branching shines!
A branch is a separate ‘space’ where you can try out any change. If you change something on a branch, it doesn’t affect the master branch until you want it to. This means that you can do whatever you want to do on that branch until you decide it’s time to merge it.
The only branch that’s going to permanently change things is the master branch. If you don’t want your changes to deploy immediately, then make your changes on a separate branch and merge them into the master branch when you’re ready.
It’s pretty simple to create a branch named “my_branch” in your terminal and switch to it with
Once you create a branch, you can make changes on that branch. After you make a change, you may add, commit and push with a descriptive commit message so other people may know what your branch is about.
If you notice the “-b” after the checkout, it means it will create a new branch. If you want to move between branches, you may use
Oh! don't forget to commit your change before moving between branch. Because you can’t simply move between branch if you don’t commit or stash any change you already made. Stash? What is that?
Use
when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to the first state without any of your change. After you stash some change, you can move to any other branch again and if you decided to return your change, you can return again to your branch and type
to return all your change. When you’re done with a branch, you can merge all of your changes back so that they’re visible to everyone.
will take all of the changes you made to the “my_branch” branch and add them to the master. What if you want to add all the changes in your branch starting from the last commit of the master branch?
will come in handy. Rebasing and merging are both designed to integrate changes from one branch into another branch but in different ways. This illustration will help you to understand both of that.
In order to create an upstream branch so that you can push your changes and set the remote branch as upstream, you will push your feature by running
Oh no! Your friend has already made their own branch and merge it to master. To make thing worse, she changes the very same files you change on your branch. Now that is called git conflict.
To solve that, the first thing you need to do is to pull from master from your branch. This will have the updated contents of the master branch on your own branch. Now let’s put the following command to your terminal
Notice you may get a conflicting message when pulling from another branch. You can check what files that cause the conflict using
It will also give you a lot of information such as what file is changed, what files is already committed, and etc. Now, to solve the conflict, we can manually search for The line (or lines) between the lines <<<<<<< and >>>>>>>. You may notice that there also exist ====== between those two markers. The lines before ====== are the change you made and the line after that is the change made on the branch you just pulled.
Now solved it. You decide on what changes should be made to the master branch. It could be yours or theirs, or even you can make another solution. After you solve the conflict, you just need to commit and push it again. Now you can safely merge your branch to the master branch.
Oh no! Your change actually breaks something on the master branch. You don’t need to worry, my child.
If you wish to undo/revert the last commit you can do the following, using the commit hash that you get from the git log command:
This command will create a new commit with the “Revert” word at the beginning of the message. After this, if you check your repository status, you’ll notice that you have the HEAD detached at the commit you tested before.
khalis:/example/example-project# git status
HEAD detached at 69ad35e
(...)You don’t want to see this message, so to fix this and attach back the HEAD to your working repository, you should checkout the branch you are working on:
Now you’re done. That’s the basic of git!
What? basic? With all those commands? Just how complicated is git? Well to answer that, I found this interesting quote on the internet:
“git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space” ~Isaac Wolkerstorfer(@agnoster)
Yep. It’s sarcasm and that the reason why you must explore git by yourself. To learn git, you must use it and in life, you will never stop learning .
To help you learn about git. I found this cool Github project. You’re going to create a simple welcome wall with notes from everyone who wants to try out Git and GitHub and contribute to their first open-source project.
You can add whatever you want to the welcome wall, as long as it’s appropriate. Add a note, add an image, whatever. Make our little world better in whatever way makes you happy. Clone the repository, either on the GitHub website or by running
git clone https://github.com/bonn0062/github_welcome_wall.gitAnd now you may create your own branch and create a merge request to master branch. I won’t tell you how because you must explore it by yourself. Don’t be surprised if you see Jacob branch on it. Because after all, I am the one who introduced git to Jacob and he is really fond of it.
Jacob is actually a messed up guys. He messed so much. At least back then in his highschool life. That’s why he hopes to have git for real life. He wants to revert to high school and make some changes there. But little that he knows, his past is what shaped him into this great man he is right now.
Good luck and get good with git!!
