The following terms are often used in documentation, blog posts, and everyday life at GitLab. This list is always a work in progress and additions are very welcome.
A regression is something that used to work one way in the last release and then we made a breaking change and it no longer works the same way.
A regression is defined as a change that results in a negative impact on the functionality of an existing feature due to recent changes, i.e. the latest release.
GitLab's business model. Coined by Andrew Lampitt in 2008, the open core model primarily involves offering a "core" or feature-limited version of a software product as free and open-source software, while offering "commercial" versions or add-ons as proprietary software.
Including to providing access to the source code, open source software must comply with a number of criteria, among them free distribution and no discrimination against persons, groups, or fields of endeavor.
A folder used for storing multiple files.
A directory where Git has been initialized to start version controlling your files. The history of your work is stored here.
A repository that is not-on-your-machine, so it's anything that is not your computer. Usually, it is online, GitLab.com for instance. The main remote repository is usually called “Origin”. Definition via blog post
A copy of an original repository that you can put somewhere else or where you can experiment and apply changes that you can later decide if publishing or not, without affecting your original project.
Terminal on Mac OSX, GitBash on Windows, or Linux Terminal on Linux
a local copy of the project you want to work on.
Independent line of development. New commits are recorded in the history of the branch you are working in.
A process that involves adding new code commits to source code with the combined code being run on an automated test to ensure that the changes do not break the software. Thoughtworks discusses continuous integration
Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. The difference between Continuous Delivery and Continuous Integration
Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing.Amazon moves toward continuous delivery
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
Copying files into another directory on your local computer. This is a common and early form of version control, but it is error-prone.
These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
DVCSs fully mirror the repository. Git, Mercurial, Bazaar, and Darcs are DVCSs. If any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it.
The time it takes to move from idea to production
A natural evolution of software development that carries a conversation across functional groups throughout the development process, enabling developers to track the full path of development in a cohesive and intuitive way. ConvDev accelerates the development lifecycle by fostering collaboration and knowledge sharing from idea to production.
The oversight, development, and maintenance of computer programs. Gitlab has advantages over both legacy and modern ALM tools.
The epicenter of software engineering, quality ssurance, and technology operations. DevOps glossary by XebiaLabs
A commit that shows the changes before and after.
Takes changes from one branch, and applies them into another branch.
A unique identifier of a computer. It is used to identify computers without the need for a password. e.g. On GitLab I have added the ssh key of all my work machines so that the GitLab instance knows that it can accept code pushes and pulls from this trusted machines whose keys I have added.
On your own server. The fact that GitLab is on premise is a strong point for large corporate clients concerned with security.
Git command to synchronize the local repository with the remote repository, by fetching all remote changes and merging them into the local repository. ("git pull origin [branch name]")
Git command to send commits from the local repository to the remote repository.
New files that Git has not been told to track previously. Add them by using the command "git add [file path]"
Files that have been modified but are not committed. Check them by using the command "git status"
Modified files that have been marked to go into the next commit.
A way for for an app to provide other applications with real-time information. e.g. send a message to a slack channel when a commit is pushed
The use of open source development techniques within the corporation.
The ability to initiate an action from chat.
Bots that run in your chat application and give you the ability to do "anything" from chat.