Using Git (any Version Control System) as tester

I had discussions about different usages of Git with some developers a while ago.
While it looks to me that most developers have a comparable simple a workflow/approach to Git, and therefore often are happy with the CLI commands, I could not stay with that nor a single tool.

The less important point is that i can not remember all the commands, maybe also because I use them less frequently, and therefor use a UI client (Sourcetree) for all my “developer-like” work. Switching branches, commits, rebase, etc.

The strong point is me as tester doing demanding investigations (!) in Git and not every tool offers the same search and view capabilites.
I can do some basic things in Sourctree, while it lacks others which I do with TortoiseGit:

  • having the history of just one directory
  • seeing the history of a single branch without needing to switch to it.

Also I prefer the already existing visualization of any UI client over the, by default not shown (and needs multiple parameters), one of the CLI.

On of my coworker said that he considers all this clients to be bad because I can not do my job with a single one.
I was not sure if he fully understood my perspective.
I think that a git repo is a complex data structure where the client influence how/what you see of that structure. And beint to able to see specific sub-structures / the data by a specific perspective, needs a specific implementation.

What do you think about this?
How do you us any Version Control System repository for investigations?

  1. I suggest anyone new to git use SourceTree (Free windows client). But that they try to move over to the commandline gradually after a year of using git. Because. You cannot use the GUI in a jenkins/teamcity/maven script, so get over it and “git gud” at using scripts to do stuff. TortoiseSNV, is good also but SourceTree is friendlier, and all you want initially is a friendly gentle mode, until you can get sued to cli

  2. Most of the workflows will be very short simple ones, that has been my experience also. Thus, write them up on a wiki page, and gradually memorize them all.

  3. Stash (a git web server front-end) is a thing of beauty, simple, and you have to have a code review tool anyway for whatever database or stack you do use, alternatives for not-git version control do exist.

Get comfortable with one tool that suites your personal common tasks, tool “quality” discussions are just bikeshedding (Law of triviality - Wikipedia), and rarely inform a disciple.


I think how you view or administer GIT shouldn’t be a problem. GUI or command line, you are still doing the same actions.

Unless your are doing automation or a developer you might not have much exposure to command line which is why tools mentioned above to make it easier exists out in the marketplace. I do think it is important to have a basic understanding of what it is and how it operates but like Devs when they get stuck they ask StackOverflow, if you need to use CLI and you don’t know the command you can always google, no harm done.


Where possible I like to use built-in tools of plug-in options in my IDE, with IntelliJ or VSCode.

Beyond that, I use Git commands, but I don’t pretend to remember them, I Google for what I want or use cheat sheets and manuals.


I try to avoid getting too locked into particular tools and workflows, and tend to rely upon learning base implementations (i.e. the command line for git), specifically to avoid the issues OP raises.

Getting tied to a specific feature or implementation can be problematic, and I’ve found that being a bit more pliable/open to alternatives has helped with my career (i.e. I’ve seen folks lose out on positions because they weren’t willing to switch from MacOS to Windows, learn a new DVCS, etc)

More generally, learn the high level concepts of the tech and the problem space, figure out what it takes to do 90% of the workflow . . . the other 10%/power user stuff can be great, but don’t get overly attached to it.

1 Like

In general I think I could not make my intentions clear as I see many answers related to something I call the “developing approach” to Git. :neutral_face:

The developing approach means to make changes at the repo. Adding and changing files…
This is what I not want to concentrate on.

I talking about tasks, not roles. Any tester commiting a file change is, in my general understanding, developing something. Contribution changes to the repo. Maybe about automation.

The other approach is about testing, maybe better investigating.
Looking into the history of the repo for different reasons. E.g. looking for when changes where introduced or what differences.
Basically you just checkout different branches and look at the history.
No commit, no rebase etc.

By my experience different tools offer different possibilities for investigating.
You can not do everything in every tool.

Aside that I’m not very used to the CLI and this maybe could to it … I would hate to remember all the commands and parameter options to do so. How and what I search varies very often.

I understand that the CLI is sufficient for developling, I see at my coworkers.

For investigating I would try to find a different tool if my commonly used tool is not available.
If there is none I would try the CLI …
As long as I have a tool I would use it.

I’m open to all new things. I have wide rang of technologies under my belt :slight_smile: e.g. I have already worked with Windows, Linuxs and Mac.

I hope I could bring it over to you why I sometimes see the need to use a specific tool. For which I surely had to look for alternatives.
I have no fixation on my tools.
I don’t want to leave opportunities out to have easier ways to do my actual work. :slight_smile: