- Setting up private Git servers on Windows using Git Daemon and virtual networks like Hamachi.
- Implementation of professional workflows by separating the production (master) branch from the development branches.
- Secure authentication management using SSH keys and Personal Access Tokens (PAT) for remote environments.
- Adjusting global parameters in Git to avoid line break conflicts between Windows and Unix operating systems.
I'm sure it's happened to you: you have a couple of computers at home or in the office and you want your code to be synchronized without necessarily relying on external cloud services. Although everyone uses GitHub these days, there are situations where you prefer to set up your own private Git server to have complete control over your files and not let third parties store your intellectual property.
Setting this up on Windows can seem like a headache, especially when you run into network walls or connection errors that don't make sense. But don't worry, we're going to break down step by step how to connect your machines, whether using virtual networks like Hamachi , cloud-based Linux servers, or the classic SSH setup, so that everything runs smoothly.
Setting up your own Git server on Windows with a virtual network
If you have two Windows 11 PCs and want the first one to act as a server, the quickest way when they're not on the same local network is to use Hamachi. For this to work, you first need to install Git and Hamachi on both machines. The trick here is not to try pushing to a regular folder, but to configure a non-bare repository or use the Git Daemon tool.
To get started, create a folder for your project (for example, C:\Repos\Test.git) and run git initIt is essential to add at least one file, such as a .gitignore, to do the git add . and issue the first commit. To allow the other computer to connect, you must activate the server with the command git daemon --export-all --base-path=. --reuseaddr --verboseOn the client side, to avoid permission issues, it is recommended to run git config --global sendpack.sideband false before launching the cloned using the IP by Hamachi.
Branch management and professional workflow
A very common mistake when starting out is pushing all changes directly to the master branch. This isn't recommended, as the master branch should be your production environment —that is, where only working code ready for deployment resides. Ideally, you should create a branch called default or develop to handle the heavy lifting.
The logical workflow would be to make your commits on the subbranch, push the changes, and save all the changes to Git before, once you've verified that everything is working correctly, performing a merge to master . This way, you maintain a clean history and prevent a silly mistake from breaking the stable version of your application.
Advanced alternatives: Cloud servers and protocols
If you're looking for something more robust than a home PC, setting up a Linux server (Ubuntu or CentOS) is the winning option. Here you can install Git using apt-get install git o yum install git-coreIn these environments, the key protocol is SSH (Secure Shell)because it offers powerful encryption and allows access management without exposing passwords in plain text.
To migrate a local project to a remote server of this type, the cleanest approach is to create a "bare" copy (without working files, only the Git database) using git clone --bare and then upload it to the server using the command scpThis turns your server into a central synchronization node where all developers on the team can pull and push.
Essential Git environment configuration
Before you start throwing commands around haphazardly, you need to set up your environment properly. Git needs to know who you are to sign commits; if you don't configure it... user.name y user.emailThe system will give you errors or assign generic names. You can apply these changes globally to affect all your projects or locally if you want to use different identities depending on the repository.
Another critical point in Windows is the handling of line breaks. Windows uses CR+LF, while Linux and macOS use only LF. To prevent Git from marking files as modified based solely on formatting, you must run git config --global core.autocrlf true on Windows. You can also customize your default text editor (such as Visual Studio Code or Sublime Text) to make rebasing or message editing operations much more convenient.
Connecting to GitHub: SSH vs PAT Tokens
If you ultimately decide to use GitHub, you have two ways to authenticate. The first is SSH, which involves generating a key pair (public and private). The public key is uploaded to GitHub, and the private key remains on your computer. This is the most convenient option because it eliminates the need to type your password with each push, provided you have the ssh-agent running.
The second option is Personal Access Tokens (PATs). These are ideal if you work with many different machines or in continuous integration environments. When you generate a token in your GitHub developer settings, it acts as a temporary password with specific permissions , adding an extra layer of security since you can revoke the token at any time without changing your main password.
Mastering remotes and conflict resolution
Managing multiple remote servers is easy if you understand the command git remote addBy default, the main server is called "origin", but you can add as many remotes as you want. If you make a mistake in the URL or change protocols (from HTTPS to SSH, for example), you don't need to delete the remote; just use git remote set-url origin .
If you ever find that the remote already exists, you can rename it with git remote rename or eliminate it completely with git remote rm. Remember Removing the remote connection does not erase the data On the server, it simply breaks the link between your local folder and the external server, allowing you to reconnect to a different destination without losing your commit history.
Mastering repository interconnection involves understanding everything from basic identity configuration and line breaks to deploying private servers using Git Daemon on virtual networks and securing SSH keys in the cloud. Whether you opt for a local workflow with Hamachi or a professional infrastructure on GitHub, the key lies in properly managing branches to protect the stable version and using appropriate authentication protocols to ensure code security.
