GitLab is built on the Git version control system. In this chapter, learn what exactly that means and how version control is different from other ways of managing files.
- [Interviewer] Git Lab is built on the git version control system. In this chapter we'll learn about what exactly that means and how version control is different from other ways of managing files. Let's take a minute to look at what life is like without version control. Imagine you have a document that you and several colleagues are working on together. Say a job description for a new position you'd like to hire. Of course you could use something like Dropbox Paper or Google Docs, and collaborate in real time, but let's say your corporate IT department is particularly draconian and blocks those sites. So you write out a list of qualifications and attach a file called jobdescription.doc to an email and send it out to the team asking for their comments. Meanwhile, Steve is also working on a doc, job.doc that's mostly overlapping with the other two, and he emails that out to the team after you've sent out your revised jobdescription_v2.doc out to the whole thread. So Karen volunteers to combine them this time, but she didn't see your revised version, so now she has her list and Steve's list in a document called openposition-combined.doc, but she also decided that she didn't like some of Steve's list so she didn't include it. There are now five separate documents on the email thread with various overlap. So how does this situation get resolved? Generally the entire team schedules the meeting to actually do the work of writing the job description. Sounds terrible, right? Now imagine instead of developing a single job description between three people you were developing a complex software application with 10's or 100's or 1000's of lines of code and a team of 50 developers. It just isn't possible without some kind of system, either a strict set of rules of a piece of software. Let's go back to our job description document. With Git Lab you can just work on your list directly on the server in your own copy of the project which is known as a branch in Git. Once you're satisfied with your changes, you can merge them into the main document. Once Karen is ready with her list, she'll merge it into the main document. Depending on the changes, she might be prompted at that point to fix conflicts line by line. For example, if both of you started with the same document and edited the same line, one of you would need to manually decide which version to use or write a new version that combined all the changes. Finally, when Steve is done, he'll be able to see everyone's lists and he can see which parts of his own changes he needs to change, or what needs to be removed. I want to emphasize that there's no magic here. Collaborating still requires manual work figuring out how to combine the documents, but Git forces that to happen in a structured way, and that makes it easy to see what other people are doing.
- Managing files with version control
- The basics of Markdown
- Creating a GitLab project
- Using the GitLab editor
- Staging and committing in the web IDE
- Tags, releases, and history
- Using the collaboration features in GitLab