Updated remote repositories

This commit is contained in:
Kenneth John Odle 2024-07-05 16:36:18 -04:00
parent 537218ad1a
commit d54f6e20f8
4 changed files with 43 additions and 3 deletions

View File

@ -456,15 +456,23 @@ If we're happy with the files we've staged, we can now commit them by using \tex
\section{Branches} \section{Branches}
If you want to experiment, the best way to do that is to create a \textit{branch}. To do that, just use \texttt{git branch <name>}. To move to that branch, you check it out\footnote{For a visual depiction, see, \kref{https://www.youtube.com/watch?v=8qxDBiiVjlQ}{https://www.youtube.com/watch?v=8qxDBiiVjlQ}.} using \texttt{git branch checkout <name>}. If you want to experiment, the best way to do that is to create a \textit{branch}. To do that, just use \texttt{git branch <name>}. To move to that branch, you check it out\footnote{For a visual depiction, see, \kref{https://www.youtube.com/watch?v=8qxDBiiVjlQ}{https://www.youtube.com/watch?v=8qxDBiiVjlQ}.} using \texttt{git branch checkout <branchname>}.
Of course, there's a shortcut to this. We can use Of course, there's a shortcut to this. We can use
\input{include/checkout} \input{include/checkout}
which creates a branch called <name> and moves us to it automatically. which creates a branch called <branchname> and moves us to it automatically.
This is the point where we experiment and have fun on this branch without worrying about our main branch. Wouldn't it be nice if life were like this?\footnote{Gosh, I've mentioned this twice. There are lots of science fiction stories about this possibility. I guess it's time to go read one.}
If we like the changes that we made on this branch, we can then go back to our main branch (\texttt{git checkout main}) and \textit{merge} those changes.
\input{include/merge}
It's always a good idea to clean up after ourselves. If we don't need that experimental branch any more, we can delete it with \texttt{git branch -d <branchname>}.
In reality, things are rarely going to be this simply, unless you are only making very basic changes to a branch. You'll likely get all sorts of error messages or warning messages, and will get confused or even scared. Never fear! The nice thing about Git is that most of the solutions you need are easily found at the other end of a web search.
\section{Remote Repositories} \section{Remote Repositories}
@ -554,6 +562,32 @@ This is one of the nice things about Git: when you clone that remote repository,
For what it's worth, you can have multiple remotes. I can create a remote repository on GitHub, clone it to my local machine, then create a remote somewhere else and add that remote to my local repo. To keep both remotes up to date with local changes, you'll need to push twice, once with \texttt{git push remote1 main} and again with \texttt{git push remote2 main}. For what it's worth, you can have multiple remotes. I can create a remote repository on GitHub, clone it to my local machine, then create a remote somewhere else and add that remote to my local repo. To keep both remotes up to date with local changes, you'll need to push twice, once with \texttt{git push remote1 main} and again with \texttt{git push remote2 main}.
\subsection{Collaborating With Yourself}
I mentioned earlier that you could use Git if you're a writer to keep track of changes to projects, provided you were willing to work with text files. My goal here is to provide at least one workflow for doing that. I'm going to assume a few things here:
\begin{enumerate}[noitemsep]
\item You have a remote somewhere on a repository host (like GitHub or your own website).
\item You write all your stories in plain text files in a local repo.
\item Your repository host allows you to edit files on their website. (I can do this on my own site with Gitea\footnote{\kref{https://gitea.com/}{https://gitea.com/}} but I'm not sure about other.
\end{enumerate}
The advantage to the workflow I'm describing here is that you can do work on your files even if you are not working from your normal machine. Thanks to family medical issues, I sometimes spend a lot of time in hospital waiting rooms and I bring my Chromebook with me. I can edit my files on the web, and then pull down changes to my main laptop (which never leaves my house) when I get home. This is how I do it.
Physically go to your remote location (library, caf\'e, hospital waiting room, etc.) and login to your repository host. Make whatever changes you want online and save your files.
Go home and go into your local repo. Open a terminal in that directory and use the \texttt{git pull} command:
\input{include/pull}
\texttt{git pull} is a combination of two Git commands: \texttt{fetch} and \texttt{merge}. \texttt{git fetch} gets the change history of the tracked remote and branch, whereas \texttt{git merge} combines the current branch with the specified branch. Your local repository will now look like your remote repository. You can write to your heart's content, push those changes, and call it a day. If you're back at the hospital waiting room again some time later, you can just repeat the process.\footnote{Again, for a visual depiction of this, please visit \kref{https://www.youtube.com/watch?v=FG1NrQYXjLU}{https://www.youtube.com/watch?v=FG1NrQYXjLU}.}
\section{Forks and Pull Requests}
These things aren't a part of Git, but they are something that is offered by GitHub and other repository hosts, so I just want to give the briefest of descriptions here for clarity and completion.
To \textit{fork} a remote repository is to make a copy of it so that you can contribute to this project. You fork somebody else's project, clone it locally, make your changes, push those changes to your remote repo, and then make a \textit{pull request}, which alerts the owner of the original repository that you have changes you'd like them to incorporate into their project. They can then pull those changes in, or they can ignore them.
\section{Summary of Git Commands} \section{Summary of Git Commands}
One of my favorite aspects of Git is that it's fairly intuitive to understand and start using right out of the box, but it's also robust enough to meet the needs of large teams and organizations. What I've done in the following table is to summarize the commands I've used in this primer, along with examples where appropriate. I've also included a few commands in this table that you probably won't use unless you are collaborating with others which I haven't discussed because it's outside the range of my experience. But I did want to include them to make the table a little more complete. One of my favorite aspects of Git is that it's fairly intuitive to understand and start using right out of the box, but it's also robust enough to meet the needs of large teams and organizations. What I've done in the following table is to summarize the commands I've used in this primer, along with examples where appropriate. I've also included a few commands in this table that you probably won't use unless you are collaborating with others which I haven't discussed because it's outside the range of my experience. But I did want to include them to make the table a little more complete.

View File

@ -1,3 +1,3 @@
\begin{Verbatim}[] \begin{Verbatim}[]
$ git checkout -b <name> $ git checkout -b <branchname>
\end{Verbatim} \end{Verbatim}

3
005/include/merge.tex Normal file
View File

@ -0,0 +1,3 @@
\begin{Verbatim}[]
$ git merge <branchname>
\end{Verbatim}

3
005/include/pull.tex Normal file
View File

@ -0,0 +1,3 @@
\begin{Verbatim}[]
$ git pull <remoterepo> <remotebranch>
\end{Verbatim}