78 lines
5.3 KiB
HTML
78 lines
5.3 KiB
HTML
<!DOCTYPE html>
|
||
<html lang='en'>
|
||
<head>
|
||
<title>gome — git</title>
|
||
<meta charset='utf-8'/>
|
||
<meta name='theme-color' content='#efe5d7'>
|
||
<meta name='viewport' content='width=device-width, initial-scale=1.0, shrink-to-fit=no'/>
|
||
<link rel='icon' type='image/x-icon' href='../favicon.ico'>
|
||
<link rel='stylesheet' type='text/css' href='../css/fonts.css'/>
|
||
<link rel='stylesheet' type='text/css' href='../css/style.css'/>
|
||
</head>
|
||
<body>
|
||
<header id='header'>
|
||
<nav>
|
||
<a href='..'>back to gomepage</a>—<a href='.'>journal</a>
|
||
</nav>
|
||
</header>
|
||
<main>
|
||
<article>
|
||
<h1 id='title'>You don’t need GitHub</i></h1>
|
||
<time datetime='Mon, 24 Apr 2023 23:00:00 CDT'>24 Apr 2023, 11:00 PM</time>
|
||
<p>
|
||
Like most programmers, I use git for version control.
|
||
I’ve been using it since college, where we were introduced to it for working on shared projects as well as a consistent way to turn our code in.
|
||
</p><p>
|
||
There were a lot of things I didn’t get about git when I first started using it.
|
||
If I needed to do anything besides simply add commits to a single branch in a linear fashion and push them to a remote, I got confused quickly.
|
||
I would try to consult a guide or StackOverflow post, typing in commands I didn’t understand and usually I made a mess of things.
|
||
I remember I would end up force-pushing to remote a lot, which I understood was a no-no, but at the time, the repositories I was working with were mine alone, so it didn’t really matter.
|
||
</p><p>
|
||
Now that I’ve used it for work and actually had to contend with things like stashes and branches and remotes over & over again, I feel like I’ve got a more stable handle on git than I used to.
|
||
At the very least, I can do what I need to for work pretty reliably, and I know how to get myself out of the sticky spots well enough.
|
||
</p>
|
||
<img src='img/network.webp' width='355' height='352' class='no-border' />
|
||
<p>
|
||
There’s one really interesting thing about git I didn’t understand until recently.
|
||
When you push to a remote repository, such as those hosted on GitHub, there’s really nothing privileged about it compared to any other repository.
|
||
The only difference is that it’s what’s called a “bare” repository, which means it doesn’t actually keep a working tree (the instantiation of a repo’s files on a given filesystem).
|
||
</p><p>
|
||
The upshot of this is that you can actually push & pull repositories from any machine you can SSH to that has git installed.
|
||
So you don’t need to use a separate hosting service to store your code, especially if you’re mainly pushing it to pull it down onto another machine you have access to.
|
||
</p><p>
|
||
For example, I use git to <a href='update.html'>deploy my website</a>.
|
||
When I wrote that post, I would always push my repository to tildegit, then log into the Ctrl-C server and pull it back down.
|
||
Since learning this little tidbit, I ended up reworking my setup so that when I do a <code>git push</code>, it actually goes to tildegit <i>and</i> the ctrl-c server directly, so no additional pulling is necessary.
|
||
</p><p>
|
||
To make this work, I had to do two things.
|
||
The first was to add an additional url to the <code>origin</code> remote:
|
||
</p><blockquote class='highlight'><code>
|
||
git remote set-url --add --push origin ctrl-c:public_html
|
||
</code></blockquote><p>
|
||
If you use this command, replace <code>ctrl-c:public_html</code> with your own hostname and repo path.
|
||
In my case, I have the <code>ctrl-c</code> hostname configured to connect to the Ctrl-C server in my <code>~/.ssh/config</code> file,
|
||
and <code>public_html</code> is the directory the actual repository resides in, relative to my home directory on the Ctrl-C server.
|
||
</p><p>
|
||
The second thing was to update the config of the repository on the Ctrl-C server:
|
||
</p><blockquote class='highlight'><code>
|
||
git config receive.denycurrentbranch updateInstead
|
||
</code></blockquote><p>
|
||
Above, I mentioned that remote repositories on hosting services are “bare”, that is, they have no working tree.
|
||
If you have a normal repository with a working tree, and you push an update to the branch it currently has checked out, it would normally deny your update.
|
||
When you set this setting, it will update the repository instead.
|
||
</p><p>
|
||
If you use this approach to deploy websites or other files, it’s best to avoid making changes in the remote repository if you can.
|
||
Also, there are more sophisticated ways to do this kind of thing, so don’t take this as expert advice.
|
||
But at the very least, it’s a cool trick that suits my needs for deploying a personal site quite well.
|
||
</p><p>
|
||
Do you use git?
|
||
Do you feel like you grasp it pretty well?
|
||
Have you ever discovered a neat trick that helps your workflow?
|
||
Have you tried managing git repositories in a similar way before?
|
||
Let me know your thoughts at my Ctrl-C email: <code>gome<span style='user-select: none;'> ​</span>@<span style='user-select: none;'> ​</span>ctrl-c.club</code>.
|
||
</p>
|
||
</article>
|
||
</main>
|
||
</body>
|
||
</html>
|