Git is the most general used code version track tool that probably every developer uses it, and no matter you use Github, Gitlab, or Bitbucket, as long as you want to share your code or learn from others’ code, or co-work with others on one project, git is a must-have ability.
There are loads of git usage tutorial, command introducing articles and documentations out there. But frankly speaking, when I look into most official docs, I got filled up with too many commands and too detailed introduction that made me hard to find what I truly needed. So, in this article, I am going to only introduce the command line tool that you definitely will need when working with git.
I will break down into 2 workflows:
- Working with an existing repository
- Creating your own repository

Working with an existing repository
This is most common when you work in a company, where in most scenarios, you need to take over a project from others, or just collaborate with other developers on a mega project. The general workflow would be:
Find yourself a workplace folder
cd {YOUR_FOLDER}
Clone the project(either using SSH or HTTPS)
git clone {PROJECT_PATH}
Now the project has downloaded into your local computer and you are right at the master branch. The next step is to create your own branch and work on that branch to develop your features. NEVER directly make changes on master branch if you are not the owner of the project or you co-work with many other developers. The rule of thumb is that we always make the master clean and tidy to the ready-to-production version.
git checkout -b {YOUR_BRANCH_NAME}
If you already have a branch and need to shift to that, you just need
git checkout {YOUR_EXISTING_BRANCH}
Alright, now you are on your branch, and you made some changes. Everything looks good, you think you are ready to update your changes to master. Then you need to commit your change to local first:
# check what files you've changed
git status
# add those files to staging
git add .
# commit your files
git commit -m "what I have done"
These three commands are probably the most frequently used commands of git. Besides git add .
, which adds all you changed files, you can do
git add {LIST OF SPECIFIC FILES}
and commit them separately.
TIPS
After you run git status
, you find some system files that you don’t intend to add them into your commit, like .idea, __cache__
, etc. Then you need to edit your .gitignore
file(or just add it if it does not exist in the root folder).
.gitignore
as its name indicates is to tell git to deliberately ignore some unnecessary files so that git would track the changes of these files. For example you can add
.idea
*/**/.idea
into your .gitignore
.
Another thing you can do is to use git rm
, which removes the file from git and stop to tracking it, not from your computer!
So now that you have your file committed, and you’re confident about them, so let’s push to the remote and merge to master.
git push origin {YOUR_BRANCH_NAME}
In most cases, you can not do git push origin master
, as your auth is restricted. But even if you can, you shouldn’t do it. The rule here would be if you work on a branch, always push to the remote branch. The above command push your local branch to remote branch(if the remote branch does not exist, git will help you create one).
When you do the above command, generally it would return an url in console which leads you to submit a merge request. Note that this merge request is to merge your remote branch to remote master. You can submit your merge request and let the repo owner to approve to merge to master(possibly need to solve conflicts alone the way).
TIPS
Suppose the remote master is very active and a lot of other developers are working on it. Before you submit your merge request, you hope to incorporate the new changes in remote master branch and possibly solve the conflicts on your local. Then you can do this:
# go to your local master
git checkout master
# merge your local master with remote master
git pull origin master
# go to your branch
git checkout {YOUR_BRANCH}
# merge master into your branch
git rebase master
The last step you can also do git merge master
. They tied up the history of git commit differently. You can check the difference here.
These are basically all about working together with others, with the most commonly used commands, and problems you might encounter.
Creating your own repository
Think about the scenario when you’re working on your own project on your laptop, and suddenly it flashes in your mind – What an awesome project this is! I got to share with others!
Cool, let’s create our own repo and put our code online. It spilts into 2 steps:
Create a Remote Repo
Go to your Github, GitLab, or Bitbucket, and select create a new repository. Here I took the example of Github:

Give your project a name and some description and hit the Create repository
button.
Copy the url(either SSH or HTTPS) from the clone button to your clipboard, and we are going to use this later.
Now go back to your awesome project folder root
cd {YOUR_PROJECT_ROOT}
Init your project with git
git init
This fires up git in your folder, and if you run ls -a
, you are going to see the hidden file .git
in your root folder which is telling you that from now on, git is tracking every change inside this folder.
Next up is to connect your local file to your remote repo, if you run
git remote -v
This would list the remote url of your current project, and so far it should be empty, as you created a remote repo, you’ve also told git to track your file, but you’ve not yet told git how to connect your local repo to the remote. To do so, run:
git remote add origin {URL_OF_YOUR_REPO}
This connects your local project with the remote repo you just created and gives it a nickname origin
(you can call whatever name you like, but people normally name it origin).
TIPS
One local repo can actually connect to multiple remote repo of different urls. You can just do:
git remote add upstream1 {SECOND_URL}
git remote add upstream2 {THIRD_URL}
...
This way when you make changes in local, you can simultaneously update multiple remote repos.
Now run git remote -v
again, you would see your url listed there. Let’s push out change and share our code!
The steps would be the same when adding your code and committing them:
# check what files you've changed
git status
# add those files to staging
git add .
# commit your files
git commit -m "what I have done"
To push your changes to the remote, there are 2 scenarios.
- If the remote has some files not contained in your local, say, a
README.md
that initialised with creation of repo, you need to:
git pull origin master --allow-unrelated-histories
# resolve conflicts and then push to remote
git push origin master
the allow-unrelated-histories
is to merge branches when they started their lives independently, here like your local folder and your remote repo.
- If your remote is clean then just do
git push origin master
.
TIPS
You don’t need to type the repo name every time. Run
git push --set-upstream origin master
This explicitly tell that origin
is going to be the default branch to push to, so that next time you only need to run git push
.
TIPS
When you have multiple branches locally, and you need to jump between branches, you might encounter the problem that git tells you to commit before switch branch, however, you are not certain with the current changes and you do not want to commit, in this scenario, you can do:
git stash
this saves your changes, and enables you to jump to another branch without commit them. When you come back to this branch, you can run:
git stash pop
which restores the changes you just made.