Sign In Start Free Trial

Book Overview & Buying
Table Of Contents
Feedback & Rating

Gitlab Cookbook

By : van Baarsen

3.3 (3)

Gitlab Cookbook

3.3 (3)

By: van Baarsen

Overview of this book

This book is aimed at developers and devops that have a GitLab server running, and want to be sure they use it to its full potential. This book will also be useful for people looking for a great Git platform, and learn how to set it up successfully. Some system administrating experience on a UNIX-based system would be useful, but is not required.

Preface

Preface

What this book covers

What you need for this book

Who this book is for

Sections

Conventions

Reader feedback

Customer support

Free Chapter

1. Introduction and Installation

1. Introduction and Installation

Introduction

Using the Omnibus package

Setting up the server dependencies for source installation

Set up the database for source installation

Installing GitLab from source

Using Chef and GitLab Cookbook

Logging in for the first time

Creating your first project

2. Explaining Git

2. Explaining Git

Introduction

Generating your SSH key on Unix-like systems

Generating your SSH key on Windows

Adding your SSH key to GitLab

Creating your first Git project

Cloning your repository and pushing code to it

Working with branches

Performing a rebase operation

Squashing your commits

3. Managing Users, Groups, and Permissions

3. Managing Users, Groups, and Permissions

Introduction

Adding a user

Creating a group

Working with user permissions

Protecting your main branches

Configuring the project's visibility

Removing a user

4. Issue Tracker and Wiki

4. Issue Tracker and Wiki

Creating your first issue

Creating your first merge request

Accepting a merge request

Referencing issues

Working with milestones

Creating your first wiki page

Managing your wiki with Gollum

5. Maintaining Your GitLab Instance

5. Maintaining Your GitLab Instance

Introduction

Updating an Omnibus installation

Updating GitLab from a source installation

Troubleshooting your GitLab installation

Creating a backup

Restoring a backup

Importing an existing repository

6. Webhooks, External Services, and the API

6. Webhooks, External Services, and the API

Introduction

Working with external services

Using webhooks

Using system hooks

Getting your private token for the API

Understanding the API status codes

Managing your projects via the API

Managing issues via the API

Working with other API resources

Working with the API sudo command

7. Using LDAP and OmniAuth Providers

7. Using LDAP and OmniAuth Providers

Introduction

Setting up your LDAP server

Installing a web interface for LDAP

Adding a user to your LDAP server

Configuring GitLab to use LDAP on an Omnibus installation

Configuring GitLab to use LDAP on a source installation

Setting up GitHub as an OmniAuth provider

8. GitLab CI

8. GitLab CI

Introduction to GitLab CI

Installing the dependencies

Installing the coordinator

Installing the web server

Installing a runner

Linking your first project to GitLab CI

Creating a build script

Using GitLab CI webhooks

A. Tips and Tricks

A. Tips and Tricks

The power of snippets

Getting involved

Getting help

The GitLab RSS feed

Archiving projects

How to format a good Git commit message

How to change your Git editor

Understanding the anatomy of GitLab

Understanding the differences between GitLab's Community Edition (CE) and Enterprise Edition (EE)

How to fork a project and what is forking?

Understanding the branching workflow

Index

Index

Customer Reviews

3.3 (3)

5 star

33.3%

4 star

33.3%

3 star

0%

2 star

0%

1 star

33.3%

Understanding the branching workflow

When you start using Git, you might be tempted to push all your code directly to the master branch. This might not be very good for multiple reasons, one of them being that you can't experiment with new features very well as you pushed everything to master. You can't simply delete the branch and start over.

The branching workflow tries to solve this by making sure that the master branch is always the latest stable code, and it has to be deployable at all time. So, only code that has been tested and proven to work can go in there.

Let me explain this a bit further.

When you start working on a new feature, you create a new branch, which is named after the feature you're working on. This branch is separate from the master branch as that is the latest stable version of the code. You directly push this new branch to GitLab and create a merge request for it. This way, your team knows what you're working on, and it allows them to comment on...

Visually different images

CONTINUE READING

83

Tech Concepts

36

Programming languages

73

Tech Tools

Unlimited access to the largest independent learning library in tech of over 8,000 expert-authored tech books and videos.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

50+ new titles added per month and exclusive early access to books as they are being written.

Gitlab Cookbook

Search

Your notes and bookmarks