The most basic and essential GIT commands walkthrough
Hello Hashnode Developers! I am coming back with GIT command lines. When you are working on a project whether on your own or with a team, GIT is a must you should acquire as a developer. If you just started learning web development or software development, I hope my blog will help you to get to good grips with it.
GIT is a version control system which allows us work in more versatile and flexible ways when it comes to development. This may sound like an abstract analogy, but, personally I think GIT is a good comparison to train terminals, particularly British ones.
Personally I don't like the train terminals and platforms. They are so confusing. Do not jump to the conclusion that you are on the right train. Ask attendants before you hop on if you are a lone traveller without much experience taking trains in a foreign country. haha
When I got on a train from Liverpool to get back to London a long, long time ago (it was my second time to get on a train in the UK), I actually got on the wrong one, obviously from the wrong platform. When I realised that, I was panicking so much til I got a new ticket to London from the next stop. It was the most nerve-racking time in the middle of nowhere half way around world as a traveller. You may wonder how come she is talking about her train trip in the UK while we were meant to talk about GIT.
My point is that you may easily get lost with GIT like my train trip with a dozen platforms lined up. But, I think it is absolutely fine. Especially, if you work in a big team, when you see so many branches, it is quite overwhelming. No worries, working with GIT is even easier and quicker than getting a new train ticket to London and find the right train again.
One of the benefits of VCS is that it enables us to see what's going as a whole and even on each branch and to roll back in case of an error or if an emergency occurs. Each branch can have a completely different setup and by virtue of it, modern microservices in one repository is also possible. So, all developers keep themselves up-to-date with the whole work flow without checking multiple repositories.
Let's say you just created a project
react-app directory locally and also remotely. Once you create a local one, in the
react-app directory, create a
.gitignore file and includes
.DS_Store as default. Open the terminal and then move to the
react-app directory using unix command
Finally it's time to use actual GIT command lines.
// to create an git repository git init
Good job! you've just created a local repository.
// to add all the files(with full stop `.`) to the index git add .
Now all the files in the
react-app directory are ready to commit. Until you actually commit it, you can make multiple changes in the directory and repeat the process over and over again without any record during this stage. The full stop
. is like a short-cut key that enable us to add all the files which have been changed.
You have made a little change on a
README.md file in the directory or you have been working on multiple files and before you commit, you want to see what status you are in now.
// to see working tress status git status
You see the
modified: README.md line with the red text on the terminal.
OK, now time to add it again.
Once you add the new
README.md, let's commit the whole directory.
// to record changes to the repository git commit -m "write your commit messages"
Voila! It's a crucial part to leave a comment regarding the work you have done when you are part of a team. So, other members would be able to see what exactly you have worked on and explain others why you decided to write codes in a certain way, etc.
Now let's push the local change to the remote github repository. As we haven't set the tracked repository, we should tell git which repository we want to track.
git remote add origin <your remote git repository HTTP/SSH>
I always create a remote repository with the same name as the local one. So, I have used
git remote and then you will see that the terminal returns
origin as the name of the remote repository.
git push -u origin master
Oh my god!
We made it! the remote branch
master is now up-to-date with our local branch. These are the very basic steps of working with GIT.
Shall we move onto creating a new branch?
I think this is the most common way you would start when you take on a task. Make sure your local repository is always up-to-date with the remote one. You can easily do that with the git command line
git branch & checkout
git branch <new branch name> git checkout <new branch name>
Ok, now you've just created a new branch in order to work on a new task you're given and you also have checked out from master branch to the new testing branch. This is a very crucial part when you work with multiple people at the same time.
Oh wait! Have you forgotten to create a branch and you've been coding away on a wrong branch? No worries, I have done that many times. haha
git stash git checkout <a branch you need to work on> git stash apply
Magic just happened. All the changes you made in a wrong branch is stashed, the master branch is in the clean state and you applied the change to the right branch.
Now you have added the branch to the index, committed with a new message and finally push it to the remote repository. As the remote repository doesn't have the same branch yet,
git push --set-upstrem origin <current new branch name>
git merge or rebase
Now you've decided to merge the branch to the master
as you've done an excellent job!
// you are still in the working branch directory git merge master <the branch name you've completed> git push
The command line is equivalent to
git checkout master git merge <the branch name you've completed> git push
Wait a sec!
It's not done yet. There is another option
When you use
merge, you will still have kept all the commit history from the branch you merged into the
master. Depending on the situation, all of these unnecessary commit histories on the
master branch could be seen to be cumbersome for all the other developers who have never worked on the task. In this kind of case, it would be better to use
git checkout master git rebase <the branch name you've completed>
rebase creates a new commit point.
As irrelevant and trivial commit histories are no longer in the master history, the whole team can easily track down the commit history.
But, this is just an example I am referring to. What is best for you and your team is up to you.
There are numerous git command lines such as
cherry-pick and so on.
However, once you get used to all of these basic git command lines, you will be able to wrap your head around why you would need to use others in certain cases. If you are not 100% comfortable with git, I would recommend you use GIT GUI together.
Thank you for reading again and please like my blog if you enjoyed this!
See you next time!
Great job with the train analogy 🙌
They always say story-telling is a great way to convey a message, I guess here the analogy+story telling is the magic that makes this so easy to read 👏
One key difference between real train and git branches too is that Git let you jump off your current branch to go to another one, with no time and no risk (don’t try that with real trains! 😅)
When I think back to the days where we moved from SVN to Git, I think the most difficult but liberating key idea was to realize that Git is decentralized by design. What that means is that anything you do is local first. Even when you experiment with things, you cannot screw up the remote origin (until you explicitly ask to push). So there’s no reason to fear with experiment.
Another key idea which was liberating was that branches and tag are super lightweight, there are only references (back in SVN, a branch was a complete copy of the file, so it came with size and latency costs). The consequence is that we should embrace branches and tag: creating a tag to experiment with a feature, some refactoring, or anything, let you easily rollback to your original state.
What I mean is that once we get that Git let you do things locally without breaking the shared remote origin, and makes it easy to have parallel versions to easily create experiments, it becomes liberating, and Git becomes more than a version control tool, it becomes a workflow assistant.
I don’t know if what I write makes sense, but it really changed and empowered the workflows that are possible compared to what we had a few years ago.
Hello Sebastien, Thanks for coming by again. I am chuffed to hear that you liked my analogy. I couldn't stop laughing when you joked about not try jumping out of the train. lol
I totally agree with you about your enhancing GIT description. Thank you for your valuable opinion as always. You made my blog more worthy. haha Kudos to you, too!
Nice approach to explaining Git, reading about
git stash for the first time.
I'll have to try it out cause I always work on the wrong branch 🤦♂️