This article is aimed at giving an entry-level tester the overview of the way a product version control system works: from the process of duplicating a repository to the function of creating a pull request.

Even if a user has a good knowledge of Git, this software may still seem a little bit confusing and interesting. It may contain numerous things that are not seen from the first look.

We’ll talk further about 6 tips that simplify working with Git.

Tip 1: constantly run a git status

Many Git clients make the following mistake: they execute a task and commit it, being located in an incorrect branch. You don’t need to be an expert to know how to fix such errors.

For example, you can run a special git status command more frequently. It can be run right after opening a command line and moving to a repository. This is needed to be aware of the branch where you’re located in the future.

Starting a git status is also quite a good way to find out what files have been modified in a certain branch.

Sometimes users change files in order to debug them and then forget to cancel these changes.

[highlight dark=”no”]Starting a git status will help you to verify that the file that shouldn’t have been modified has been already modified.[/highlight]

Tip 2: download a master branch before working in it

Before starting code modification in your branch, you should ensure that it contains the newest and most valid software code. Otherwise, a client can change the code that doesn’t exist or simply duplicate the work of another person.

When you ensure that you have access to the latest software code, you can also protect yourself from the conflict of branch merging when a client branch and a master branch have unsolved differences that can’t be solved by version control software.

After downloading a master branch, don’t forget to switch to your own branch.

[highlight dark=”no”]If a user runs a git status command very frequently, he/she will notice right away if he/she has forgotten to switch to a necessary branch.[/highlight]

Tip 3: add each modified file simultaneously

If a user has modified several files at once, it’s very hard for him/her to type the git add<add a long file’s name> command every time.

A simple method of simultaneous adding all user’s modifications to files is to use the special git add — A command.

[highlight dark=”no”]But you need to be really interested in adding these files before using this method.[/highlight]

Tip 4: every commit should contain a useful name

Adding a commit message is optional while committing files but numerous companies will expect that you add it yourself. Try to make your and others’ lives more simple by marking the commits in such a way that you will be able to understand them in the future.

“Editing one line of software code” is not a good message.

“Adding the test for the end-point of new contact details” will be more informative during the future analysis of the document.

Tip 5: put every git log in one line

It’s very easy to forget what exactly you were doing in Git since it doesn’t contain the interface that may show you this.

So such a thing as a git log can come in handy in this case. The log can completely show a user several last commits, their creators, date, and time of modification.

[highlight dark=”no”]It’s very easy to analyze the logs when they are written in one line.[/highlight] You simply need to type the git log—pretty=online command. And enter q, to exit from a log.

Tip 6: find the difference between user files before executing a pull request

If a client runs a git status command too frequently, he/she is more likely to not commit and push the files that shouldn’t be pushed.

But he/she may accidentally commit the software code that hasn’t been developed for this inside the file that contains necessary changes.

[highlight dark=”no”]This means that you simply need to look at the diff of necessary files before executing a pull request and asking to review software code.[/highlight]

For this, just go to GitHub and compare files in your branch and in a master branch, to see what branches could have been changed.

If a client has pushed something incorrectly, he/she can simply change the file into a valid one, and then simply add it, commit and push it again.

We hope that these tips and recommendations will be quite useful for different testers and developers, of course, that daily interact with Git.