Hi! Hi! All guys~

Previously I talked about Docker for afford us programmers the ready-to-eat environments. This time it’s the turn of source code as we have to write them for tens or hundreds files. Let’s see what can be happened:

  • Misunderstanding about requirements and just realize the source code has been writing so far.
  • Handling conflicts from multiple programmers in one projects.
  • Find out the easiest way to deploy on production servers
  • Share our source code as an open-source
  • and hundreds reasons

Therefore, we shall go meet Git!

This is Git

Git is a repository for our precious source code. It also affords the maintenance.

This repository is similar to an online shared drive. We can put, update, replace, restore, share, and merge source code with colleagues or even strangers (if we want!)

Its environment can be explained like this:

  • working directory
    A place of our source code in physical drives
  • staging
    It is a repository (I will call “repo” for short) for verification before submitting to the Git server.
  • local repo
    When we verify ones on staging, we can confirm them to be moved to local repo. This is happened before moving to a real Git server on cloud.
  • remote repo
    The destination of our source code

Begin with Git

1. Git server

We can find free Git server such as


A famous Git server. I guess you once heard its name. Its spotlight is a large open-source community.


Also famous. Gitlab has CI/CD as an out-of-the-box feature so we can do an automation on this. Nah, I have no chance to play around with it.


I have been using it on my workplace. BitBucket is under Atlassian and completely integrated with the sibling products e.g. Jira or Confluence.

And we have a choice to make our own Git server.

2. Git account

In case we chose one of above 3 choices, we need to register an account.

3. Install Git client

  • Windows
    download from https://git-scm.com/download/win
  • Unix
    with command yum install git-core or apt install git-core (depends on distro)
  • OSX
    Innate installed with OSX Maverick

For any installation problems, please check this out https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

4. Make a repo

Repo is like a folder of all source code. For example, I created a repo named “test_git”.

5. Register our machine’s public key to the Git server

Next we need to allow Git server to access files in our machine. Public key is a key to verify it and we are going to register our public key on Git server setting.

Generate a public key

We can follow this link to generate it:


Add our public key

Add our public key (in .pub file) to SSH key setting page of our Git account.

6. Start syncing

Use git init and .git file will be created. This file is like a registrar to manage all files between our machine and Git server.

git init

Important! Only files placed inside a folder with .git can be detected and moved to Git server.

Add a destination repo to .git file with this command.

git remote add origin [git_url]

We can find git_url in the pattern [email protected]:abc/repo.git as the example figure below (My github repo)

Once we finished command git remote add origin, our machine is ready.

We command git remote show origin to ensure everything is ok.

7. Set user’s properties

git config – global user.email "[email protected]"
git config – global user.name "my name"

It takes effects when we upload or commit files into Git and check the history.

8. Initializing files

We use this to download files from Git to the machine

git clone [git_url] [local_path]

It will copy everything from git_url into local_path which is automatically working repo.

9. Move to staging

After initialization, we are ready to copy our files from machine to the remote repo.

First, enter the working repo.

Check the status by typing:

git status

Below means we have no file to add.

This below show a fresh empty file named test.txt.

Next, we move this file to staging:

git add [path_folders_or_files]

See, we got new file: test.txt

In case we don’t want any file on staging, remove them with:

git rm -- cached [path_folders_or_files]

It already moved to untracked files.

But for some reasons, we want to remove it from both staging and the machine we use this command.

git rm -f [path_folders_or_files]

10. Move to local repo

Let me add test.txt again and that’s all for staging. We will go to local repo with this command.

git commit -m "description"

At “description”, we can put any text to describe what we do at this time. This helps us recall in the future.

11. Move to remote repo

At the time we commit, the change is in form of a branch. If we confirm to make this change over the remote repo, type this.

git push origin master

Now the current branch (origin by default) are merging with the main folder (master).

12. Check it out on Git server

That’s right! test.txt that we just commit is showing with the description.

Last but not least

All above are just a beginning. Those are a very simple ability Git can do. We can do more by using full document at https://git-scm.com/docs.

What is next, stay tuned.