most people think git = github

Or just put the repo in a shared directory in a high-trust group of developers (or just yourself).

Filesystems and folders are foreign and elusive concepts to gen Z.

https://www.theverge.com/22684730/students-file-folder-direc...

Also relatively unknown: You can clone from a directory. It won't accomplish the backup feature but it's another option/feature.

I didn’t know either - or rather, I had never stopped to consider what a server needs to do to expose a git repo.

But more importantly, I’m not sure why I would want to deploy something by pushing changes to the server. In my mental model the repo contains the SOT, and whatever’s running on the server is ephemeral, so I don’t want to mix those two things.

I guess it’s more comfortable than scp-ing individual files for a hotfix, but how does this beat pushing to the SOT, sshing into the server and pulling changes from there?

My way used to be in the past, put bare repos on Dropbox, clone the bare repo to a real path. Done.

That way, I

1. didn't have to worry about sync conflicts. Once complete, just push to origin 2. had my code backed up outside my computer

I can't exactly remember, if it saves space. I assumed it does, but not sure anymore. But I feel it was quite reliable.

I gave that way up with GitHub. But thinking of migrating to `Codeberg`

With `tailscale`, I feel we have so much options now, instead of putting our personal computer out on the Internet.

What are some fun/creative ways to do GitHub/GitLab style CI/CD with this method? Some kind of entry point script on push that determines what to do next? How could you decide some kind of variables like what the push was for?

am using gitea. but thinking of switching to serve (charm).

Could also consider running a Tangled knot (lightweight, headless git servers): https://tangled.org

Forgejo is working okay for me.

Hard to justify using SSH for Git. Principle of least power and all that

One of my favorite tools available for Linux is called gitolite. It's in the Debian repo.

https://gitolite.com/gitolite/

If you think the bare bones example is interesting and want something simple just for you or a small group of people, this is one step up. There's no web interface. The admin is a git repository that stores ssh public keys and a config file that defines repo names with an ACL. When you push, it updates the authorization and inits new repositories that you name.

I put everything in repos at home and a have multiple systems (because of VMs) so this cleaned things up for me considerably.

I feel like this is a bug that Xcode should fix

> This is a great way to [...] work on server-side files without laggy typing or manual copying

This is the usecase mentioned in the article and it wouldn't work with a bare repo. But if the server your SSH'ing to is just a central point to sync code across machines, then you're right: multiple hoops mentioned in the article are solved by having the central repo bare.

A repo is as database containing a tree of commits. Then you got the concept of branch, which points to a specific commit. Then there's the special pointer HEAD which is the latest commit for the current worktree.

When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit). When you do operation like commit, reset, reset,... both the head and the branch are updated. So if a remote node tries to update the local node via a push on its end, that would mess up the local worktree. So you create a bare repo instead which can't contain a local worktree.

Note: A worktree is computed from the initial commit to the commit currently identified by HEAD by following the parent information on each commit.

The staging area is like a stored snapshot of what you would like to commit. You can always create patch between HEAD and the worktree, edit it, and then save the patch as the commit, then apply the leftover to the worktree. The staging just make that easier. It's a WIP patch for the next commit.

Yeah, I am in the same boat. My files are either non-staged or committed about 99.99% of the time. For me the concept of staging is completely useless

Are basic git concepts like bare repos "obscure tribal knowledge" these days? What do you think ".git" directory is?

The cool thing is that once you know how simple it is to self host (I certainly didn't know before, just used github), you learn a skill that you can apply to many different contexts, and understand better what actually goes on in systems you depend on. That's what these "tech should be invisible" people miss, where they tout you should instead learn using SASS solutions and have zero ownership nor agency, instead of taking the time to learn transferable skills.

> obscure tribal knowledge

The knowledge is neither obscure nor tribal, it is public and accessible. And likely already on your system, in the form of man-pages shipped with your git binaries.

> The problem with software development is that not knowing such "tribal knowledge" is considered incompetence.

Consequently.

> Technology is best when it is invisible

For normal users. Having this tribal knowledge is basically what makes developer and it’s their job to make technology invisible for others. Someone has to be behind the curtain.

> Its because GitHub "Just Works".

IPv6 still doesn't work with GitHub: https://doesgithubhaveipv6yet.com/

People use github because it has a bunch of features outside git and because they don't already have a server.

Not because it's hard or obscure to put git on your server.

> I tried this and it is never as smooth as described.

I think your comment shows some confusion that it's either the result or cause of some negative experiences.

Starting with GitHub. The primary reason it "just works" is because GitHub, like any SaaS offering, is taking care of basic things like managing servers, authorization, access control, etc.

Obviously, if you have to setup your own ssh server, things won't be as streamlined as clicking a button.

But that's obviously not the point of this post.

The point is that the work you need to do to setup a Git server is way less because you already have most of the things already set, and the ones that aren't are actually low-hanging fruit.

This should not come as a surprise. Git was designed as a distributed version control system. Being able to easily setup a stand-alone repository was a design goal. This blog post covers providing access through ssh, but you can also create repositories in any mount point of your file system, including in USB pens.

And, yes, "it just works".

> The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)

I'm sorry, the inability to go through the how-to guide that you cited has nothing to do with Git. The guide only does three things: create a user account, setup ssh access to that account, and create a Git repository. If you fail to create a user account and setup ssh, your problems are not related to Git. If you created a user account and successfully setup ssh access, all that is missing is checking out the repo/adding a remote repo. If you struggle with this step, your issues are not related to Git.