This is a short list!

• Git Winch is totally file-agnostic. What this means is that the office is free to use any file they choose. We do NOT lock you into any files.

• We do NOT make offices transmit files through our server. This is a huge deal, if you think of it. There are many office systems that allows you to attach files and then send those files to others. For e.g. Slack or Microsoft Teams. This is actually a serious headache, which needs a deeper explanation. Read about the "V-Four" problem here.

• Git Winch will keep other members working on the files in a repository informed about which files they are working. It prevents the same file being worked-upon, thus it is useful for working on binary files as there would be very little chance of merge errors.

• Members can leave additional notes on each and every file, if they so want – such meta-information about files can be very useful to help others working on those files.

• The managers of such members are also happy as they can see the list of filenames that are being currently worked upon… and by whom. They also can do what we call a hashtag analysis… That's explained here.

• The coordination server of Git Winch does not have access to ANY of the office files. Only the file-paths are kept for coordinating the work and reducing chances of clash. The owner/manager creates his/her own repository at one of the compatible Git Hosts: Github or Gitlab or Gitea … As both Gitlab and Gitea allows self-hosting too, this gives you the maximum flexibility on where the central repositories of the office are to be located.

• The office workers need not have any account at the Git Host. Only the owner takes such an account. Hence the membership system of Github/Gitea/Gitlab is not used at all. So regular office workers need not have any knowledge about the host. This also becomes very useful if you plan to delegate work to temporary workers too.

• The system allows owners/managers to distribute work to the office-workers on a need-to-know basis. So office workers need not become member of each and every repository of the office. All that membership is in the hands of the owners/managers.

• The owner/manager creates deploy-keys and then passes on the private key to the appropriate member who is allowed to work on the files of a repository. But if a person wants to generate his/her own keys; that also can be done. In that case, after creating the keys, the said member has to pass on the public key to the owner/manager who will then use that key to enroll the person as a member of the said repository.

• Owner/manager can download session logs and can see the IP address and geo-location of each members, their login and logout, and file-handling actions. This is very useful for attendance, and the amount of work each member is contributing.

• Owner/Manager can even set into motion automatic “build” activities once a repository is pushed. Kind of a simple, yet elegant continuous integration.

• The Git Winch Client Application is partially open-source. A bulk of the actual work is done using windows batch files called silently by the application. You are reassured that nothing from the computer where Git Winch is working, is surreptitiously routed to us! If you want more checks; email us at admin@gitwinch.com and we'll show you how to use Fiddler to examine the http connections that the application makes.

• If by some chance you need to do some advanced Git commands, you can easily drop into a console window, and carry out the actions using command-line Git. You can also use TortoiseGit if you so choose, provided the repository was cloned using the Git Winch Client Application

Learn the concepts | Table of Contents