Git: for everyone of us

Git: for everyone of us.md

1. Git is a tool for modelling your code's history as a tree (which usually called repository).

2. There are two ways to have a git repository on your local computer. First is to create your own from scratch (or from existing folder of code). Second is to clone an existing remote online repository that you have access to.

   command(s):
   git clone {url-of-remote-repo} {name-new-folder-for-git-to-create}
git remote add upstream {url-of-master-repo-before-forked} (see point 3. below)
   or
   mkdir {your-new-project-folder-name}
cd {your-new-project-folder-name}
git init

3. There are two ways working on existing remote repository. One way is to work directly within that repo (usually by creating a new branch). Another way is to fork the repo as your own first, and then work on that forked repo. (Choose the later as much as possible.)

   command(s):
   there is no terminal command, you need to issue the command from web like Github or Bitbucket, find it by your own.

4. There are ways of creating and using branches. Basically, you use branch for grouping your work/changes from works done by your colleague(s).
   For example, you can create a new branch using your name. Or people usually create a new branch for a new feature/module that they will be working on.

   command(s):
   git checkout --branch {name-of-a-new-branch} (create and jump to a new branch)
   git branch --all (show all branches and current used branch)
   git checkout {name-of-existing-branch} (move to another branch)

5. When saving your code history, you need to tell git to create a node. This step is called committing code changes. Hence, that kind of a node is usually called a commit.

   command(s):
   git status (checking the status of current repo: is there a new file, or changes, or deleted file(s), etc)
   git add . (add all files to be tracked/indexed by git, or you can provide specific file of folder instead of dot)
   git commit --message "{your-commit-message}"

   You can commit as-often-as and as-early-as you want to, with whatever commit message that you think is important to describe your commit. Just try to make it clear, short, and concise; to help others understand.

6. To update the remote repo following your work inside your local repo, you need to push your current active branch to related remote branch.

   command(s):
   git push origin {name-of-related-branch-on-remote} (people usually use the same name between local branch and its related remote branch)

7. To merge (or combine) two branches, make sure that you have pulled your colleague(s) update (if exist) on that branch first, and then merge from the side of your branch, to resolve conflicted line of code (if exist).

   command(s):
   git checkout {branch-to-merge-back}
git pull upstream {name-of-related-branch-on-upstream-remote-repo}
git checkout {your-feature-branch-to-be-merged}
git merge {branch-that-was-pulled-before}
git push origin {name-of-related-remote-branch}

8. A better alternative to merge, is to rebase. Re-base-ing is basically telling git to move the base of your branch to the current-updated-pulled commit/node of the origin-branch that you start your branch previously. Hence, realigning your code history to make it linear.

   command(s):
   the sequence of commands is the same with point 7. merge above, but changing: git merge to git rebase

9. Create a pull request, when you think your changes (on your remote forked repo) is ready to be combined to remote upstream (parent source) repo.
   Your colleague(s) who is responsible maintaining that upstream repo will be notified. She can approve your pull request or can discuss/clarify things prior to.

   command(s):
   there is no terminal command, you need to issue the command from web like Github or Bitbucket, find it by your own.

10. You will be notified when your pull request is accepted/merged to upstream repo. And then, you need to update you forked origin repo from the updated upstream repo. (Not by merging your local branches by yourself.)

command(s):
git checkout {local-branch-to-update}
git pull upstream {updated-branch-from-upstream-repo}

Congrats! You have completed a full-circle-of-gitting-the-git!

11. One more thing, when you want to continue working on your feature branch, just rebase (not merge) that feature branch with the updated local branch.

command(s):
git checkout {your-feature-branch}
git rebase {the-just-udpated-local-branch}