[PR-Git-2021] How to use Git for day-to-day operation

In This Article:

Overview

---

Purpose

This procedure shows you the procedure for Git in day-to-day activities

Applicability/Scope

This standard applies to all crew that use git in their day-to-day workflow

Prerequisites

Read about Git Standards:

• [S-Git-002] Git Branching Standardization

Procedures

---

Git Concept Crash Course

Git vs GitLab vs GateGit

• Git  is the software used to keep track of project files. Git is free and can be used by anyone
• GitLab is simply a platform that use Git software. GitLab host Git on the internet so you can collaborate remotely with your team
• GateGit is a hosted service where Agate’s repositories lives. GateGit uses GitLab and is for internal use only

Why do we use Git?

• Git allow us to easily synchronize changes so you and your team can work collaboratively on the same repository

  • What is repository?

    Repository is a storage where the project files live. Easier way to understand it is that it’s like a folder in a Google Drive that stores the files you are working on. That folder can be called repository, which is hosted on Google Drive. In GateGit case, the project files is stored in a repository hosted in GateGit

• Git allow us to keep track of every changes made to every files in our project, which helps us:

  • stay organized

  • see what changes were made, when was it made

    • like if you changed an image

      

    • with a timestamped changelog

      

  • allows us to revert changes to previous version (this is why it’s called Version Control software)

Git Add and Git Commit

Let’s say you are changing something in the project file. You’ve finished with your work, and you want to save it. To do that in Git, you first have to “add” the changes into what is called a “staging area”, kind of like registering to the system “here, this is the list of files I want to save.” After you add the changes, you “commit” them to Git. The commit basically act as a save point.

Git Branch

Let’s say you and your lead is working on a project. You want to add a new button next to an existing button. You directly change the file to add the button. Turns out you made a mistake and mess up the whole layout! Before you can fix your mistake, your lead take a peek at the main project file. Oh no! Your lead is now mad at you for messing everything up in the main project file! Why did you do this?!

With Git, this can be easily avoided by branching like a tree. The concept is you make a branch of the main project file. In this new branch, you can safely add the button there without the fear of messing up. Well, maybe you still mess up the layout even this time, but it is isolated and the main file is unaffected. You can change and test the button until you get it right, and maybe show it to your lead for review.

So, how does that work, technically? The “main project file” we talked above is called the main branch or master branch. You can create (virtually infinite) new branches to do your work without directly affecting the main branch. Usually, each branch is associated with a distinct feature or issue that need to be fixed.


Example of branching

When all is well, you can commit your change, then merge it to the main branch! This way, the main branch is always the clean branch where everything works.

Git Merge

With the scenario above where you work on a new button in a new branch, let’s say you are sure that your work is done and everything is working as intended. You now want the new button in the main branch. To achieve this in Git, you do what is called Git Merge. Git Merge is essentially merging your button branch into the main one, applying all the changes you did. Now, you have the new button in the main branch!


Example of merging

Git Pull and Git Push

So far the concept we talked above are applied to local repository. But what about remote repository, where they lives in the cloud? Git Pull and Git Push is the answer. With Git Pull, you can “download” a remote repository into your device so you can work on it. With Git Push, you can “upload” what you have been working on your device into a remote repository, making your changes available for the team (which they can pull to collaborate).

Setup

Install Git

Responsibility

• Individual Crew

Pre-Requisites

1. Check your device for Git installation, because if you're using UNIX system (Linux, macOS), Git comes pre-installed. If you are using Windows, it is worth to check as well. Open a terminal (UNIX) or command prompt (Windows) and type type git --version. If you already have Git, you can skip this and goes right to setup.

2. Choose your preferred Git software. Git, at its purest form, is installed as a command line tool. If you aren't comfortable using the command line to work, there are many great User Interface tools for Git, like GitGUI and SourceTree. Popular choices are:

   • Git
   • Git for windows
   • SourceTree

   If you are unsure, you can pick SourceTree

Steps

1. Go to one of the Git software download link listed above
2. Choose and download the installer for your OS
3. Install the software

Clone Repository

After repository created, each crew need to clone the repository to their devices.

Responsibility

• Individual Crew

Steps

1. Go to the repository GateGit website

2. Click the “Clone” dropdown on the far right of the repository

   • Image

     

3. Take note of the repository address (either SSH or HTPPS)

   • Image

     

4. a

You can clone repository via via git bash  with:

## Git clone, change [repository_address] with your repository address
git clone [repository_address]

Repository address can be found in gategit project project main page.

Go to to Project  from left side bar and then select select Details. After the page loaded, find and click click Clone  button (blue button with down arrow inside it).

After button button Clone  clicked,  there will be drop down form.  Clone with SSH  is repository address with with SSH credential, while while Clone with HTTP  is repository address with gategit credential. Using SSH creadential is recommended instead of HTTP credential because there are plenty of advantages when choosing choosing SSH credential instead of HTTP credential. But that topics will not not be discused here.

For Programmer

Programmer Git flow

Create Issue

Responsibilities

• Lead Programmer: create issues for a feature or bugfix, so that the programmer can work on it
• QA Team: create issues for bugs found during/after testing
• Stakeholders (Product Manager, Tech Advisor, Producer, Lead Programmer): creates issue based on needs and importance

Flow

Glanceable flow

Steps

• Go to Project Repository

  

• Create Issue by List

  • On side menu, click Issues to go to Issues List page

    

  • Click New issue to go to New Issue page

    

  • Write down the required information, such as Title, Assignee, Milestone, Labels, and Weight. Below are description about it.

    • Title = Issue Title

    • Assignee = Drop down list of Team Member. Select team member who work on that issue. You can assign to yourself by clicking Assign to me

    • Milestone = Drop down list of Milestone. Select your current milestone

    • Labels = Label that indicate scope of issue

    • Weight = Difficulty of issue. Our standard is using fibonacci sequence.

      • 1 = Noob
      • 2 = Easy
      • 3 = Normal
      • 5 = Hard
      • 8 = Expert
      • 13 = Need more breakdown

    • Description and Due date are optional — depending on needs and detailed information about the issue

      

  • Click Submit issue to submit those details and you will be redirected to issue detail

    

  • Lead Programmer must add label Sanitized on issue

  • QA Team must add label Bugs and bugs type (trivial-bug, minor-bug, major-bug, critical-bug) on issue

  • Newly created issues appear on issue list and issue board

    

    

• Create Issue by Board

  • On issue boards, click + button on list.

    • Lead Programmer adds new issue under the Sanitized label

    • QA Team adds new issue under the Bugs label

      

  • A mini form will appear on list — type down your issue title in it

    

  • Click Submit issue to submit and it will be created on issue list and issue boards. You can add more information on appeared menu in right of screen or go to detail issue by click issue title.

    

Work on an issue

Responsibilities

• Assigned crew

Flow

Glanceable flow

Steps

1. Go to the issue detail

   

2. Click the dropdown arrow on Create merge request, then add the branch prefix (feature/ or bugfix/ etc.) on the branch name, wait a while for GitLab to check the name, and then click Create merge request.

   

3. GitLab will then create the branch for you

   

4. Checkout the merge_request to your local computer, hence you can work on it. You can use Git, GitGUI, GitKraken, SourceTree, and other Git tools.

5. As you work on a quest's merge_request, you must add Closes before issue number i.e., Closes #529 on merge_request description. This will mark the merge request, so that when it is merged by Lead Programmer, issues linked on the merge request will be closed as well.

6. As you work on a merge_request that fixes a bug, you must add Solving or Solving This before issue number like Solving #529 or Solving This #529 on the merge_request description. This will mark the merge request, so that when it is merged by Lead Programmer, issues linked on the merge request will not be closed.

Commit changes & Merge Request

When you want to commit and push changes you made on merge request, below are some rules to follow:

• Commit message must represent what you do on that commit
• Use active verbs
• All team member works are combined in the develop environment. When you must get latest develop environment, make sure commit message is Merge branch 'develop' into merge request name.

Merge the merge request

After a team member has done working on a merge request, it is finally the time to merge it. The flow is:

• Make sure all pipeline jobs are successful, except the Sonarqube job

• If there is any code conflict in the merge request, please solve it before proceeding any further

• Remove WIP from ****merge request after all discussions are resolved (if any)

• Mention Lead Programmer to review the merge request

• If you really need to update the version of develop environment by merging the merge request, you can directly follow up about that merge request. Thus, the Lead Programmer can look up on it immediately.

• When Lead Developer start a discussion by commenting code on merge request, merge request will become WIP again and team members must solve it

• The merge request will be merged only if: (1) it is not in WIP, (2) has been approved by the other two team members (Lead Programmer and Peer Programmer), and (3) all related discussions are resolved (if any).

Closing the issue

An issue on GitLab project repository will be closed with these conditions:

• The issue has Done label
• If created by Lead Programmer, it is closed after its merge reques is already merged
• If created by QA Team, it is closed after its merge request has solved the reported bug(s)
• Issue will be closed directly if it is already deprecated, outdated, direction changed, and already applied or fixed on different issue, though the related issue is not mentioned.

Below are some screenshots of closed issues

For Artist/Designer

Work on Asset