Everyday GIT Using CLI

I decided on writing a tutorial on Git usage. Especially considering how popular remote work is now. When I began software development, I started with using a GUI but I made too many mistakes with it. Its really easy to screw up using that since there are too many options that you can easily click and I think I may have accidentally deleted some commits at some point. And well, using the CLI really feels quite cool. I won’t be going through setting up a repository since you can find a step by step guide anywhere. No really, there are steps on a new repository itself.

Using git with the command line is quite simple. For your everyday needs, you just need to know 4 basic commands and how to solve conflicts should they arise (which don’t come in often unless you work in a team on the same components).

I will try and explain the 4 commands that everyone should know and where certain commands have helped me with respect to the situations in which they arose.

Note: I will be using Xcode as an IDE where necessary and don’t worry, the knowledge is transferrable! This isn’t something that is language specific!

Before we get started with the commands, something you need to keep in mind is that when talking about git, we talk about 2 “copies” of the same files. One is your local copy and one is on the server. Until you explicitly tell git to send stuff to the server, it will keep all the items on your machine.

One important command (according to me) before anything else is:

git status

Sometimes you just need to know what all you need to do. What I mean by this is, if you have a new filed added, the command will tell you, you have files that need to be tracked. If you have added the file to tracking then it will tell you that there are changes that need to be committed. After committing them, it tells you that you are ahead of the remote i.e you have taken the latest code from the remote, worked on it and are yet to send it to the remote. Quite a useful command to re-orient yourself.

So the first few commands come in the following sequence for your daily tasks. I would strongly recommend following the sequence to make sure everything goes according to plan. If there are terms you don’t understand, just wait till you completely read everything.

1. git add -A/git add .

Git add -A command. It has no output inherently and is used in tandem with git status

The above command informs git that all files in the current local git repository need to be tracked for changes. Without running this, git will never know about any changes made to a file. I recommend running this command every time unless you consciously decide to not track all files. Generally, you would want changes tracked in all files and any you don’t want, would go into .gitignore file.

.gitignore: This is a hidden file that, as the name suggests, has a list of files that git should ignore. Event running git add won’t add the files if there are present in .gitignore. This is useful to not have .DS_Store files or any random auto generated files automatically added on the remote.
Note: You will have to make sure this file is present before adding files for tracking to git because once they are added then git will continue to track them even if they are present in the .gitignore and you will have to manually remove them.

2. git commit -m “Commit message”

Because of the add command, git knows that it needs to track files. And only that. It doesn’t know that you want to save the changes you made to your local copy. Running this command does exactly that. Inside of the double quotes you write a message to identify what all changes/work you have done to be able to better determine a point you might need to revert your code back to. I cannot stress the importance of writing a good commit message, spending a few extra minutes is worth it. It can serve as a daily log for your manager to see what all work you have done too!

All the commands till now were simply for your local machine. And you haven’t actually sent anything to the server.

Git commit

No changes to commit!

3. git pull <remote> <branch>

This command downloads any updates to the code pushed by someone on the server from somewhere else to your machine. You don’t necessarily have to do this but I would say just do it out of paranoia. Now you can push (more in the next point) without having to do a pull and the CLI will tell you that you need to do a pull first. But well…I am not entirely sure when this may happen but I have heard of people’s code being overwritten (maybe it is just hearsay but better safe than sorry).

Git pull for no changes on remote

Git pull when remote has changes

4. git push <remote> <branch>

Finally, this one pushes everything that you committed till now to your local machine will be pushed to the server.

Git push when there are changes

That is it. That is all you need to know for work on a daily basis! Just these 4. Typically a more senior member of the team will setup everything else and tell you where to push or take a pull from and you don’t have to worry about anything else! All you will have to do is copy the url of the repository and then run:

git clone insert_url_here

If you want want to know some more stuff like what branches, remotes, stash and other stuff is. Keep reading on.

Remote

Remote refers to the server url where your repository is hosted. The command you will typically use is git push origin master where origin is your remote url and master is the branch. Now you may wonder why these names. The term origin is a convention that typically denotes the original place where the code exists (I like to think of it this way) . What this means is you can use any other name! But you have to tell git that! You do this by running:

git remote add origin1001 insert_url_here.git

and the command becomes

git push origin1001 master

Think of origin as nothing but a variable storing the url value. So you have two places to push the code to now, origin and origin1001 and these two are completely independent of each other!

Should you want, you can reset the url stored in any variable at any point of time. You need to run:

git remote set-url origin insert_url_here.git

Now your origin will update the value store inside to the new url passed!

Branch

Now in the example above, the branch is called master by convention as it is the root, the primary and the original branch that will have other branches flowing out of. You can set any other branch to be the default branch and rename it even but I would strongly suggest not doing this. Since these are things other people working on your code will expect.

Think of master as the trunk of a tree. There can be other branches but conventionally the master branch will have the most stable and working code. And all other team members will be working on branches of master. To create a new branch, just do:

git checkout -b branch_name

To view the list of all available branches type:

git branch

On branch development. Denoted by the text in green and asterisk.

And to switch between branches you need to do:

git checkout branch_to_go_to

Work on the second branch will be completely independent from the original branch. The second branch will contain code from the point you created it out of the original and that is it. The new branch will not care about the other and vice versa.

Merging

Let us say you have done work on branch development after checking it out from the master branch. After doing some work on development you are ready to release the code. So what you can do now is go to the master branch using checkout. And once you are on master, you can do:

git merge development

This will merge all the committed code on development to your master branch along with the commit history.

Make sure you do a git push afterwards to push all your changes to the remote.

Stash

The stash is basically a place where you send all the changes you don’t want to commit. This can be useful when you accidentally have done some work on a different branch than the one you were supposed to (I have done this more times than I can count). Simply run this on the branch who’s uncommitted code you want to temporarily say bye to:

git stash

Some people think that this command deletes the modifications, what it really does is that it takes all the changes and stores them separately and these modifications can be re-applied at a later date.

To re-apply the stashed changes:

git stash apply

This will pop the most recent stash from the top of the stack and apply it to the code.

Anything else?

git log

Above command will provide you with a list of all your commits on the branch you are on. The information provided involves the commit id, author name and commit message. This is why giving a detailed commit message is quite important as this is the only way of knowing what you did when you committed the code and want to revert to it.

Just one commit message for now but typically this will be a huge list

These are the few commands that I think every software developer should know. The add, commit, pull and push commands in that particular order are key for a beginner. Once you get more accustomed to them then I would recommend moving onto the subsequent ones.

This was all for this guide, I’ll introduce some more problem specific items in the next guide because I don’t want to make this one unbearably long. I think that a majority of these problems are faced by a good number of people and I have seen people take the manual approach of deletion, adding code and copying files instead of relying on git. So stay tuned!

The next part:
https://medium.com/@mayankrikh/git-using-cli-problems-and-resolutions-333754963e0e