Starting out with Git: How to use Git on Windows (TortoiseGit tutorial)
Git merge conflicts using Tortoise Git merge in Windows
Today we wanted to use Tortoise Git Merge, a Windows Git utility which comes with Tortoise Git. It helps us do a 3 way merge and solve our conflicts easily. The advantage of it is that it automatically merges the lines that where uniquely modified in every file and you only need to merge the common changes where the conflicts are. So in our case we had a file. let’s call it README.md. in which we had 1000 changed lines out of which only 2 had a conflict with the file pulled from upstream server. Eclipse and IntelliJ do provide a merge editor but as far as we are concerned they are not automatically merging your unique changes (please correct us if we are wrong). After some searching on the web of how to do so, we found StackOverflow Question 5190188 : Why can’t I use TortoiseMerge as my git merge tool on Windows? which explains different approaches.
So according to the aforementioned question and our experiments, in order to use Tortoise Git Merge you have to download and install Tortoise Git and configure your local.gitconfig file with the following lines:
[core] longpaths = true autocrlf = true [merge] tool=tortoisemerge [mergetool “tortoisemerge”] cmd = \”C:\\Program Files\\TortoiseGit\\bin\\TortoiseGitMerge.exe\”.base:\”BASE\”.theirs:\”LOCAL\”.mine:\”REMOTE\”.merged:\”MERGED\”
If you want an one liner equivalent command, you can run the following:
git config.-global mergetool.tortoisemerge.cmd “\”C:\\Program Files\\TortoiseGit\\bin\\TortoiseGitMerge.exe\”.base:\”BASE\”.theirs:\”LOCAL\”.mine:\”REMOTE\”.merged:\”MERGED\””
NOTE: The core section is complimentary for Windows in order to help Git use long paths and overcome Windows 260 character MAX_PATH limitation. Furthermore we need to automatically checkout with file ending using CRLF and push to LF. thus the autocrlf is set to true.
After this short parenthesis, back in action! When you pull from a remote repository, or you merge, or rebase a branch and Git complains about conflicts you can use in your shell or in Git Bash:
Tortoise merge will appear with a display like the following:
In this image, conflicts are marked with red and the automatically merged lines are marked with yellow. Left side (Theirs) is the version of the file which comes from repository and right side (Mine) is your local version with your changes.
That’s it. We hope this quick guide helped you!
Updated: May 30, 2018
MS SQL Server Docker container restore database from.bak file created in Windows to a New Location
Yesterday, a client which uses Microsoft SQL Server 2008 R2 (SP2) wanted to test if his database backup can work in Microsoft SQL Server 2019 Developer versi.
SQL query to check if a date range is between two dates in Oracle database
A few days ago, we had to select records from an Oracle database table which should be inside a given date range. The difficult thing with those records was.
Go Mongodb Error Cannot create field X in element
Today we had a MongoDB 3.6 collection with the following documents:
Convert from/to JSON decimal fields in Go (golang) structs
Yesterday we had to marshal and umarshal to/from JSON some HTTP requests and responses in a Go microservice we are building. We already use ericlagergren/dec.
Getting Tortoise Git to work with GitHub repositories
In this post I’ll walk you through installing Tortoise Git in a way that allows it to interact easily with GitHub repositories.
Download msysgit
First off download msysgit, a prerequisite for running Tortoise Git. (A the time of writing this was v1.8.3).
For the installation, I mostly accepted all the default options. The only change I made was to allow the system’s PATH environment variable to be updated. This will be required for a latter step.
I also left the default “Checkout Windows-style, commit unix-style endings”, which is equivalent to the git option core.autocrlf being set to true. You probably also want to set this on if you don’t have it set already. GitHub also has an article on their site about file specific options that you might want to include in a.gitattributes file in your repository.
If you have any existing repositories on your system you can now use GitBash to work with them. At the moment each command, however, will require you to type your user name and password.
Download Tortoise Git
Then download Tortoise Git (v1.8.4 at the time of writing). If you have Windows 8 you should go for the 64-bit edition. Again, I just accepted all the default installation options.
As with GitBash in the msysgit installation, once this is set up you’ll be able to work with any existing repositories, and again each operation will require a user name and password to be allowed.
Download the git-credential-winstore
GitHub has an article on how to set up password caching (skip to “password caching” for download link) if you are using tools other than GitHub for Windows. The file requires that the path variable has the git bin folder in it. This will be the case if the option above was made when installing msysgit. I also found that a machine reboot was required before installing this as it didn’t immediately find git in the path after installing msysgit.
The git-credential-winstore install very quickly. It asks one slightly confusingly worded question, “Do you want to install git-credential-winstore to prompt for passwords?”. The correct answer is “yes”. It doesn’t mean that it will always prompt you instead of at the command line or the GUI tool, it will only prompt for a password if it does not know the credentials to use, after that it uses what’s in its credential store so you don’t get asked all the time.
When git-credentials-winstore is installed it will create a [credentials] section in your.gitconfig file which should be at C:\Users\\.gitconfig
Be aware, however, that GitHub does have a nasty habit of removing the [credentials] section of the.gitconfig file. To get around this, copy the credential section to the gitconfig file in the msysgit directory (If you followed the installation defaults it will probably be in C:\Program Files (x86)\Git\etc.) You’ll have to run as administrator in order to edit that gitconfig file due to its location.
If you have multiple users on your machine you may also want to move the installed location of git-credentials-winstore as it installs in your AppData directory. However, I’ve not tried this as I’m the only user on my machine.
You can now use GitBash and Tortoise Git with your GitHub repository.
Git cheatsheet (WindowsTortoise)
TortoiseGit is an Windows Explorer shell extension which you can download to fetch and share changes from the master copy held by ROOL.
The RISC OS sources need to be built on a RISC OS machine. You can use emulator for this, in which case you need to run TortoiseGit in a directory visible to the emulator, but for the rest of this cheatsheet, we assume you will be building on a physical RISC OS machine.
The following examples assumes you are using Windows 7 or later.
Choose the drive or folder you wish to share, right click on it, choose Properties then the Sharing tab, then Advanced Sharing… button. Tick Share this folder give the share a name, and check the Permissions allow full access for your username at least.
- Start OmniClient (installed as !Omni in Apps)
- From the iconbar menu, choose Mounts Protocols LanManFS
- Fill in the following fields:
Name: a name by which the mount will be referred to on RISC OS Server name: the name or IP address of the Windows machine Directory path: the name you chose for the share User name: your username Password: your password
- Click on Connect
- Optionally, from the icon bar menu, choose Mounts Save mounts, so that the mount settings will be available under the Mounts submenu after any reboots
- There’s more information in the chapter OmniClient in the RISC OS 5 User Guide
Get sources to a single component
On the git machine, navigate to the directory where you want your source tree to be stored. Next, choosing the Alarm application as an example, clone it:
You can find the URL to use from the project’s GitLab page by clicking on the Clone button on the Project Details screen. If you don’t have an account on the server, you must choose the HTTPS option.
Getting the latest sources to an entire product to build on RISC OS
On the git machine, navigate to the directory where you want your source tree to be stored. Next, choosing the Risc PC IOMD ROM as an example, clone it:
Then to initialise everything referred to by the product select the Submodule Update… menu entry:
Note that there is a different recommended procedure listed below for fetching the latest version if you have made source code changes locally since you did the clone, or if enough time has passed since you did the clone that someone else might have published changes.
Now, on the RISC OS machine, copy the IOMDHAL.RiscOS directory from your LanManFS mount to a local filing system. The IOMDHAL./git directory ( IOMDHAL/.git on the server) is very large and of no use from within RISC OS, so can be ignored. Make sure the Filer has ‘seen’ the SetPaths application inside your copy of the DDE. then run RiscOS.Apps.!Prepare and follow the instructions. You only need to run !Prepare once for each copy of the source tree: subsequently, you should run RiscOS.Apps.!Builder instead.
Getting the source to a particular version of a build
To get a specific previous release, right click on the IOMDHAL folder you just cloned and select the Switch/Checkout menu entry:
Once the operation completes, click the Update Submodules button, select all the components, then click OK:
Viewing the history of my local source tree
Because git is a distributed version control system, you actually have a complete copy of the repository’s history, including any changes you’ve made locally but not yet shared. It is common to use graphical history viewers on your local machine both for studying the existing code in a faster way than is possible using web viewers, and for checking how your changes will look to others in advance of publishing them.
Tortoise includes a repository browser from where you can read the change logs for a given component, and see what changes were made. Right click on a component (or even at the top level to see the entire product change log) and choose Show log from the menu.
Many other git viewers are available, such as gitg, Fork, Ungit, SmartGit, GitKraken or SourceTree. A handy list can be found on git’s own website. Most IDEs, such as Visual Studio, X-code or Eclipse, come with git viewers built in, so you can do things like view multiple revisions of a file at the same time in different Windows without having to explicitly check them out.
Local setup before you start to make changes
Before you can use git to record any changes locally – even if you never intend to share them – you need to configure git with a valid user name and email address. If you have not done this before, open TortoiseGit Settings and set a user name and contact email:
Remember that if you publish your commits, the email address you specify here will be publicly visible. If you prefer, you have the option of using a unique private commit email address instead – any emails sent to that address won’t be delivered, but GitLab will still know that any commits that specify that address should be associated with your GitLab account.
Recording your changes locally
First, you need to copy your source tree from your build machine back to the machine you run git on (unless were building in an emulator on that machine).
You should store the changes you wish to keep on a branch in each of your local git repositories. In many cases, this will make the process of merging your changes with other people’s much simpler. Use the Create Branch… option:
which also switches to the new branch so any future commits are applied there.
The branch name you choose should be descriptive of the line of development that you are performing, and typically would not need to include anything identifying you as a developer by name. We recommend the use of a CamelCase name for the branch because GitLab will automatically convert that to a string of space-separated words to form a default title for your contribution when you come to submit it to ROOL for review. Please do not use. or _ characters in your branch names, since these have special meanings for the tag names used in our repositories.
The next step is to commit your changes – that is, tell git which of your changed files you want to be recorded in your commit. This is your chance you check that you aren’t bothering your reviewers with irrelevant changes such as temporary debugging lines. Click on Git Commit submodule → ‘mybranchname’ top level menu
Updating your clone with the latest version
You might want to update your cloned repositories simply to obtain newer versions of the sources. However, it is also necessary to update them immediately before you publish a contribution, because it’s your responsibility to accommodate any changes that other people have made since you started your branch. The process is the same either way.
If you have changed any repositories, first make sure you have committed them before proceeding as described in the section above. Once this is done, move back to the super-project, and choose Pull… from the menu:
Once complete, choose the Update Submodules from the dropdown
Работа с Git репозиторием при помощи TortoiseGit ч1
to open the familiar submodule update window. We recommend selecting Init to ensure that if any new submodules have been added centrally you’ll get a copy of that too, but is otherwise harmless.
Having Rebase selected will move (“rebase” in git terminology) any commits on your local branch so that they come after the upstream commits in the git history. Occasionally, git won’t be able to do this rebasing automatically: in such cases it will stop and open the Tortoise rebase dialogue box to help you resolve clashes. If you have more than one local development branch, note that these operations will only automatically rebase the branch that each component was checked out on. It will be your responsibility to rebase any other branches explicitly.
Lastly, don’t forget to copy the sources back to your build machine at the end, if applicable.
Submit changes for review
Once you are ready to share your changes to a component, you do this by raising a GitLab Merge Request as follows.
First, if you don’t yet have a user account on the GitLab server, you need to request one by emailing code@riscosopen.org. Once you have an account you will need to go to your account’s Settings then click on SSH Keys and associate an SSH key with your account.
Then, if you have never submitted a merge request to a given component, you will need two things:
- You need to click on Request Access on the Details screen of the top-level RiscOS Group, and
- You need a personal fork of the component on the GitLab server: also on the Project Details screen, click on Fork. After you’ve done this, you can use the Clone button to grab a copy of the URL of the fork repository for use in the next step.
(You may notice that the repositories are listed under your username in a flat namespace. It is for this reason that we now require every component to have a unique name.)
The first time you wish to submit changes from a particular local clone, select the Push… menu entry:
and fill in the remote branch name (usually the same as your local one), paste in the URL from the above step, then click OK.
Git will helpfully print the URL you need to go to in order to initiate the merge request. Alternatively, navigate to the Repository Branches screen for your fork project on GitLab, and click on Merge request for the branch in question. On the merge request page:
- Since a merge request can consist of multiple commits, you are asked to enter a description of the merge request as a whole.
- Make sure you select ROOL as the assignee, or nobody will know to look at your merge request! Note that you will not be able to assign the merge request until you have been granted access to the project as explained in step 1 above.
- Don’t assign ROOL as a reviewer, leave that and the milestone unset
Although the GitLab interface allows it, please don’t upvote or approve your own work; they’re for the independent reviewers’ use.
If you are asked to make changes during the review process, and your merge request consists of only a single commit, you would typically make your edits then commit as usual with the Amend Last Commit option ticked:
When you have completed this process, you need to push these again and force (i.e. override) the pre-existing branch in your fork project on the GitLab server:
Sign up to add or upvote cons Make informed product decisions
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
What is TortoiseGit?
It is a Git revision control client, implemented as a Windows shell extension and based on TortoiseSVN. It is free software released under the GNU General Public License.
Need advice about which tool to choose? Ask the StackShare community!
United States of America Texas Richardson
United States of America New York New York City
United States of America Texas Richardson
United States of America Texas Richardson
San Francisco, United States
What companies use TortoiseGit?
What tools integrate with TortoiseGit?
Sign up to get full access to all the tool integrations Make informed product decisions
Blog Posts
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over three million people use GitHub to build amazing things together.
Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.
Bitbucket gives teams one place to plan projects, collaborate on code, test and deploy, all with free private Git repositories. Teams choose Bitbucket because it has a superior Jira integration, built-in CI/CD, is free for up to 5 users.
Visibility, access control, workflow and code management for Git environments. Flexibility of collaborating on the same codebase and code reviews using any combination of Perforce and Git workflows and tools without compromise.
Mercurial is dedicated to speed and efficiency with a sane user interface. It is written in Python. Mercurial’s implementation and data structures are designed to be fast. You can generate diffs between revisions, or jump back in time within seconds.
