If you want to start your career as a web developer/software developer blindly learn and practice git beforehand you get things nasty with frameworks. Trust me it’s worth experimenting and could be your companion of all times in your development phases.
Why is it so? Let me explain how I learned it the hard way. I was once interning with a fast-paced AI startup at Chennai. After getting comfortable with the team and product I was assigned my first task to make changes with the UI of a particular retail-dashboard module. It was quite a simple task in React, an experienced professional would fairly complete it in minutes. I was taking almost a day to push my changes and get approved. Why do you think so? To be honest it just took me an hour to read the existing code, understand and make changes. But it took me a day to push my changes. The reason is my lack of understanding with git basics. You don’t want to be an expert to clone a repo, fork it, commit code and push changes. I have done those before, but the point where I struggled is dealing with a distributed environment. I have worked the way I am the only one taking care of my repo. And here I was supposed to work with a team and I struggled to pick up. I was so afraid of what if I pushed some breaking code and if it breaks the production app. You know what I was not aware of branches concept since the only branch I knew is the master, hehe :)
I was so shy to ask doubts about starting up. How would I ask someone about cloning a repo, committing changes, etc? What would they think of me? I was confused. Googling doesn’t help me out at that time since I was not stable and calm. Later I managed to calm me down, watched a few youtube videos and done with the task. It took me a day, they didn’t make any remark on that. But I was so much disappointed. I felt inferior. I like to share the lessons learned from this experience.
If someone is stressing you to follow the same structure, again and again, please don’t ignore it. If something is worth following don’t hesitate to spend time on it. For eg: Even if you are working with your hobby project, push the code to a repository, work distributed with your project mates and experiment how the industry works.Because these are skills that come by practice and no use in memorizing.
Always stick yourself firm with the basics. Refresh them again and again. Apply those skills as much as possible. Stress on the basics before getting your hands dirty with frameworks.
A company may adopt any tech stack, will have its own coding principles, design system, etc. But the foundation will remain the same. At the end of the day, the goal is to stay productive. So, learn how to use Git like productive tools so that you stand out in a crowd.
Now let’s get our hands dirty with some git basics which you will encounter again and again in your projects. I don’t want this to be a regular tutorial listing git commands, which is very easy to find on the web. Instead, let’s experiment with some common issues and confusion we would encounter while getting started with git. Let’s get the git done!
Say, your company wants to develop software to manage meeting rooms in the office. You received the requirement documents, design modules, and other helpful resources. How will you get started? The first question that should come to your mind is
“Are you the only one who is going to work in this project?”.
The answer is no. Thus you would need a distributed version control system like Git to keep track of code changes and feature updates. The next step is to initialize an empty repository to start working on it. It can be done provided git is available on your machine with the following command.
git init
Terminal pops something which is not expected.
'git' is not recognized as an internal or external command,
operable program or batch file.
We would go crazy with wrinkling thoughts in our minds. But we shouldn’t react that way. Calm down and just read the statement once. Errors are not that bad, they can help you actually. They are good friends. You haven’t properly installed git in your system. It’s not recognizing it. So go back and read the documentation, refer some stack overflow solutions and come back. You will find it funny.
Now let’s say you are finding that the project is not up to the deadline and you want someone to help you with the backend tasks. So you are inviting your colleague to help you with the backend part. How can you both work distributed and stay productive? Both should contribute independently and should be aware of all the changes. The key here is working on the same repository. The guy was confused with one thing at this point whether he should fork it or clone it? What is the exact difference between those?
Let’s learn how to approach this rather than discussing the actual solution. One thing you can do is just google it and find answers from some forums like quora which would provide you relatable clear explanations. Like this one below,
https://www.quora.com/What-is-the-difference-between-Git-Clone-and-Fork
Also, know how to branch out and work on a new branch to make changes independently. Also, know how to make proper PR(pull request) after that. Let me leave you some reference. Just google it, dude!
https://thenewstack.io/dont-mess-with-the-master-working-with-branches-in-git-and-github/
Now let’s say the project is going well and teams were comfortable working with the distributed repo. As we make changes then and then we can review those using,
git status
which would list all the tracked as well as untracked file status. In order to view those changes in detail use,
git diff
But git diff will not list the changes if the files are already staged. In that case, this command could be handy to use,
git diff --staged
As the repo grows with many changes and commits he like to review all his earlier commits and its changes. This can be done with,
git log
Guess what the terminal is poured with a rain of commit details similar to the one below.
What is he want’s to see only the latest two commit? Here we go,
git log -n2
This will do the job for us. What if the other person wishes to see the changes done with the latest commit. He can use the long commit SHA value(the 40 character hexadecimal entity found in the above screenshot). Copy it and run,
git show "83a65ef387154658d14839fa97dd3a0d756f796a"
Git is much more capable than it can detect with the minimal optimal information you provide with. The result is the same even if you try this way,
git show "83a65ef38"
Before you commit code, you should add them to the staging area. But let’s say the app which you are working on goes for content review and you are receiving multiple content/typo changes one after another. It could be hefty to add files and commit again and again when you are sure that the changes are not going to affect the core logic by any means. So we can skip that step in most parts of this cycle. The trick is to use,
git commit -am "minor typo change to the title for SEO purpose"
It would be unfair if we couldn’t remember the most fundamental git commands. Yet, at times we may make some mistakes. At that point we should know how to get hints handy, one could easily get those via,
git help
which would make our life much easier without switching our window or navigating to the browser.
When the contents of the terminal are too long you will notice a : below, which you could scroll down to view more. Some would struggle without knowing how and guess what it’s hard to search on the web with the right keywords too. This can be done by hitting the space bar to race forward. You have similar controls to move up and down. The point is to get comfortable with these minor basics, possibly only via practice.
You would definitely encounter a situation struggling to quit the terminal, unknowingly locked with some command execution. Use **ctrl+q **to exit the terminal.
Now the backend guy feels that the header part could have some more width and bright font color would make much more sense. So he makes some changes and runs it. Unexpectedly the UI crashes and responsiveness gets affected. So he wishes to revert back those changes. How can he do so? He can undo things in the editor (2 steps). But what if he made many other changes and undo all. Do you think he would remember all those or is it efficient to undo them one by one when you knew all those are not needed. Here is where git could help you with, say it is the index.html file
git reset -- index.html
Now let’s discuss one classic usability issue you would encounter while working on large enterprise projects. Often your colleagues would pull your changes before they start working with their fresh part. What if they need only a part of your changes and not all. Say, only a few of your changes are compatible or ready to be integrated with the backend. That if you made a bunch of changes in a single commit it would be too hard for him to separate those changes after the pull. So let’s look at an example,
Say you are making few typo changes at the index.html file, then making some product pricing changes in the pricing page. Following it you changed the header part of the app and committed all those changes in a single commit. Now you are supposed to release a build and still, you are not done with the header changes fully. Your colleague feels that it's not that crucial and it’s ok to release the new app version with existing header itself but he needs the rest of the typo changes and pricing details changes there. Imagine how he could overcome this problem effectively. It looks messy right?
The solution here is always we should make atomic commits. That is all the typo changes should go in a commit, followed by pricing changes in a separate one, followed by the other one so that he can pull only what is needed.
Now let’s say he wanted to make more typo changes in the same index.html file(say the previous commit is the same kind of typo changes). It would make more sense to amend those changes with the previous commit. How can we act at this point? The solution is,
git commit --amend -m "typo changes as per marketing requirements"
Have you noticed these kinds of files in your project directory before?
These log files are generated on memory crash or some done internally by the OS-specific to them. Mac generates such files often. They are no way project-function-specific and thus can be ignored. If you commit changes with these junk files it could look messy. So you can ignore these by including the file name or generally including all files ending with .log extension using a regular expression,
# .gitignore
#ignoring log files generated by the system
log/*.log.[0-9]
which ignores all files inside the logs directory as well as any files with **.log **extension if any.
Last but not least I wish to share something related to vim editor which you would be prompted to use at times. If you try to make a git commit without any commit message you would land up in a terminal window similar to the one below.
Dealing with this would be hard initially since no common keys we use will work until we use exact shortcuts to proceed with that. In such a case type the commit message and use :wq end then enter to commit.
This is just to ensure you start working with git comfortable initially. These are some basic confusions you would encounter when you experiment git. There is a lot more to explore which you could do it yourself. Start today, learn to stay productive with your team. Happy coding!
Regards,
Mariappan S
Email: mariappangameo@gmail.com
Top comments (0)