Git has won the race for the most popular version control system. But why exactly is it so popular? The answer, at least in my opinion, is pretty clear: branches! They allow you to keep different versions of your code cleanly separated—ideal when collaborating in a team with other people, but also for yourself when you begin working on a new feature.

Although other version control systems also offer some form of branching, Git’s concept and implementation are just stunning. It has made working with branches so quick and easy that many developers have adopted the concept for their daily work. //

Unlike their short-lived colleagues, long-running branches typically remain in a project during its complete lifetime. These branches are not tied to specific features or topics. Instead, they represent states or stages in a project:

• the typical “main” branch for the project’s mainline or production code
• often also a “develop” branch where different short-lived branches are integrated
• sometimes also branches like “staging” or “production” that represent certain stages or environments

Along with this distinction between short-lived and long-running branches, there’s also often a golden rule: never directly commit on a long-running branch; code should only land on these branches through deliberate integration (via merge or rebase).

Gitea - Git with a cup of tea
A painless self-hosted Git service.
Gitea is a community managed lightweight code hosting solution written in Go. It is published under the MIT license.

Linus Torvalds will pull Paragon Software's NTFS driver into the 5.15 kernel source – but he complained about the use of a GitHub merge in the submission, saying that GitHub "creates absolutely useless garbage merges." //

First, he said the pull request should have been signed. "In a perfect world, it would be a PGP signature that I can trace directly to you through the chain of trust, but I've never actually required that," he said.

Second, he noted that the code in the pull request included merge commits done with the GitHub web user interface. "That's another of those things that I really don't want to see – github creates absolutely useless garbage merges, and you should never ever use the github interfaces to merge anything," he said.

He added: "[G]ithub is a perfectly fine hosting site, and it does a number of other things well too, but merges is not one of those things."

Torvalds has complained about aspects of GitHub before, saying in 2012: "I don't do github pull requests. github throws away all the relevant information, like having even a valid email address for the person asking me to pull. The diffstat is also deficient and useless."

Note that the git request-pull command is different from the GitHub pull request feature. The ensuing forthright thread has more information on the subject.

In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.

The purpose of this post is to detail how to setup Git within the Windows Subsystem for Linux (WSL). Git is the source control tool of choice nowadays. It’s distributed style makes it great for working with a remote team but also allows you to work completely offline, which wasn’t an option for previous tools like Subversion or CVS.

This post focuses on setting up Git for command line access and scripting on Windows. There are other options like Git BASH, which I have used in the past, but why settle for a “BASH emulation” when you can use the real thing?

The simple way is:

git remote set-url origin [updated link url https://........git]

Alternatively, if you like the long way it is:

git remote rm origin
git remote add origin [updated link]

The root of your monorepo should have very little in it – A README, some useful scripts for managing workflows maybe, etc. It certainly shouldn’t have a “src” directory or whatever the local equivalent where you put your code is.

But given this distinction, I think almost everyone will benefit from organising their code this way.

For me the single biggest advantages of this sort of organisation style are:

1. It is impossible for your code to get out of sync with itself.
2. Any change can be considered and reviewed as a single atomic unit.
3. Refactoring to modularity becomes cheap.

Create a New SSH Key Pair

Open a terminal and run the following command:

ssh-keygen 

SSH config, which is a per-user configuration file for SSH communication. Create a new file: ~/.ssh/config and open it for editing:

nano ~/.ssh/config

Managing Custom Named SSH key

The first thing we are going to solve using this config file is to avoid having to add custom-named SSH keys using ssh-add. Assuming your private SSH key is named ~/.ssh/id_rsa, add following to the config file:

Host github
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

Now you can use git clone git@github:username/project

Although Git is a very powerful tool, I think most people would agree when I say it can also be... a total nightmare 😐 I've always found it very useful to visualize in my head what's happening when working with Git: how are the branches interacting when I perform a certain command, and how will it affect the history? Why did my coworker cry when I did a hard reset on master, force pushed to origin and rimraf'd the .git folder?