Git for Exi

In the previous session

Please keep this in your mind ...

Exi gitlab server

this is where your git projects are stored

Repository

We also called it as project or simply called it as repo

Branch

It is a stage area of your project

Protected Branch

Well, it is a branch but protected

Commit

Basically you're adding a changes into stage area

We will simply reference commit as :

  1. Adding / deleting files with git add / git rm
  2. Commiting with git commit
git commit
git add
git rm

Remote URL

Your repository's URL

Copy from :

# add remote
git remote add remote_name your_url
git remote add origin git@git.extrainteger.com:exi/open-project.git
git remote add mainrepo git@git.extrainteger.com:exi/open-project.git

# remove remote
git remote remove remote_name
git remote remove mainrepo

# update
git remote update

# fetch
git fetch remote_name

Command :

Push

Upload commit to server

git push remote_name current_branch

Command :

Pull

Download commit to server

git pull remote_name current_branch

Command :

Merge

Combine current branch with another branch

git merge another_branch_name

Command :

Rebase

Get the latest branch's update and implement it to current branch

# rebase with local branch
git rebase branch_name

# rebase with remote branch
git rebase remote_name/branch_name

Command :

Merge Request / Pull Request (PR)


Asking owner to implement your changes

Accept PR

 

Owner accepting your PR

Good practice if you work alone or in a very small team

Single workflow :

  1. Commit your changes
  2. Push to server

Team workflow :

  1. Commit your changes
  2. Pull from server to get update
  3. Fix conflict (otherwise skip)
  4. Push to server
git commit -m "update readme"
git add .
git push origin master

Good practice if you work  in a small team. All members are equal.

workflow :

  1. Create your branch from main branch
  2. Commit your changes
  3. Go to main branch
  4. Pull from server (when team updated repository)
  5. Merge with your branch
  6. Fix conflict (otherwise skip)
  7. Push
git checkout -b add-readme-page
git add .
git commit -m "update readme"
git checkout master
git merge add-readme-page
git pull origin master
git push origin master

Good practice if you work in :

  1. Organized team
  2. Single repository

A master is the one that maintain main branch (protected)
Developers commits in their branch and makes PR

workflow :

  1. Create your branch from main branch
  2. Commit your changes
  3. Go to main branch
  4. Pull from server (when team updated repository)
  5. Go to your branch
  6. Rebase with main branch
  7. Fix conflict (otherwise skip)
  8. Push
  9. PR
  10. Master accepting PR
git checkout -b add-readme-page
git add .
git commit -m "add readme page"
git checkout master
git pull origin master
git checkout add-readme-page
git rebase master
git push origin master
git checkout master
git pull origin master

Good practice if you work in :

  1. Organized team
  2. Multiple repository

Similiar with flow 3 but using main branch and forked branch

workflow :

  1. Fork main repo *
  2. Clone / fetch *
  3. Add main remote to forked repo *
  4. Commit your changes
  5. Rebase with main repo branch
  6. Fix conflict (otherwise skip)
  7. Push
  8. PR
  9. Master accepting PR

* one time only

Errors = More Codes

e = mc^{2}
e=mc2e = mc^{2}

Happy Coding !

Made with Slides.com