Git issues from svn perspective

When changing from svn to git/github there are some important features of svn that are no longer (directly) available in git/github. Find below such a list and also suggestions how to fix the issues:

1. Files cannot be locked in git/github (-> use git-lfs)
   When making a large restructuring of a repository or when accessing binary files (such as a Word document), it is standard in svn to lock the corresponding files or directories beforehand. As a result, when making "update", users get read-only versions of the file (so they notice that they cannot modify the file until the lock is released). Since git is a distributed version management system, there is no "lock" feature, because there is no central repository. Also github does not support this as an addon.
   This can be fixed by using git-lfs (git Large File System), see below.

2. Binary files cannot be practically handled in git (-> use git-lfs)
   Git is a distributed version control system. Therefore, a user has a local copy of a complete repository, including all branches and the whole history. When storing a binary file, such as a Word document, git cannot compress much, and therefore every commit basically stores another copy of the binary file. This is essentially the same situation as with Subversion (try to avoid binary files, i.e. use Markup-documents in .md format instead of Word-docx files for simple meeting protocols, which GitHub can show and format directly) If binary files are large, the local memory consumption and the "push"-time can become excessive.
   This can be fixed by using git-lfs (git Large File System), see below.

3. Holding several branches in the file system (-> use download ZIP or svn checkout)
   Sometimes one has to merge branches manually together. In svn it is usual in this case to "checkout" or "export" the different branches into different locations of the file system, and then perform the merge. In git, only one local copy of one of the branches is available in the file system (selected via "Switch ..."). If two local copies of different branches are needed in the file system, one simple way is to click on the "Clone or download" button in github, select "Download ZIP", and store the current version of the seleted branch on the desired location in the file system.
   If this feature is needed more often, it might be simpler to use the svn checkout feature of github: Select the URL from the github "Clone or download" button and make "checkout" with this URL for your svn client. As a result, the selected branch is stored in the desired location and standard commit and update functions of svn can be used to synchronize with the repository in github.

As mentioned above, git-lfs solves the problem of large files, especially of binary files in github. Basically, git-lfs turns git from a distributed version management system to a version management system with central repositories for selected file types. This means that for the selected file types, the files are physically stored in one location (for example in github) and in the working copy (selected via "Switch ..."), but not in the local repository of the user (containing all branches and history). In the latter case, only the path names of the files are stored, but not the files itself. Since there is now a central repository again (for the selected file types), it is also possible to lock these files, as in svn. A good description and tutorial of git-lfs is here. So, to summarize, think of git-lfs as svn for selected file types.

Git-lfs is a separate software that is used on a command line. Starting with version 2.13.0, it is included in Git for Windows, so does not need to be installed separately. It might not yet be supported by all GUI clients for git (e.g. it is not yet supported by TortoiseGit). It is, however, supported by Sourcetree.