A Hands-On Guide to Git and GitLab For Beginners

GitLab Overview

GitLab is an all-in-one DevSecOps platform designed to streamline the entire software development lifecycle. It covers everything from Source Code Management to Continuous Integration, Integrated Security, and more, making it a comprehensive solution for development needs.

Traditionally, as software development processes evolve, organizations tend to adopt different tools for various stages of the lifecycle. This often results in a patchwork of incompatible tools and manual processes, leading to issues such as redundant tools, data silos, lack of alignment among teams, and inconsistent security and compliance practices.

GitLab addresses these challenges by offering a unified platform. It replaces the need for multiple tools with a single application that logically integrates DevSecOps capabilities. This eliminates the complexities associated with managing various tools, providing better visibility, control, and collaboration throughout the entire DevSecOps lifecycle.

For example, when approaching a software project, Developers need to consider tools for:

• Project planning
• Source Code Management
• Continuous Integration
• Infrastructure configuration
• Incident Monitoring
• Application Security
• Compliance Assurance

GitLab simplifies this by offering a cohesive and centralized platform that covers all these aspects. This approach fundamentally changes how organizations approach DevSecOps, offering a more efficient and streamlined experience for development teams.

GitLab Benefits:

GitLab offers a range of benefits to streamline and enhance the software development lifecycle.

1. Better Insights: Provides end-to-end visibility across the complete software delivery lifecycle (SDLC).

2. Greater Efficiency: Built-in support for automation and integrations with third-party services.

3. Improved Collaboration: Unites developer, security, and ops teams with a single workflow.

4. Faster Time to Value: Enables continuous improvement through accelerated feedback loops.

5. Ease of Adoption: Integrates with your existing toolchain, allowing adoption at your own pace.

6. Security: Security is built in and integrated throughout the complete SDLC.

7. Compliance: Offers comprehensive governance solutions, ensuring separation of duties and compliance assurance between teams.

GitLab's Role for Teams

GitLab serves as a Single DevSecOps Platform, empowering various teams, including Software, Operations, IT, Security, and Business, to collaboratively plan, build, secure, deploy, and monitor software through an end-to-end unified system.

GitLab Features Overview

GitLab is an all-in-one DevSecOps platform, transforming how Development, Security, and Ops teams collaborate and build software. It offers essential tools to streamline the software development lifecycle.

1. Plan: GitLab provides powerful planning tools for portfolio management, including epics, groups, and milestones. It accommodates various methodologies, from Waterfall to DevSecOps, helping teams organize, plan, and track project work for end-to-end visibility.

2. Create: Manage code and project data with GitLab's robust branching tools. It facilitates portfolio planning and management, offering a simple and flexible approach for teams of all sizes to organize, plan, and track project work effectively.

3. Verify: Maintain high-quality code standards with automatic testing and reporting. GitLab supports continuous integration with industry-leading capabilities, enabling automated testing, security testing, and code quality analysis for faster feedback.

4. Package: Build a consistent software supply chain with GitLab's built-in package management. Teams can package applications, manage containers, and build artifacts seamlessly with private and secure registries, enhancing DevSecOps acceleration.

5. Secure: Integrate security capabilities into the development lifecycle. GitLab offers Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Container Scanning, and Dependency Scanning to deliver secure applications and ensure license compliance.

6. Deploy: Automate release and delivery with GitLab's integrated Continuous Delivery (CD) solution. Shorten delivery lifecycles, streamline processes, and accelerate team velocity with automated deployments to multiple environments and advanced patterns like canary deployments.

7. Monitor: Reduce incident severity and frequency with GitLab's monitoring capabilities. Receive feedback and tools to release software frequently with confidence.

8. Govern: Manage security vulnerabilities, policies, and compliance across the organization with GitLab's governance features.

GitLab helps teams improve cycle time, reduce costs, speed time to market, and deliver more secure and compliant applications, fostering collaboration and efficiency throughout the development process.

Git and Version Control

Git is an open-source version control system (VCS) designed to track changes in files, enabling collaborative work while ensuring the integrity of the source code. GitLab serves as a platform for storing and managing files, such as source code and documents, using Git.

• Free open source Version Control System (VCS)
• Tracks changes in source code during software development

Git operates independently of GitLab. It records changes made to files in a repository, facilitating collaboration among developers. Git supports non-linear development and handles large projects efficiently.

Git Features:

• Multiple working copies with the entire change history
• Detailed repository history tracking
• Local branches for individual project versions
• Automatic synchronization when uploading changes to the server (master branch)

Git Benefits:

• Free and open source
• Supports non-linear development
• Tracks history of files
• Creates backups
• Enables collaboration through both command line and GUI
• Scalable with a branching model adaptable to different workflows
• Distributed environment, eliminating the need for a constant connection to a central server

Common Git Terms and Definitions:

1. Branch:

• An independent line of development.
• Used to develop features separately and share the same source code.
• The main branch is the default branch.
• Command: $ git branch [branch_name]

2. Tag:

• Marks a specific point in time on a branch.
• Used for code version releases.
• Command: $ git tag
• Creates, lists, or deletes tags in the repository.

git tag -a <tag_name> -m "Tagging version x.x.x"

3. Checkout:

• Switch between branches and start making changes.
• Execution command: $ git checkout

4. Commit:

• Save changes to the local repository.
• Point-in-time snapshot.
• Command: $ git commit

5. Push:

• Send changes to a remote directory.
• Transfers commits from local to remote repositories.
• Export commits: $ git push
• Import commits: $ git fetch

Git Pull, Git Push, and Git Fetch:

• These commands synchronize repositories but in slightly different ways.
• Git fetch retrieves the latest metadata info without transferring files.
• Git pull does that and brings a copy of changes from the remote repository.

Common Git Commands:

Adding and Committing the New File

git add hello.txt
git commit -m "Add hello.txt"

git add hello.txt: Stages the "hello.txt" file for commit. git commit -m "Add hello.txt": Commits the staged changes with a commit message.

Checking Repository Status Again

git status

Displays the updated status of the Git repository after the commit. Example: Shows that the repository is still on branch "main," and there are no more uncommitted changes.

Branching Overview Explanation:

In a version control system like Git, branching provides a way to work on different aspects of a project simultaneously. The main branch, often named "main" or "master," represents the stable, production-ready version of your code. By creating branches, developers can experiment, introduce new features, or fix issues without affecting the main branch until changes are thoroughly tested and reviewed.

Note: The First Commit Requirement: Before diving into branching, it's essential to understand that every Git repository must have at least one commit. A commit serves as a snapshot of your project at a specific point in time. It includes changes to files, a commit message describing those changes, and a unique identifier known as the commit hash.

Creating a New File for Demonstration

vim hello.txt

Opens Vim to edit the "hello.txt" file for demonstration purposes.

Checking Repository Status with Uncommitted Changes

git status

Displays the status, indicating there are uncommitted changes (changes to "hello.txt"). Example: Shows that there are changes in "hello.txt" that need to be committed.

Understanding the "Git add" Command

git add hello.txt

The git add command stages changes from the working directory to the staging area. In Git, changes are tracked in two stages: working directory (where you make modifications) and staging area (where you prepare changes for a commit). Example: Adds the "hello.txt" file to the staging area for the next commit.

Verifying Staging Area with "Git Status"

git status

The git status command shows the status of the repository, indicating changes in the working directory and the staging area. Staged changes are shown in green, indicating that they are ready to be committed. Example: Confirms that the "hello.txt" file is now in the staging area.

Committing Changes with "Git commit"

git commit -m "Adding hello.txt"

The git commit command creates a new commit with the changes in the staging area. The -m option allows you to include a commit message directly in the command. A commit message provides a concise summary of the changes made in the commit. Example: Commits the staged changes with the message "Adding hello.txt."

Why Branch?

1. Isolation: Branches provide isolated spaces for changes. You can tweak, test, and refine without impacting the main project.

2. Collaboration: If you're working with a team, branches enable collaborative efforts. Each member can have their playground (branch) to contribute without conflicts.

3. Feature Development: Say you're adding a cool feature. Create a branch dedicated to that feature. It won't affect the main project until you're ready to merge it in.

Feature branches FTW! they are a game-changer:

• Focus: You concentrate on one feature or bug fix at a time.

• Safety Net: If something goes awry, your main project remains untouched. No late-night panic moments!

• Easy Integration: When your feature is polished and ready, you smoothly merge it into the main branch, and voila – your masterpiece becomes part of the big picture.

Creating a New Branch

git branch my-feature

The git branch command creates a new branch named "my-feature." The new branch is created, but the working directory and HEAD still point to the main branch.

Checking Out to a New Branch

git checkout my-feature

The git checkout command switches to the specified branch ("my-feature" in this case). It updates the working directory and HEAD to be associated with the "my-feature" branch.

Checking the Branch and Log Again

git status
git log

git status: Confirms the current branch ("my-feature") and that there are no changes to commit. git log: Shows the updated log, indicating the HEAD is now on the "my-feature" branch. Example: Confirms the branch switch and the updated log.

Making Changes to Files

vim hello.txt

Opens the "hello.txt" file in the Vim editor for editing. Modifies the file content (adds "world" to "hello").

Staging Changes and Checking Status

git add hello.txt
git status

git add hello.txt: Stages the changes made to "hello.txt" for the next commit. git status: Shows that changes to "hello.txt" are staged and ready for commit.

Committing Changes

git commit -m "Modifying hello.txt"

The git commit command creates a new commit with the staged changes. The -m option allows including the commit message directly in the command. Example: Commits the changes made to "hello.txt" with the commit message "Modifying hello.txt."

Creating a New File

vim test.txt

Opens the Vim editor to create a new file named "test.txt" with the content "unrelated change."

Staging and Committing New Changes

git add test.txt
git commit -m "Adding test.txt file"

git add test.txt: Stages the new file "test.txt" for the next commit. git commit -m "Adding test.txt file": Commits the staged changes with the specified commit message.

Checking Out to the Main Branch

git checkout main

The git checkout command switches back to the main branch.

Verifying the Branch and Listing Files

git status
ls

git status: Confirms that the working directory is now on the main branch. ls: Lists the files in the directory, showing the absence of "test.txt" on the main branch. Example:

Merging a Branch in Git

git merge my-feature

The git merge command integrates changes from one branch into another. In this case, it merges changes from the "my-feature" branch into the currently checked-out branch (assumed to be "main" based on the context). Example: Merges changes from "my-feature" into the current branch.

Checking the Result and History

ls
cat hello.txt
git log --all --oneline

ls: Lists files in the directory, showing the updated content (possibly the new "test.txt" file). cat hello.txt: Displays the content of "hello.txt," indicating whether the changes from "my-feature" are present. git log --all --oneline: Displays a summarized log of all branches with their respective commit hashes.

Deleting the Merged Branch

git branch -d my-feature

The git branch -d command deletes the specified branch after its changes have been successfully merged. Example: Deletes the "my-feature" branch since its changes are now merged into the main branch.

Using "Git Stash" Command

The git stash command saves the current changes in the working directory and index without committing them. It's useful for temporarily storing changes when you need to switch branches or perform other operations. Example: Stashes changes made to "hello.txt" to experiment without committing them.

Optional: Configuring User Information

git config --global user.name "your_name"
git config --global user.email "your_email@example.com"

Configures the global user name and email for Git. This information is associated with your commits. Example: Sets the user name to "moss" and the email to "your_email@example.com" globally.

Basic Git Workflow:

The basic Git workflow revolves around organizing and expediting releases through a branching strategy, utilizing different types of branches throughout the development process. Here are the key branch types in the typical Git flow:

1. Main (or Master) Branch:

• Created at the project's start and maintained throughout development.
• Contains production-ready code eligible for release.

2. Develop Branch:

• Created at the project's start.
• Holds pre-production code with newly developed features being tested.

3. Feature Branch:

• Most common branch type.
• Used to add new features to the code.
• Functions as the working branch, merged back into the development branch when the feature is complete.

4. Release Branch:

• Created when preparing for new production releases.

5. Hotfix Branch:

• Used for quickly addressing necessary changes in the main branch.

Each branch type serves a specific purpose in managing the development lifecycle. The flow involves creating feature branches to work on specific functionalities, merging them into the development branch for testing, and eventually merging into the main branch for production-ready code.

Every change is recorded as a unique commit, forming a detailed history of file changes, including when and how they occurred, and who made the changes. This commit history is crucial for tracking the evolution of the codebase.

Handson: Starting with Git:

Step 1. Install Git locally

1. Verify Git Installation:

• Open your terminal (Linux/macOS) or PowerShell (Windows).
• Type git version.
• If you see a version number, Git is installed.

2. Install Git (If Not Installed):

• If Git is not installed, check the Installing Git page for instructions on your OS.

Step 2. Generate an SSH key

SSH keys are crucial for secure communication between your local machine and GitLab. Follow these steps to generate an SSH key:

1. Check for Existing SSH Key:

ls -a ~/.ssh    # Linux or macOS
dir ~\.ssh      # Windows

• If id_rsa is listed, you have a key; skip to the next section.

2. Generate SSH Key Pair:

• Run ssh-keygen in the terminal.
• Press Enter for default key location.
• Press Enter for a blank passphrase.

Step 3. Add SSH key to GitLab profile

1. Navigate to GitLab Profile:

• In GitLab, click your avatar's down arrow > Edit profile.

2. Access SSH Keys:

• In the left navigation, select SSH Keys.

3. Navigate to Key Directory:

• In terminal: cd ~/.ssh

4. List Key Files:

• In terminal: ls
• You should see id_rsa (private key) and id_rsa.pub (public key).

5. Display Public Key:

• In terminal: cat id_rsa.pub
• Copy the key.

6. Add Key to GitLab:

• In GitLab, paste the public key into the Key field.
• Enter a Title.
• Click Add key.

7. Verify SSH Setup:

• In terminal: ssh -T git@spt.gitlabtraining.cloud
• If you see a welcome message, your SSH key is set up correctly.

Follow these steps meticulously to ensure a smooth Git and GitLab setup. Now you're ready to collaborate and version control with confidence!

Step 4. Create a Project

1. Navigate to Your Group:

• Click on "Menu" > "Groups" > "Your Groups."
• Open the group named "My Test Group - <USERNAME>."

2. Create a New Project:

• Select "New project."
• Choose "Create blank project."
• Enter "Gitlab Demo Project" in the Project name.
• Ensure "Private" is selected under Visibility Level.
• Check "Initialize repository with a README."
• Click "Create project."

Step 5. Clone a GitLab Project Repository to Your Local Computer

1. Navigate to Project Overview:

• Use the top bar to go to "Menu" > "Projects" > "Your projects" > "Gitlab Demo Project."

2. Clone the Repository:

• Select "Clone" and, in the "Clone with SSH" section, click the "Copy URL" icon.

3. Create a Local Directory:

• In the terminal/PowerShell, create a new directory called "training" in your home directory and navigate into it.
  Copied!

  mkdir ~/training
  cd ~/training
  

  Terminal

  Lines: 2

  UTF-8

4. Clone the Remote Repository:

• Run the following command, replacing <REPOSITORY-URL-YOU-COPIED> with the copied URL.
  Copied!

  git clone <REPOSITORY-URL-YOU-COPIED>
  

5. Move into the Cloned Repository:

• Navigate into the repository you just cloned.
  Copied!

  cd top-level-project
  

6. View Repository Contents:

• Show the contents of the directory, including hidden files and directories.
  • Linux or macOS: ls -a
  • Windows: ls -Force

7. Check for Uncommitted Changes:

• Find out if the directory contains edited files not yet committed to the repository.

  Copied!

  git status
  

• If the output says "nothing to commit," it means the files in this directory match the stored versions in Git.

Step 6. Work on a Branch

1. Create a New Branch:

• Create a new branch named "temporary_branch" on your computer.
  Copied!

  git branch temporary_branch
  

2. Switch to the New Branch:

• Switch to the branch you just created.
  Copied!

  git checkout temporary_branch
  

3. List All Branches:

• List all branches in the repository.

  Copied!

  git branch -a
  

• The red branches are on the remote server (GitLab instance), and the asterisk indicates the current branch.

Step 7. Edit a File

1. Open README.md:

• Using any text editor (e.g., Visual Studio Code, Sublime Text), add a line to the end of README.md and save the file.

2. Check for Modifications:

• See if Git has noticed that the file has been modified.

  Copied!

  git status
  

• The output indicates that Git detected the file edit, but since it's not committed, the change isn't stored in a snapshot yet.

Step 8. Add the edited file to Git's staging area

1. Add to Staging Area:

• Use the following command to add the edited file (`README.md`) to Git's staging area.
  Copied!

  git add README.md
  

• If successful, there will be no output. Remember, this action doesn't physically move `README.md` on your filesystem; it adds it to Git’s "staging area."

2. Check Staging Status:

• Ensure that `README.md` is now ready to be committed by checking the staging status.
  Copied!

  git status
  

Step 9. Commit the edit

1. Commit Staged File:

• Commit the changes you staged in the previous step.
  Copied!

  git commit -m "Add a line to README.md"
  

• This creates a snapshot of the file that can be referred to later if needed.

2. Check Staging Area (Empty):

• Confirm that the staging area is empty again.
  Copied!

  git status
  

Step 10. Push your changes to the GitLab Demo instance

1. Create Remote Branch and Push:

• Create a new branch in the remote Git repository on GitLab server called `temporary_branch` and push your changes to that branch.
  Copied!

  git push -u origin temporary_branch
  

• If you're ever unsure of the exact command to push your changes, simply type `git push`, and Git will provide the correct command.

Step 11. Edit, commit, and push the file again

1. Edit File Locally:

• In your local machine’s text editor, add a new line to the end of your local copy of `README.md` and save the file.
  Copied!

  a second line in README.md
  

2. Move to Staging Area:

• Move the edited file to Git’s staging area.
  Copied!

  git add README.md
  

3. Commit Staged File:

• Commit the changes with a descriptive message.
  Copied!

  git commit -m "Modify README.md"
  

4. See Commit Description:

• View a description of the commit you just made.
  Copied!

  git log
  

5. Push Changes to Remote Repository:

• Push your commit up to the remote repository on the GitLab instance.
  Copied!

  git push
  

6. Navigate and Confirm:

• Navigate to your project in the GitLab app. On project's main page, go to the left-hand navigation pane, select `Repository` > `Branches`, and select `temporary_branch` to switch to that branch. Confirm that the changes made to `README.md` on your local branch were pushed up to the remote repository.

By following these steps, you're effectively editing, committing, and pushing changes in your GitLab workflow.

Step 12. Edit a remote branch

1. Navigate to GitLab:

• Go to the Gitlab Demo Project landing page on GitLab.

2. Select Branch:

• In the left-hand navigation pane, go to `Repository` > `Branches` > `temporary_branch`.

3. Edit in Web IDE:

• Choose `README.md` to see its contents.
• Select `Web IDE` to edit the file.

4. Add a Line:

• In the Web IDE, add a new line to the end of the file.
  Copied!

  a third line added on the remote copy of temporary_branch
  

5. Commit Changes:

• Select `Commit…`.
• Check the radio button for `Commit to temporary_branch`.
• Uncheck `Start a new merge request`.
• Select `Commit` to finalize the changes on the remote repository’s `temporary_branch`.

6. Note:

• Since you made changes in GitLab webapp, the remote repository on the GitLab instance is now one commit ahead of your local repository.

Step 13. Get metadata about changes to the remote temporary_branch

1. Fetch Remote Metadata:

• Retrieve metadata about branches on the remote copy of the repository.
  Copied!

  git fetch
  

2. Check Commits Status:

• Find out how many commits are in the remote copy but not your local copy (or vice versa).

  Copied!

  git status
  

• Tip: After `git fetch`, you can use `git diff origin/temporary_branch` to see changes before pulling, avoiding conflicts with `git pull`.

Step 14. Pull from the remote repository

1. Update Local Copy:

• Merge the remote copy into your local copy.
  Copied!

  git pull
  

2. Check Updated Files:

• Check the output to see how many files Git updated locally.

3. View Updated File:

• View the updated contents of `README.md`.
  Copied!

  cat README.md
  

O. Merge changes back into the main branch

1. Check Current Branch:

• See what branch you are currently working on.
  Copied!

  git branch
  

2. Switch to Main Branch:

• Switch to the main branch.
  Copied!

  git checkout main
  

3. Incorporate Changes:

• Incorporate all changes from your local `temporary_branch` into your local `main` branch.
  Copied!

  git merge temporary_branch
  

Step 15. Update the remote repository

1. Check Status:

• Ensure there are no edited files that need to be staged or committed, and confirm that you are on the `main` branch.
  Copied!

  git status
  

2. Update Remote Main Branch:

• Update the remote copy of the `main` branch with any changes from your local copy.
  Copied!

  git push
  

3. Verify Changes on GitLab:

• Return to the GitLab page in your browser and view `README.md` in your project’s `main` branch to see the changes you just pushed to the remote copy of `main`.