To follow the examples shown in this chapter, you will need Git: https://git-scm.com/. You will also need an interactive shell (for example, Git Bash if you are using MS Windows), a text editor or an IDE for web development (for editing JavaScript and HTML), and a web browser.

You can access the code of an example project used in this chapter at the following URLs: https://github.com/PacktPublishing/Mastering-Git---Second-Edition/tree/main/chapter01 and https://github.com/jnareb/Mastering-Git---Second-Edition---chapter01-sample_project.

A version control system (sometimes called revision control) is a tool that lets you track the history and attribution of your project files over time (stored in a repository) and helps the developers in the team to work together. Modern version control systems give each developer their own sandbox, preventing their work in progress from conflicting, and all the while providing a mechanism to merge changes and synchronize work. They also allow us to switch between different lines of development, called branches; this mechanism allows the developer to change, for example, from working on introducing a new feature step by step to fixing the bug in an older, released version of the project.

Distributed version control systems (such as Git) give each developer their own copy of the project’s history, which is called a clone of a repository. This is what makes Git fast, because nearly all operations are performed locally. It is also...

Let’s follow a step-by-step, section-by-section, simple example of two developers using Git to work together on a simple project. You can find all three repositories (for two developers, and the bare server repository) with the example code files for this chapter, where you can examine the code, history, and reflog, at https://github.com/PacktPublishing/Mastering-Git---Second-Edition, in a sample_project.zip archive.

Following the example

To follow this example of the team development process on a single computer, you can simply create three folders called, for example, alice/, bob/, and server/, and switch to the appropriate folder when following work done by Alice, Bob, and Carol, respectively.

There are a few simple changes you need to make for this simulation to work. When creating a repository as Carol, you don’t need to create and switch to the /srv/git directory, so you can simply skip these commands. In Alice or Bob’s role, you need...

This chapter walked us through the process of working on a simple example project by a small development team.

We have recalled how to start working with Git, either by creating a new repository or by cloning an existing one. We have seen how to prepare a commit by adding, editing, moving, and renaming files, how to revert changes to the file, how to examine the current status and view changes to be committed, and how to tag a new release.

We have recalled how to use Git to work at the same time on the same project, how to make our work public, and how to get changes from other developers. Though using a version control system helps with simultaneous work, sometimes Git needs user input to resolve conflicts in work done by different developers. We have seen how to resolve a merge conflict.

We have recalled how to create a tag marking a release, and how to create a branch starting an independent line of development. Git requires tags and new branches to be pushed explicitly...

Answer the following questions to test your knowledge of this chapter:

1. Describe how to create a repository from existing files and how to get your own copy of an existing repository.
2. Describe how to create a new version of the project locally, and how to publish those changes.
3. Explain how to get changes from other developers, and how to combine those changes.
4. What do merge conflict markers look like, and how can you resolve a merge conflict?
5. What can you do to make Git not show temporary backup files as unknown files in the status output? What about the products and byproducts of the build system?
6. Where can you find information about how to undo adding a file, or how to undo changes to a file?
7. How can you abandon the commit? What are the dangers of doing so?
8. Explain how Git manages moving, copying, and renaming files.

Here are the answers to the questions given above:

1. Use git init, git add ., and git commit to create a repository from existing files. Use git clone to get your own copy of the existing repository.
2. Use git commit or git commit -a to create a new revision, and use git push to publish changes.
3. Use git fetch to get updates from other developers, or git pull to get updates and merge them together. Use git merge (or, as mentioned in later chapters, git rebase) to combine changes.
4. Merge conflicts are presented using the <<<<<<<, =======, and >>>>>>> markers; you can also find the ||||||| marker used, depending on the configuration. To resolve the conflicts, you need to edit files marked as conflicting into shape, use git add on them when finished, and then finalize the merge with git commit or git merge --continue (or rebase with git rebase --continue).
5. To make Git ignore specific types of files, you need to add appropriate...

If you need a reminder about Git basics, the following references might help you.

• Everyday Git With 20 Commands or So, part of the Git documentation as giteveryday(7): https://git-scm.com/docs/giteveryday
• A tutorial introduction to Git, part of the Git documentation as gittutorial(7): https://git-scm.com/docs/gittutorial
• The Git User’s Manual, part of the Git documentation: https://git-scm.com/docs/user-manual
• Eric Sink, Version Control by Example, Pyrenean Gold Press (2011): https://ericsink.com/vcbe/index.html
• Scott Chacon and Ben Straub, Pro Git, 2nd Edition, Apress (2014): https://git-scm.com/book/en/v2