10-Minute Guide to Git Version Control for Testers
Learn to use Git for work quickly
In my training, one of the early tasks is to teach the manual testers to use Git. Just like programmers’ code, automated test scripts need to be stored in a version control system. Git is the de-facto version control (also known as source control) system for source code.
Besides the obvious benefits of version control, such as
sharing the updates among the team members
traceability (who changed what)
document history (also backups)
…
For testers in a team, they get the latest automated test scripts (changes from others) via a version control system. There is also a need for automated testers to execute an automated test suite in a Continuous Testing (CT) server, and the CT server gets the latest automated test scripts and supporting data via a version control system like Git.
Tip: Create a separate repository for automated test scripts only, do not mix with the source code, at least initially.
This article will show testers how to use Git to work quickly, in around 10 minutes. Git is applicable for various IT tasks, not just for programmers or testers, for example, my daughter has used Git to version control her IT homework since high school.
I suggest you skim through the article (that’s how many youths read anyway 😊), and perform the exercise step by step on your computer. Then come back to read the text one more time to understand better how Git works.
Install Git (~90 seconds)
Git is available on all platforms. macOS and some Linux distributions pre-installed Git. Here I will show you how to install Git on Windows quickly.
Google “Git Windows”, which will get you to the Git Download page. Click the “Download for Windows” button. After completing the download, run the installer.
Accept all the default opinions, i.e., keep pressing the ‘Enter’ key until completing the installation.
Git with Command-Line or GUI tool (15 seconds)
Many people think that beginners would prefer Git GUI tools such as Sourcetree and TortoiseGit, but I disagree. Git is easy to use for basic operations. For most Git operations, I have always been doing it from the command line. Sometimes, I do use GUI tools to compare the differences between revisions and others.
Most manual testers I mentored did not know Git (or version control) before, and I taught them to use Git from the command line. They all mastered the basics that are enough for daily use quickly (in minutes). Surely, there is more to Git, such as merging and branching, but we will leave it for later. The important thing for effective learning is that the students can quickly apply the newly learned knowledge and find it useful. They will grow.
Once a programmer saw a tester was using Git from the command line. (I taught her the day before, using this guide)
The programmer commented: “That’s hardcore!”
The tester felt very proud.
Back to hands-on, here is how to start a Command Prompt window on Windows.
First Try: Clone an existing Repository (~45 seconds)
In a command window, type the commands below to create a new folder (mkdir ) and change the current work directory (`cd`) to it.
Then type (or copy-n-paste) this command,
git clone https://github.com/testwisely/agiletravel-ui-tests.gitto clone (i.e., retrieve) an existing repository on GitHub.
Now, there is agiletravel-ui-tests folder under demo .
You can think of the above command retrieving a folder (containing files and subfolders) for now. (of course, it is more than that. Explanations will be provided later)
[Optional] If you have had the test automation execution environment set up, you may run an automated test script.
> cd C:\demo\agiletravel-ui-tests\selenium-webdriver-rspec
> rspec spec\login_spec.rbIf your configuration (for executing tests) is OK, you shall see test execution in a Chrome browser. The output in the command window:
Understands Git folder (30 seconds, read this part later)
Under agiletravel-ui-tests , there is a special hidden folder .git .
If you cannot find it, it is because Window Explorer hides the hidden files. Check the ‘Hidden Items’ option under the ‘View’ tab.
There are many files and subfolders under the .git folder, which is a Git repository that stores all versioned files in a compressed format (we don’t need to care).
The important file is .git/config , as its name suggests, it is the configuration of the Git repository on your local computer. It is a text file.
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
[remote "origin"]
url = https://github.com/testwisely/agiletravel-ui-tests.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/masterAgain, beginners don’t need to understand it. They only need to know that the parent repository (the correct term in Git is ‘remote repository, but I use ‘parent’ as I think it is easier to understand) is defined in this configfile.
Set up a new Git Repository
Create a repository for the team so that the team members can share the test scripts.
Create a new Git repository (~30 s)
The simplest way is to use a folder on the shared network drive.
Some might ask why not use GitHub, BitBucket or Azure Repos? Yes, you can use them. But in reality, it usualy takes longer to set it up by others (with certain privlieges). I recommend starting with this way. Remember, you can easily migrate to Github (or others), without any data lose.
> mkdir G:\share\repos\my-ui-tests
> G:
> cd G:\share\repos\my-ui-testsType the command below to create a new Git repository, i.e., .git folder under the working folder.
> git init .The output in the command line window:
You may want to view it in Windows Explorer.
2. Clone from an existing one (~30 s)
Take a copy of an existing repository from a known location.
> cd C:\work
> git clone G:\share\repos\my-ui-testsThe output in the command window:
Then you will get the working folder: c:\work\my-ui-tests , which contains a .git folder, i.e. repository. Yes, it is empty, as expected.
Unlike using the server-based version control system such as Subversion, you can perform version control operations, such as commit, locally.
Common Git commands (Level 1)
3. Status: show the status of local files compared to the repository (~20 s)
Now we add some files to the working folder. For example, here are the test skeleton files created by TestWise.
> git status
The untracked files: means the repository does not ‘know’ these files within the working folder yet.
4. Add: add new files to the repository (~20 s)
Run the command below to add all the files to the (local) Git repository.
> git add .Run git status to view.
At this stage, the local Git repository knows these files are to be added but is not done yet. To make it happen, do a commit.
6. Commit: Confirm your local changes (~20 s)
After making some changes (to files), you need a step to ‘tell’ the Git repository. This step is called “Commit”.
> git commit -am "reason for change"To help you remember: “we commit in the morning (AM)”. -a switch means ‘all changed files’; -m is the description of what the changes are.
Rerun git status .
7. Push: publish your changes (~45 s)
After the commit, the changes are still local only, i.e., your team members won’t get them. To make your changes available to others, you need to push your changes to the master repository.
> git push origin masterYou will see the following error:
This means that no permission is given to push to the parent repository. The fix is shown in the text.
> cd /d G:\share\repos\my-ui-tests
> git config receive.denyCurrentBranch ignoreYou only need to do the above once.
Now run the git push origin master again.
8. Pull: Get the updates from others (~60 s)
The master repository is the one where all team member’s commits go. To get others’ changes, do a ‘Git Pull”.
Run the command (from the command line) within a local working folder.
> git pullIf no new updates from the parent repository:
If there are new changes (to the parent repository):
To achieve it, clone the parent repository to another working folder. Make some changes there and do a
git push. Basically, a replay about Step 2, 6, and 7.
You will see that the files in the working folder might be changed: (newly created, deleted or updated).
Tip: do
git pullregulally, like every 1 or 2 hours. This will help you avoid conflicts (you and your colleagues made changes to the same files).
Common Git commands (Level 2)
9. Show the change history (~15 s)
To see who changed what, run this command:
> git log --stat
If the entries (in reverse chronological order) are too long, type q to end it.
10. Discard all changes (~30s)
We often make mistakes in editing test scripts and want to discard all changes, .i.e, back to the last version. This is called ‘Check out’ a revision from the repository to the local working folder.
For example, I added one file new.txt and modified a couple of files.
But I realized the changes were no good and decided to discard all changes.
> git checkout -f
The working folder is “clean” again.
There are plenty of online resources and tutorials on Git. You can learn more at other times. But for now, you shall have enough knowledge of Git to work effectively on automated test scripts in a team environment.
Resources:
Git Explorer, a quick way to show Git command syntax