Fortunately, if you’re familiar with the terminology either from some other Git Client, or perhaps from reading the Terminology section from my guide, What is Git ?, then using Tortoise Git to Clone / Commit / Push / Pull is a trivial task.
Hopefully you are already set-up with SSH in tortoise, if not you can follow my guide, Getting Started with Tortoise Git for windows.
Assuming that you HAVE read my guide, or are already familiar with Git terminology, we can cover the essentials. Before going on to some Tortoise specific topics, I’ll be looking at the basics that you need no matter which Git client you’re working with:
Copy your repository from the remote repository.
- Stage, Commit and push
Send your work from your local repository to the remote repository.
If your local repository is out of date due to changes pushed to the remote from somewhere else, grab those changes and merge them in to your local. This is mainly used if you’ve personally been working from several different computers, or if you’re working with team members who have been pushing to the same branch. Always remember to pull before you start working for the day.
Please remember that Tortoise commands are accessed via the right-click menu, and the menu changes depending on whether the folder you’ve clicked in is a Git project or not.
This is only accessible from outside of a Git folder, because we have the assumption that you don’t need to clone if you’re inside a project already. If you have copied your project’s URL from GitLab, right clicking in a folder and selecting clone will reveal to you that your copied address is automatically pasted in to the clone dialogue’s URL section. Hit the OK button and you’ll see your project downloaded below:
Once inside a project’s folder, you will have access to all the other Git commands via the right-click menu.
Stage, Commit and Push
This is only accessible from within a Git folder. Assuming you’ve made changes or added files to your project, you can stage, commit and push them to the remote all in one go. Simply right-click somewhere in your project’s folder, and select Git Commit. Remember that you must add a message before you can commit.
I’m not sure what else there is to be said about this, that’s pretty much it. Request more info if needed…
This is accessed in the same same way as commit. You must be within a project folder when you right-click. But there are two main ways to access this feature. One is via the Git Sync option found when you right-click. The other is explicitly named Pull and is found under the TortoiseGit menu when you right-click. You’ll find it right at the top of that menu.
Now that THAT’S out of the way…
I’m sure you can agree that using Tortoise for your day-to-day work is fairly simple, it’s just the set-up process that’s a pain.
I am happy to give more information about any of this stuff and I may do out of necessity in the future. In the meantime, there are a few more topics I think would be of interest to new-comers. I think it would benefit anyone greatly to look at the TortoiseGit menu and try to guess what each of these options do, do a little googling and figure out how to make the best use of tortoise. The options that I’ve found extremely simple and useful are what I’ll cover below:
Remember that when you commit, you’re required to add a message. The reason is because you’re able to restore your project to the state it was in during any of your previous commits, and the messages help us identify what exactly happened during that commit, and what we’ll be getting if we revert our project to that stage. The Show Log option is also a handy way to review team-member’s work to figure out what changes you may have received when you pull. You can click on commits, and see exactly which files were changed. You can click on those files on an individual basis and save them out if you feel the need. You can also right-click on any file and perform a Diff which will use colours to highlight what has changed between this and the previous version of said file, and exactly what that change was.
If you’ve modified files, be it a text document or an image, or anything, really, and decide you no longer approve of those changes, you can access the tortoise menu from the folder that contains those files and select revert. This will un-do all changes. Note that adding a new file counts as an addition, NOT a modification, so newly added files do not get caught by the revert function.
This is a good task to follow up after a Revert. It is sort-of the opposite of Revert. While Revert will un-do changes made to files, but ignore new files, Clean Up will remove any newly added files, ignoring changes to already-existing files. The default options for this are usually fine.
Sometimes when you commit and push a file from one computer, and then do the same thing to the exact same file from another computer, you can cause a conflict where Git does not know which of your 2 changes you want to keep. The ultimate way to avoid this catastrophe is to always Pull before you work, to make sure you have the latest data, or to never work simultaneously on the same file on two separate machines. However, sometimes it happens. The resolve dialogue will reveal any files that are currently undergoing a conflict. You can then right-click on any file found in the list, and decide to keep changes by using YOUR change (meaning the one on the current machine you’re working on), or to use THEIR changes (the changes from the other machine). Conflicts should be rare, and as such, I don’t currently have an example to show you. When there are conflicts, your current branch will go in to a MERGING state, and will require you to resolve said conflicts before any other Git operations can be performed. Once all conflicts are resolved, a commit is required.
That’s all for now. Feel free to ask for more info if you need it.