How to Git

Git is the most popular version control system used now. Being distributed in contrast with its counterpart svn make git more flexible, reliable, and convenient to use for development. Here are basic things you'll do in git.

How to Git

Git workflow and branching *note: not necessarily in step(ini ga harus berurutan)

Initialization

Initialize Git repo inside project folder.

git init

Add Remote URL

git remote add <remote_alias> <remote_URL>

‘<remote_alias>’: alias for remote url, e.g origin ‘<remote_URL’: remote url taken from git remote server. Example remote url: https://prdc-support.anabatic.com:7443/git/admin.emporia/edr-eksporaja.git

Cloning Repo

Clone repo from remote server to get everything from remote server. If you want to clone repo, no need to initialize git using git init.

git clone -b <remote_repo_URL>

‘<remote_repo_URL>’: git remote server URL example: cloning from dev branch: git clone -b dev <url_to_remote_repo>

Stage Files

Move/Add edited files into ready to commits stage. Add all edited files:

git add -A

Add certain edited files:

git add <filename>

‘’: filename

Add multiple edited files:

git add <file-name-1> <file-name-2> <file-name-3>

*note: space separated

Commit Files

Commit files edited using certain commit message.

git commit -m "commit message"

Multiple line commit message:

git commit -m "First line
Second line
Third line"

Commit History

git log -n

-n : how many commit history you want to see. n is integer. If you just want to see all of them, remove -n. Example: see 4 previous commits → git log -4

Undo Previous Commit In case you commit wrong works/files, or you just want to undo your commit:

git reset HEAD~

it will take your back to state where your previous work will be in unstaged status. Fix them, and re-commit it by git add -A and git commit -m "``message commit``"

Check Old Commits Say you want to go back to certain commits in commit history to see what happen there. For example you want to see the code base at the time you commit new feature login.

Check old commits without creating branch:

git checkout <commit_hash_code>

Use git log or commit history in remote server to see commit hash code. For example git checkout 0d1d7fc32

Check old commits by creating branch: git checkout -b <branch_name> <commit_hash_code> Say you want to check old commits and move it to certain branch.

Revert Commits If you want to undo things in git to specific commit use rever. For example you want to undo file changes in a file to certain commit in history.

git revert commit_id/hash

example: git revert efT43g → will revert/undo any changes related to certain certain files in that specific commit.

Rollback Commits

• Soft rollback If you want to rollback to specific commit but keep the files changes, use soft rollback. This method won’t alter working directory nor staged directory. Changes from previous committed works will resides in staged directory and now working changes still in working directory. Use this method to change previous commit message. Stage Directory → Changes between Original HEAD to commit rollback. Working Directory → Won’t be touched. git reset --soft <tag/branch/commit_has_code>

• Mixed rollback Same with soft rollback, but previous committed changes will be in working directory as modified. The stage directory will be matched to HEAD/commit we rollback to. Stage Directory → All staged files for the commit we rollback to. Working Directory → Changes between Original Head to commit rollback git reset --mixed <tag/branch/commit_has_code>

• Hard rollback Delete everything you worked on from current head to commit you want to rollback to. Matching everything as that commit condition. git reset --hard <tag/branch/commit_has_code>

source for rollback commit:

• https://davidzych.com/difference-between-git-reset-soft-mixed-and-hard/
• https://stackoverflow.com/questions/3528245/whats-the-difference-between-git-reset-mixed-soft-and-hard
• https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting

Tag

To label your certain commit for easy tracking, for example version number tag. Create Tag To tag recent commit on current branch: unannotated:

git tag <tag>

annotated:

git tag -a <tag> -m "tag message"

To tag recent commit on other branch: unannotated:

git tag <tag> <branch_name>

annotated:

git tag -a <tag> <branch_name> -m "tag message"

To tag previous commit: unannotated:

git tag <tag> <commit_id>

annotated:

git tag -a <tag> <commit_id> -m "tag message"

Push Tags

git push --tags pdc

List all Tags

git tag

Push to Remote Server

Push all remotely un-tracked local commits to remote master(default) branch.

git push <remotealias> <branch_tobe_pushed>

‘’: alias for remote server URL ‘<branch_tobe_pushed>’: e.g master or any branches

Push Specifically Push from specific local branch to specific remote branch

git push <remotealias> <localbranch>:<remotebranch> 

e.g: git push origin dev:dev push from local branch dev to remote branch dev

Push Force Forcefully push your local into remote server and make local identical with remote repo(timpa)

git push -f <remotealias> <localbranch>:<remotebranch>

Git Status Check on what branch you are and status of unstaged/staged and committed/uncommited files.

git status

Git Branches

Create Branch Create branch locally and check that branch immediately:

git checkout -b <branch_name>

Create branch locally without checking it out:

git branch -d <branch_name>

Checkout Branch Checkout to already created branch.

git checkout <branch_name>

List Branches List all created branches locally

git branch -v

List all branches locally and remotely

git branch -a

Rename Branch Rename current checked branch

git branch -m <newname>

Rename another branch

git branch -m <oldname> <newname>

Delete Local Branch Delete unnecessary branch

git branch -d <branchname>

Let say you don’t need that branch anymore because it has already merged into main branch.

Delete Remote Branch

git push <remote> --delete <branch_name>

Temporary Branch Let say you want to go back to certain commit id and want to work from there but maintaining the original head.

git checkout -b <temp-branch-name> <commit_id>

Merge Branch

Merge certain branch into other branch. Let say we want to merge current feature branch(f-branch) we already finished into dev branch:

• First checkout branch you want your other branch to merge into(example dev): git checkout dev

• Then do the merge git merge --no-ff <branchname_tobe_merged>

e.g: git merge f-branch example above will merge f-branch onto dev branch. f-branch is the most updated(with most progresses worked on), and merge into dev branch as main development branch.

*note: --no-ff option make the merge process keep the history of the branch that was merged. Recommended.

After merging branch, if you don’t need that branch anymore, it’s recommended to delete that already merged branch into main branch. So in above example, delete branch f-branch(while still in dev branch)

git branch -d f-branch

Git Pull

Pull updates from remote server. Pull take every updates from remote server and automatically merge them into our local works.

git pull <remotealias> <branch_tobe_pulled>

example: we want to update our local works with already updated remote dev branch from our coworker. Let say remote alias name origin. then do git pull origin dev

Git Fetch

Difference between pull and fetch is that fetch only take(download) all commits from remote server into local without merging them into our local works. The fetched commits/files will have their own branches as remote branches in our local repo so that we can preview things our coworker pushed before without merging them into our local works, fear that they will mess our local works.

Fetch All Branches

git fetch <remotealias>

Take all branches from remote server.

Fetch Specific Branch

git fetch <remotealias> <branch_tobe_fetched>

Take only specific branch from remote server.

Git Fetch Use Case If you approve those changes your coworker made, merge them into your local works.

Let say our remote server(origin) have 3 branches: master , dev , and your_friend_branch. Your coworker push their works to specific remote branch called your_friend_branch , and you want to preview them. You fetch that branch using git pull origin your_friend_branch. Your local branches will be like this:

• master (default local branch)
• dev (your main local development branch)
• feature-A (branch you created locally to work on specific feature, e.g login feature)
• origin/your_friend_branch (your coworker branch you just fetched. It’s prefixed with its remote name origin/.

Checkout to that branch like normal checkout: git checkout origin/your_friend_branch and preview your coworker works before merging. If you're done previewing, merge it by checking out to your branch first(let say you want to merge it with your main dev branch), then do git merge origin/your_friend_branch. You branch dev will be as updated as your coworker works.

Git Clone/Fetch Remote to Existing Folder/Files

Let say that your local existing directory git repo is uninitialized/not a git repo. You want to clone from remote repo to update your local directory with remote files but keeps your local files. Change Directory to your local directory and do: ****

git init
git remote add origin <remote_url>
git fetch origin dev
git checkout -b master --track origin/master 

git reset origin/master # or whatever commit you think is proper...

Git will change the way you develop program/code. With Git, every code, progresses, features, you wrote will be recorded in something called commit. Working in team will require some workflow for you to optimize the use of this version control. Here's one many ways you can use git.

Git Workflow

How to work with Git for versioning and team works.

Article recommended to read for insights:

• Successful Git Branching Model
• Git Workflow Comparison
• Git Best Practice for Small Team
• Git Cheat Sheet

Sync Up

All developers must sync their local with remote. Make sure our local working directory synced up with remote server. This is for equalize the version for each developer. So, all developers have same codebase and same git history. There are 2 main branch in remote: master and dev.

• First, clone remote repo using: git clone <remote_url>

• Change directory to that cloned folder: cd

• Continue working in dev branch by checking it out from cloned remote branch: git checkout dev

Now you’ve been set up and synced up with remote server.

Working on Dev Branch

Best practice git workflow suggest that you have to work on separate branch from your master branch. As our master branch is set up as Production Branch(branch for production release), so we will be working on dev branch. So checkout to your dev branch:

git checkout dev

Adding Features/Functionalities

Best practice git workflow suggest that everytime you want to add new feature(e.g login), or new functionalities, you have to work it on separate branch that branched off from dev branch.

Create new branch from dev everytime you want to work on new features using:

git checkout -b f-<featurename> dev

naming convention: for every feature add prefix *f-*

Merge Feature into Dev

After finishing working on feature in feature branch, add all files, commit and merge it back to dev by using:

• Add all files we edit: git add -A

• Commit them: git commit -m "commit message"

• Checkout to dev branch: git checkout dev

• Merge feature branch: git merge --no-ff f-

• After finished merging the features to dev branch. That feature branch is no longer needed, so we remove that unnecessary branch from our local branch list by: git branch -d f-

  Bug Fixing

  Same with adding new features, everytime we found issues/bugs, fix them in new branch. Using the same way as creating feature branch, we create fixes branch using:

  git checkout -b fix-<fixname(e.g UDI-33_gabisaregistrasi)> dev
  

  Add, commit and merge back the fixes into dev branch using the same way as merging feature branch.

  git add -A
  git commit -m "commit message"
  git checkout dev
  git merge --no-ff fix-<fixname>
  git branch -d fix-<fixname>
  

  Push to Dev Remote Server

  After you’ve made sure your local dev works succeed with no bugs, push to remote server dev branch. While still in dev branch:

  git push origin dev:dev
  

  we push our local dev branch to remote dev branch.

  Pull Remote Dev Branch

  After other developers finishing their works on dev and pushing it to remote dev. Update your local dev by pulling updates from them by using:

  git checkout dev
  git pull origin dev
  

  Merge Dev to Master

  After finishing some features and ready for production release, merge dev into Master branch and tag it with version iteration(e.g v1.0.2). Commit all edits in dev branch and do:

  git checkout master
  git merge --no-ff dev
  

  After merge finished, push our updated master(production release) to remote server by using:

  git push origin master:master
  

  Deploying to Server

  Deploy to Dev Server

  • Checkout dev branch: git checkout dev

  • Make sure no changes uncommitted: git status

  make sure the status is clean:

  On branch dev
  nothing to commit, working tree clean
  

  • If all is clean. Use codebase from dev branch for development server.

  Deploy to Prod Server

  • Merge all changes from dev branch. While still in dev branch: git checkout master git merge --no-ff dev

  • Tag that merge commit with version number git tag -a v0.1 -m "tag message" master

  • Push to remote master along with the tag. git push --follow-tags origin master:master

  Sync Local Master Branch

  After one developer/release manager push to master as production release. Every other developers must update their local master branch by pulling it from remote master:

  git checkout master
  git pull origin master
  

  ---

  Branch is what made Git flexible and reliable in writing code. The branches are independent which you can use to maintain your code efficiently without breaking things. Here is one of many ways you'll branch your git repo.

  Branching Model

  How to branch local workspace and remote server.

  For each individual Local Workspace

  • Main Local Branches:

    • *master* **: **created as default branch. Used as Production Branch to control production versioning and release. Each commit in master branch will mostly consist version commit with tag(e.g v1.0.2)
    • *dev* **: main branch for development process. Used as Development Branch to control development progress and product features. Each commit in dev will mostly consist features and fixes. (e.g f-userlogin(feature user login) , fix-buttonredirect(fix button redirect anomaly), etc) **

  • Additional Local Branches:

    • *f-<featurename>* **: for the sake of naming convention, we use prefix f- to denote this branch as working branch for features(e.g login, registration, oauth, bank transfer, etc). Each progress to this branch will be added to minor changes in versioning → v1.x.0. x will increment for each feature added.
    • fix-<what-to-fix> : naming convention use prefix fix- for each fixes after sprint preview by mbak putri. Each progress to this branch will be added to patches in versioning → v1.0.x. x will increment for each fix fixed.

  Remote Server(PDC)

  • Main Remote Branches:

    • *master* **: **contains all commits ready for production releases. Pushed from master in local branch.
    • *dev* **: contains all commits for development process. Pushed from dev branch in local branch.

  • Additional branches Additional branches will be created if one/more developers push their special branch to remote server to be previewed by head/senior developer before merging. Naming convention: b-<developer-name>