Git practice for automation engineers.

Photo by Roman Synkevych

In my recent article, I offered my vision of how code review should take place in test automation. In this article, I want to continue and present the best practices of working with the Git version for discussion.

Version control (sometimes called source control) plays an important role in any development project, including test automation. This is the practice of tracking and providing control over changes made to the source code. And since one of the most common tools used in version control is Git, let’s take a look at some of the most common Git commands.

All automation engineers have to work with Git every day, but not everyone pays much attention to this tool. This article aims to introduce some useful Git functionality and show how it is used in practice. First of all, this article can be useful for novice automation engineers who want to improve their expertise in working with Git and people who want to but do not know how to keep their repository clean and tidy.

To begin with, I would like to describe my point of view about the” right “ repository. The main difference between such a repository is a clean commit history. Each of these commits should be a meaningful atomic unit of changes in the project. This means that our history should not contain commits with messages like “feature in progress”. Your task is to learn how to divide all the changes you make into such atomic units.

Benefits of Git.

• It’s free (and open-source): you don’t need to purchase, and of course, since it is open-source, you are free to contribute to the code any time.
• Performance: Git focuses on file content rather than on filenames, which makes it faster and more reliable than other version control software.
• Security: Git protects the code and the change history, through a cryptographically secure hashing algorithm called SHA1.
• Widely-used: Git has become the preferred VCS tool in many great organizations.

Most common Git commands.
Using git –help in the command line will give you a list of the available Git commands:

the output of the git — help on mac os command

Let’s look over some of the most useful Git commands and understand them.

Clone. It is a Git command-line utility for selecting an existing repository and creating a clone of it, i.e. a copy.

git clone <url remote repo>

To clone a specific branch, you can use

git clone -b <branch> <url remote repo>

Fetch. This command gets all of the branches from the repository. This also downloads all of the required commits and files from the other repository.

git fetch <url remote repo>

Checkout. This command allows you to move between branches.

git checkout <branch name>

Also, you may create a new branch and switch to it.

git checkout -b <branch name>

Add. This is the command you need to use to stage changed files.

git add <file path>

Commit. This one is the most used Git command. After changes are done locally, you can save them by “committing” them.

git commit -m <message of commit>

Push. Git push will push the locally committed changes to the remote branch.

git push

Also, you can use this command to create a pull request (this is the standard when working in a team).

git push origin <name of main repo> <name of branch>

Pull. Using git pull will fetch all the changes from the remote repository and merge any remote changes in the current local branch.

git pull

Stash. This is a very useful command. It allows you to save our changes without creating commits. This option is good when we want to switch to another branch but the current changes are not ready to make a commit. Of course, we could make a commit, but it would contain unfinished work and would not carry much meaning, and in addition, it would pollute our repository.

To save our changes to stash, use the command:

git stash

To view the list of saved changes, use the command:

git stash list

To return the changes from stash, run the command:

git stash apply

Important. By default, the latest changes from the list are applied, and to select a specific one, you must specify the index:

git stash apply --index 0

Cherry-pick. This command allows you to insert the commit you selected (and of course its changes) into the current branch. This is useful when we want to move specific changes from another branch, but don’t want to merge them completely.

Let’s look at an example. There are two branches, main and release, with a commit history.

Main branches:

commit fe19efc1d7a34ddb6193b1e4f859dd9e1a5d7049 (HEAD -> main)
some changes for release

commit 15471b35d338f8dbcbc43ba1531ad1c5447696f7
example cherry-pick commit
commit dfa5218fa6e2bd8a8752eca225c2bd86380724b3
Initial new commit

Release branches:

commit 9fa72be55c083f879ef5a73c2b4350b4056411e8 (HEAD -> release)
Initial new commit

We need to get the commit changes with the message “example cherry-pick commit”. But at the same time, you do not need to commit “some changes for release” in the release branch. To do this, we need to make a cherry-pick of the commit we need. To select the desired commit, you need to use its hash:

git cherry-pick 15471b35d338f8dbcbc43ba1531ad1c5447696f7

Now we can see the necessary changes in the release branch:

commit e6a95034d392d295741a14ab0eaf084258116f5d (HEAD -> release)
    example cherry-pick commit

commit 9fa72be55c083f879ef5a73c2b4350b4056411e8
    Initial commit

Warning! Conflicts may occur during the execution of the git cherry-pick command.

Working in this situation is somewhat similar to working with the git rebase command (which we will discuss below). After all, conflicts are resolved, you can continue with the git cherry-pick — continue command.

After using the git command, cherry-pick remembers the main commit rule. Every commit should be a perfect, atomic unit of change:

Each commit to your repository’s main branch should be exactly the correct size, be it large or small, such that it introduces one atomic unit of change. It should fix one bug, introduce one feature, refactor one system, and do so completely, rather than spreading the change out across several commits.

A proper commit history helps a lot when using the cherry-pick command.

Rebase. For clarity, let’s briefly consider the development cycle of some automation scripts from the point of view of Git. Automation engineer takes a shared branch (usually called dev) as a basis, creates a new branch, makes its own changes to it, and then creates a merge/pull request to pour its changes into the shared branch. I advise you to do rebase before creating a merge/pull request of your branch to the general one. All this is done to resolve potential conflicts and keep the history in the repository clean. A clean and clear history makes it much easier to potentially manipulate the repository in the future. So, why do anything at all before creating a merge/pull request? The main goal for merging your branch with a shared one before creating it is to resolve possible conflicts. I bet every developer has ever seen a message like “There merge conflicts” or “Cannot merge automatically”. Therefore, we have a choice: merge and rebase. Of course, rebase is not always appropriate, but it is worth choosing it in this situation.

Let’s say we need to implement a new automation script. To begin with, we switch to the shared branch (in our example, dev) and do a pull to pull up the latest updates:

git checkout dev
git pull origin dev

Creating a feature branch from a dev for local development:

git checkout -b feature

Imagine that we implemented a new automation script and made a new commit:

git add .
git commit -m “implemented a new automation script”

Since a lot of developers and automation engineers are working on our repository, while we were implementing a new automation script, there were changes in the general branch that may cause a conflict with our functionality or somehow affect it. Therefore, we must prevent possible conflicts:

git pull --rebase origin dev

Then we have to resolve those very conflicts (if they are present) and then continue:

git rebase --continue

Note: rebase overwrites your created commit, the hashes of the old and new commits are different.

And now you can safely create our merge/pull request and not worry about conflicts.

git push --force origin feature-branch

or

git push --force-with-lease origin feature-branch

The — force option for git push the commit history on the remote will be forcefully overwritten with your own local history.

The — force-with-lease is a safer option that will not overwrite any work on the remote branch if more commits were added to the remote branch (by another team member or coworker or what have you). It ensures you do not overwrite someone else’s work by force pushing.

Reset & revert. Let’s say we want to add changes to a previous commit. To do this, we need the reset command with the — soft or — mixed parameter (mixed is used by default if parameters are specified).

git reset --soft HEAD~1

Writing HEAD~1 means that we want to go one commit back from the current HEAD position. To see what happened, you can use git log and git status. The commit list will no longer contain the commit that we deleted, and the changes to this commit will remain in the working directory with the status of the stage. Then you can add/fix these changes and make a new commit. If we just want to delete a commit and its changes should be reset with the — hard parameter, it will delete the commit and their changes will not remain in our working directory. Also, to change the last commit in Git, there is a — amend parameter for the commit command, but I like to use reset more for some reason.

It is worth noting that the approaches described above change the history of commits in the repository, which is not always safe. In shared branches, which are usually named as master, dev, or main, it is not customary to make changes to the commit history, as this can have negative consequences.

Conclusion.

Git can be a really powerful tool in any project and you will probably use most of these commands daily if your team uses Git for version control.

Today, knowledge of git is a critical skill in the work of a tester. For those who switch to automation — this is the first step from which you should start studying. For the experienced, the SDET is a Swiss knife. However, it is almost impossible to remember all the commands, so I found an interactive cheat sheet:

https://gitexplorer.com/

https://test-engineer.site/

Author Anton Smirnov