GitLab Basics

Common Terminologies

 master - the repository’s main branch. Depending on the work flow it is the one people work on or the one
where the integration happens
 clone - copies an existing git repository, normally from some remote location to your local environment.
 commit - submitting files to the repository (the local one); in other VCS it is often referred to as “checkin”
 fetch or pull - is like “update” or “get latest” in other VCS. The difference between fetch and pull is that pull
combines both, fetching the latest code from a remote repo as well as performs the merging.
 push - is used to submit the code to a remote repository
 remote - these are “remote” locations of your repository, normally on some central server.
 SHA - every commit or node in the Git tree is identified by a unique SHA key. You can use them in various
commands in order to manipulate a specific node.
 head - is a reference to the node to which our working space of the repository currently points.
 branch - is just like in other VCS with the difference that a branch in Git is actually nothing more special
than a particular label on a given node. It is not a physical copy of the files as in other popular VCS.
 upstream: After cloning a repository you often call that "original" repository "upstream". In git it's aliased
to origin
 a head: The top commit of a branch (commit the label points to)
 HEAD: A symbolic name to describe the currently checked out commit. Often the topmost commit
 version: Might be the same as a commit. Could also mean a released version of your project.
 tag: A descriptive name given to one of your commits (or trees, or blobs). Can also contain a message (eg.
changelog). Tags can be cryptographically signed with GPG.
 archive: An simple archive (.tar, .zip), nothing special wrt git.
 patch: A commit exported to text format. Can be sent by email and applied by other users. Contains the
original auther, commit message and file differences
 stash: Git allows you to "stash away" changes. This gives you a clean working tree without any changes.
Later they can be "popped" to be brought back. This can be a life saver if you need to temporarily work on
an unrelated change (e.g. time critical bug fix)
 merge: Merge means two branches are committed separately and merged together with single commit.
Let say if Branch B has 100 commits and A is master then (A merge B) will result in modified B with single
merge commit.
 rebase: Rebase end result is same like merge but it takes all commits from Branch B and apply them one by
one on A master branch and maintains clean history. Dangerous to use on public branch like master. Can
use on private branches if any.
 cherry-pick: Used for hotfixes where you add only that commit containing critical fix to master branch so
that everyone making new feature branch will have latest code.
 Development Process

Feature Branch
Feature-driven development (FDD) is an iterative and incremental software development process. It is one
of a number of lightweight or agile methods for developing software. The basic idea of a feature branch is
that when you start work on a feature (Let say Menu Control) you take a branch (Make new branch) of
the repository to work on that feature. This branch will be generated from master branch and feature will
be developed on this new branch.

Staging Branch
There will be one staging branch and all feature branches will be pushed to that staging branch. When
staging branch is stable, Developer will generate merge request for master branch.

Master Branch
Master branch will contain most stable code and it’s ready for pre-production branch and then to
production branch.

Pre-Production Branch
This branch will contain pre-production versions not every master version is in pre-production. Final
testing will be done on this branch.

Production Branch
This branch will be linked with Continuous integration process of GitLab and this version will be deployed
to production server.
 Tasks Management

Milestones
Milestones allow you to organize issues and merge requests into a cohesive group, optionally setting a
due date. A common use is keeping track of an upcoming software version. Milestones are created per-
project. You can create a milestone for several projects in the same group simultaneously. On the group's
milestones page, you will be able to see the status of that milestone across all of the selected projects.

Issues
Issues help you summarize your ideas and align the team on a common goal. This can be a bug, new task
etc. All new assigned works will be managed by an issue. Due dates can be used in issues to keep track of
deadlines and make sure features are shipped on time.

Label
Labels make it easy to categorize issues based on descriptive titles. They help teams quickly understand
the context of an issue. Labels can be used to describe the issue type, like "new feature," or describe the
issue stage, like "QA."

Merge/Pull Request
If you work on a feature branch for more than a few hours it is good to share the intermediate result with
the rest of the team. This can be done by creating a merge request without assigning it to anyone, instead
you mention people in the description or a comment (/cc @ali @inaam). This means it is not ready to be
merged but feedback is welcome. Your team members can comment on the merge request in general or
on specific lines with line comments. The merge requests serves as a code review tool and no separate
tools such as Gerrit and reviewboard should be needed. If the review reveals shortcomings anyone can
commit and push a fix. Commonly the person to do this is the creator of the merge/pull request. The diff
in the merge/pull requests automatically updates when new commits are pushed on the branch.
 GitLab WorkFlow for Team KBK

1. Create New Milestone if not exists with start and end date (Probably Admin will do it).

2. Create New Issue and assign Label as category (Create New Label if not exist) add timelines.

3. Create New Branch from that issue (Branch should be made on master).

4. Work in that branch and commit and push changes to your issue branch.

5. After complete fix/task generate merge request for staging branch.

6. Do add “/cc @users” in comments while generating merge request.

7. Resolve merge conflicts by negotiating with team members.

8. Accept merge conflict and complete merge request.

9. Now again for new work back to step 1 or 2.