By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
Objective 3.3: Given a scenario, perform basic version control using Git Key Topics: Understanding Version Control Setting Up Your Git Environment Committing with Git Tags Merging Versions Linux is a popular development platform. If you are administering a system for programmers, it is important to understand the various tools they employ. In addition, you may find yourself writing complex shell scripts that require similar tools. In this guide, we take you through the concepts of version control and the popular Git utility, which implements it. Understanding Version Control Two software developers, Natasha and Bruce, are working furiously on a new project called StoneTracker. The project is broken up into several program files that now have names such as UI‐3.2.A‐73.py due to all the modifications and revisions. Natasha and Bruce are constantly telling each other what file they are working on so that the other one doesn't accidentally overwrite it. In addition, they have created several directory trees to store the various project file amendments. The project has become bogged down with these complications and the extra communication it requires. These developers need version control. (also known as source control or revision control) is a method or system that organizes various project files and protects modifications to them. Version control methods or systems can control more than program files. They can typically handle plaintext files, executable files, graphics, word processing documents, compressed files, and more. A version control system (VCS) provides a common central place to store and merge project files so that you can access the latest project version. A VCS protects a file so that it is not overwritten by another developer and eliminates any extra communications concerning who is currently modifying it. Additional benefits include situations around new developers entering the project. For example, if Tony is a new team member, he can copy the latest StoneTracker project files via the version control system and begin work. Distributed version control systems make projects even easier. The developers can perform their work offline, without any concerns as to whether or not they are connected to a network. The development work takes place locally on their own systems until they send a copy of their modified files and VCS metadata to the remote central system. Only at that time is a network connection required. A side benefit is that now the work is backed up to a central location. A new version control system for Linux projects was created by Linus Torvalds in 2005. He desired a distributed VCS that could quickly merge files as well as provide other features that the Linux developers needed. The result was Git, which is a popular high‐performance distributed VCS. Git is a distributed VCS, which is often employed in agile and continuous software development environments. The figure below shows a conceptual depiction of the Git environment. To understand Git's underlying principles, you need to know a few terms about its configuration: Figure: Conceptual depiction of the Git environment
Working Directory- The working directory is where all the program files are created, modified, and reviewed. It is typically a subdirectory within the developer's home directory tree. The developer's computer system can be a local server or laptop, depending on workplace requirements. Staging Area- A staging area is also called the index. This area is located on the same system as the working directory. Program files in the working directory are registered into the staging area via a Git command (git add). The staging area employs a hidden subdirectory named .git, which is created with the git init command.
When files are cataloged into the staging area, Git creates or updates information in the index file, .git/index, concerning those files. The data includes checksums, timestamps, and associated filenames. Besides updating the index file, Git compresses the program file(s) and stores the compressed file as an object(s), also called a blob, in a .git/objects/ directory. If a program file has been modified, it is compressed and stored as a new object in the .git/objects/ directory. Git does not just store file modifications; it keeps a compressed copy of each modified file. Local Repository- The local repository contains each project file's history. It also employs the .git subdirectory. Project tree and commit information is stored as objects in the .git/objects/ directory via a Git command (git commit). This data is called a snapshot. Every commit creates a new snapshot. Old snapshots can be viewed, and you can revert to previous ones if desired. Remote Repository- The remote repository is typically a cloud‐based location. However, it could also be another server on your local network, depending on your project's needs. Prominent remote repositories include GitHub, GitLab, BitBucket, and Launchpad. However, by far, GitHub is the most popular.
Using Git as your VCS includes the following benefits: Performance: Except for sending/retrieving files to/from the remote repository, Git uses only local files to operate, making it faster to employ. History: Git captures all the files' contents at the moment the file is registered with the index. When a commit is completed to the local repository, Git creates and stores a reference to that snapshot in time. Accuracy: Git employs checksums to protect file integrity. Decentralization: Developers can work on the same project, but they don't have to be on the same network or system. Older VCSs required developers to be on the same network, which didn't provide a great deal of flexibility. They were also slower in operation, which is one reason Linus Torvalds decided to create Git. Setting Up Your Git Environment The Git utility typically is not installed by default. Thus, you'll need to install the git package prior to setting up your Git environment. Read “Governing Software” for details on package installation.
After you have the git package installed on your system, there are four basic steps to setting up your Git environment for a new project:
To begin the process for a new project, create a working directory. A subdirectory in your local home folder will suffice.
An example is shown in below. List: Creating a working directory using the mkdir command $ mkdir MWGuard $ cd MWGuard $ pwd /home/Christine/MWGuard In List: you create a simple subdirectory, MWGuard, for the project. After the working directory is created, you use the cd command to move your present working directory into it. Within the working directory, initialize the .git/ directory. This task employs the git init command. An example is shown in List 27.2. List: Initializing the .git/ directory via the git init command $ git init Initialized empty Git repository in /home/Christine/MWGuard/.git/ $ ls ‐ld .git drwxrwxr-x. 7 Christine Christine 119 Feb 6 15:07 .git
The git init command creates the .git/ subdirectory. Because the directory name is preceded with a dot (.), it is hidden from regular ls commands. Use the ls ‐a command or add the directory name as an argument to the ls command, as was done in List 27.2, in order to view its metadata. Note: .git/ directories. Just create a separate working directory for each one. If this is the first time you have built a .git/ subdirectory on your system, modify the global Git repository's configuration file to include your username and email address. This information assists in tracking file changes. The git config command lets you perform this task, as shown below. List: Modifying a local Git repository's config file using the git config command $ git config ‐‐global user.name "Christine Bresnahan" $ git config ‐‐global user.email "[email protected]" $ git config ‐‐get user.name Christine Bresnahan $ git config ‐‐get user.email [email protected] By including the ‐‐global option on the git config command within
In the above list,you store the user.name and user.email data in the global Git configuration file. Notice that you can view this information by using the ‐‐get option and passing it the data's name as an argument.
Git configuration information is stored in the global ~/.gitconfig file and the local repository, which is the working‐directory/.git/config configuration file. (Some systems have a system‐level configuration file, /etc/gitconfig.) To view all the various configurations, use the git config ––list command, as shown ibelow. List: Viewing Git configuration settings using the git config ‐‐list command $ git config ––list user.name=Christine Bresnahan [email protected] core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true $ cat /home/Christine/.gitconfig [user] name = Christine Bresnahan email = [email protected] $ cat /home/Christine/MWGuard/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true
The settings that are displayed via the ––list option use a file-section.name format. Notice that when the two Git configuration files (global and project's local repository) are displayed to STDOUT via the cat command shown above, the section names are shown along with the data they hold. When your local Git environment is configured, it is time to establish your project's remote repository. For demonstration purposes, we chose the cloud‐based remote repository GitHub. If you want to follow along, you can set up a free remote repository at github.com/join. Note: git utilities on non‐text files.
After you have your project's remote repository established, you'll need to record the URL it provides. This web address is used for sending your project files to the remote repository, which is covered later in this guide. Committing with Git When you have your Git environment established, you can begin using version control. There are four steps:
Depending on your team's workflow, you may repeat certain steps before progressing to the next one. For example, in a single day, a programmer adds files as they are completed to the staging area. At the end of the day, the developer commits the project to the local repository and then pushes the project work to the remote repository for nonlocal team members to access.
In thr above list, a simple shell script was created called MyScript.sh to use as a Git VCS example. List: Viewing a simple shell script named MyScript.sh $ cat MyScript.sh echo "Hello World" After the program is created (or modified), it is added to the staging area (index). This is accomplished through the git add command, as shown below. The file is in the working directory, and you perform the git add command while located in that directory. List: Adding a program to the staging area via the git add command $ git add MyScript.sh $ git status # On branch master # Initial commit # Changes to be committed: # (use "git rm ––cached <file>…" to unstage) # new file: MyScript.sh
The git add command does not provide any responses when it is executed. Thus, to see if it worked as desired, use the git status command, as shown above. The git status command shows that a new file, MyScript.sh, was added to the index. Notice also the name branch master. Git branches are covered later in this guide. You can add all the files in the current working directory to the staging area's index at the same time. To accomplish this, issue the git add . command. Note the period (.) at the end of the command. It is effectively a wildcard, telling Git to add all the working directory's files to the index.
Tip: .gitignore file in the working directory. Add the names of files and directories you do not want included in the index. The git add . command will now ignore those files. The staging area's index filename is .git/index, and when the file command is used on it, below, the file type is shown as a Git index. Git uses this file to track changes to the file. List: Looking at the staging area index file with the file command $ file .git/index .git/index: Git index, version 2, 1 entries
The next step in the process is to commit the project to the local repository. This will create a project snapshot, which contains information such as the project's current tree structure and commit data. Git stores this data in the .git/ directory. The commit is accomplished using the git commit command, as shown in List 27.8. The ‐m option adds a comment line to the COMMIT_EDITMSG file, which is used to help track changes.
When you make commits later in the project's life, it is useful to include additional information to the ‐m option arguments, such as ‐m "Presentation Layer Commit". List: Committing a file with the git commit command $ git commit ‐m "Initial Commit" [master (root-commit) 6d2370d] Initial Commit 1 file changed, 5 insertions(+) create mode 100644 MyScript.sh $ cat .git/COMMIT_EDITMSG Initial Commit nothing to commit, working directory clean
When you have committed the project to the local repository, the git status command will display the message shown in List 27.8 indicating that all the files have been committed. Note: ‐m option and its argument to the git commit command, you are placed into the vim editor to edit the .git/COMMIT_EDITMSG file by hand. The vim editor was covered in “Searching and Analyzing Text.”
Now that the project is committed to the local repository, you can share it with other development team members by pushing it to the remote repository. If the project is complete, you can also share with others or the whole world. If this is a new project, after you have set up your remote repository account, create a Markdown file called README.md. The file's content displays on the remote repository's web page and describes the repository. It uses what is called the Markdown language. An example of creating this file, adding it to the staging area index, and committing it to the local repository is shown below. List: Creating, adding, and committing a README.md file $ ls MyScript.sh $ echo "# Milky Way Guardian" > README.md $ echo "## Programming Project" >> README.md $ cat README.md # Milky Way Guardian ## Programming Project $ git add README.md # (use "git reset HEAD <file>…" to unstage) # new file: README.md $ git commit ‐m "README.md commit" [master 4541578] README.md commit 1 file changed, 2 insertions(+) create mode 100644 README.md Note: README.md file by using various features of the Markdown language. Find out more about Markdown at http://guides.github.com/features/mastering-markdown.
At any time you can review the Git log, but it's always a good idea to do so before pushing the project to a remote repository. An example of how to view the log is shown below. Each commit is given a hash number to identify it, which is shown in the log. Also, notice the different comment lines along with dates as well as author information. List: Viewing the Git log via the git log command $ git log commit 45415785c17c213bac9c47ce815b91b6a9ac9f86 Author: Christine Bresnahan <[email protected]> Date: Fri Feb 11 13:49:49 2022 -0500 README.md commit commit 6d2370d2907345671123aeaaa71e147bd3f08f36 Date: Wed Feb 9 15:23:11 2022 -0500 Initial Commit
Before you can push your project to the remote repository, you need to configure its address on your system. This is done via the remote add origin URL command, where URL is the remote repository's address. List: Configuring the remote repository with the git remote command $ git remote add origin https://github.com/C‐Bresnahan/MWGuard.git $ git remote ‐v origin https://github.com/C‐Bresnahan/MWGuard.git (fetch) origin https://github.com/C‐Bresnahan/MWGuard.git (push)
Notice above that you can check the status of the remote address using the git remote ‐v command. It's a good idea to check the address before pushing a project.
Tip: git remote rm origin command. After it is removed, set up the remote address again using the correct URL. After the remote repository URL is configured, push your project up to its location. An example is shown below. List: Pushing the project to the remote repository with git push $ git push ‐u origin master Username for 'https://github.com': C‐Bresnahan Password for 'https://[email protected]': Counting objects: 6, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 561 bytes | 0 bytes/s, done. Total 6 (delta 0), reused 0 (delta 0) To https://github.com/C-Bresnahan/MWGuard.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
Typically the remote repository will demand a username and a password, unless you have set it up to use SSH keys (OpenSSH was covered in “Looking at Access and Authentication Methods”). When the project is pushed to the remote repository, you should be able to view it. If it is a private repository, you'll have to log into the remote repository in order to see your work. The figure below shows the remote repository for this project. Keep in mind that different providers will have different user interfaces for your projects. Figure: MWGuard remote repository
What is really nice about the remote repository is that your project team can pull down the latest files for the project using the git pull command. You'll need to either set up access for them to the remote repository or make it public. A snipped example of pulling files is shown below. List: Pulling the latest project files from the remote repository with git pull $ git remote add origin https://github.com/C‐Bresnahan/MWGuard.git $ git pull ‐u origin master […] Auto-merging MyScript.sh […] Note: git pull command will fail. However, the error message will instruct how to rectify this problem.
A new development team member can copy the entire project, including the .git/ files, to their local system from the remote repository using the git clone command. A snipped example is shown below. List: Cloning a project from remote repository via git clone $ git clone https://github.com/C-Bresnahan/MWGuard.git Cloning into 'MWGuard'… remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0 Unpacking objects: 100% (6/6), done. MWGuard $ ls ‐a . .. .git MyScript.sh README.md $ git log README.md commit Date: Wed Feb 9 15:23:11 2022 -0500
When the project is cloned from the remote repository, the working directory is automatically created, along with the .git/ directory, the Git staging area (index), and the local repository. The git log command shows the project's history. This is an easy way for a new team member to grab everything needed to begin working on the project. Tags As you start committing newer versions of files to your project and the project history becomes longer, things can quickly get confusing. To help maintain some organization, the Git software provides tagging. Tagging allows you to mark specific commit versions with additional information, such as a release number. You can then easily reference specific versions in the repository based on the tags you assigned.
There are two tag formats available in Git: Lightweight: Only includes a tag name Annotated: Includes the tag name, plus additional metadata that can provide additional information to help identify the version
To create a lightweight tag, just use the git tag command, along with the tag name: $ git tag v2.0
The command doesn't return any information, but you can verify that the tag was created by using the git tag command without any parameters, which lists the existing tag names: $ git tag v0.1 v1.0 v1.5 v2.0
To create an annotated tag, include the ‐a parameter, along with the ‐m parameter to specify the descriptive text you want to add: $ git tag ‐a v2.1 ‐m "development code for 2.0 branch"
Tags can help you identify production versus development versions, making it easier to identify where in the commit history release changes occur. Merging Versions A helpful concept in Git is branches. A is an area within a local repository for a particular project section. By default, Git stores your work in the master branch, as shown below. List: Viewing the branch in use with the git status command $ git status # On branch master
You can have multiple branches within a project.
A simple example is having a branch for production software (master), a branch for software in development (develop), and a branch for testing development changes (test). You can designate the branch you wish to work on to protect files in another branch from being changed. Using the example, you certainly would not want your development code files going into the production branch (master). Instead, you want them maintained in the develop branch until they are tested in the test branch and ready for production.
Let's take a look at a project that needs to use branches.
The StoneTracker project is in production, and its files are managed via the master branch, as shown below. List: Viewing the current branch in use via the git branch command $ git branch * master
Notice the * master line above. The asterisk (*) indicates that the current branch is master and that it is the only branch. If there were more branches, they would also be displayed. The current branch always has the asterisk next to it. You can view the filenames within a particular branch by using the git ls‐tree command. The StoneTracker project's committed files are shown below. List: Viewing the file names in the master branch $ git ls‐tree ––name‐only ‐r master README.md ST-Data.py ST-Main.py
In the master branch (production), the StoneTracker project currently uses a text‐based user interface via its business tier, ST‐Main.py. The development team needs to add a presentation layer, which will provide a GUI. To create this new program without affecting production, they create a new branch to the project using the git branch command shown below. List: Creating a new branch with the git branch branch‐name command $ git branch develop $ git branch develop
Notice from above that when the new branch, develop, is created, it is not set as the current branch. To change branches, the git checkout command is needed, as shown below. List: Switching to a branch via the git checkout branch‐name command $ git checkout develop Switched to branch 'develop' * develop master
Now that the branch is switched, development on the new user interface (ST‐UI.py) can occur without affecting the master branch. However, Git VCS is still employed, as shown below. List: Using GIT VCS on the develop branch README.md ST-Data.py ST-Main.py ST-UI.py $ git add . # On branch develop # new file: ST-UI.py $ git commit ‐m "New User Interface" [develop 1a91bc3] New User Interface 1 file changed, 47 insertions(+)
create mode 100644 ST-UI.py When development (and testing) on the new user interface is completed, the develop branch is merged with the master branch (production). To merge branches, use the git merge branch‐name‐to‐merge command. Merges must be performed from the target branch. Therefore, in this case you must go back to the master branch prior to issuing the command, as shown snipped below. List: Merging a branch via the git merge command $ git checkout master Switched to branch 'master' $ git merge develop Updating 0e08e81..1a91bc3 Fast-forward ST-UI.py | 47 […] $ git ls‐tree ––name‐only ‐r master ST-UI.py commit 1a91bc30050ef1c0595894915295cc458b2539b7 Date: Fri Feb 11 18:03:18 2022 -0500 New User Interface commit 0e08e810dd767acd64e09e45fff614288144da45 Date: Fri Feb 11 16:50:10 2022 -0500 Initial Production Commit
Notice from above that now within the master branch, the new production tier program, ST‐UI.py, is managed. Also notice that the Git logs between the two branches were also merged, as shown by the git log command. Note: rebasing. Instead of simply merging the commits and history logs into a single branch, rebasing performs new commits for all the files, which simplifies the history logs. To rebase a project, replace git merge with the git rebase command. Which one you employ is dependent on your organization's development workflow as well as team member preferences.
The distributed VCS utility Git is useful in many ways beyond the needs of developers. Understanding how to set up working directories, staging areas, and local and remote repositories is a wonderful skill set. Not only will you be able to use the appropriate lingo with your programmers, you can implement Git for various other useful things to manage your Linux systems. Important exam questions: Describe version control. - Version control is a method or system that organizes various project files and protects modifications to them. A distributed VCS allows developers to work offline and independently. The Git VCS provides a working directory, staging area (index), and local repository and uses a remote repository provided by a third party. It is popular due to high performance, maintained modification history, file protection, and decentralization. Explain how to set up your Git environment. - The git package provides the various Git tools used for VCSs. Create a working directory for each project using the mkdir command. The .git/ directory, used by both the staging area and the local repository, is initialized via the git init command. Finally, a third party, such as GitHub, can provide the remote repository to use with the various Git tools. Detail committing with Git. - As needed, files are moved from the working directory to the staging area (index) via the git add utility. The project's workflow dictates when the programs are moved to the local directory via the git commit command and then on to the remote repository via the git push utility. If a remote developer needs the latest project files, the git pull command is used. For new team members who need all the project files, including modification history, the git clone command is used. Summarize Git branches. - A Git branch is a local repository area employed for a particular project section, such as development or project testing. By default, the main branch is called the master branch. New branches are created using the git branch branch‐name command. You can view the various branches available using the git branch utility, which uses an asterisk to denote the current branch. To switch to another project branch, git checkout branch‐name is employed. After work on the branch is completed, its VCS files and project files can be merged with another branch via the git merge branch‐name‐to‐merge command.
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.