Skip to content

Commit

Permalink
updates
Browse files Browse the repository at this point in the history
  • Loading branch information
@grrrwaaa
grrrwaaa committed May 20, 2024
1 parent e1c82a1 commit 6028527
Show file tree
Hide file tree
Showing 2 changed files with 571 additions and 0 deletions.
273 changes: 273 additions & 0 deletions git.html
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,273 @@
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Logs</title>
<meta name="description" content="">
<meta name="author" content="Graham Wakefield">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<link rel="stylesheet" href="css/basic.css" type="text/css" />
<link rel="stylesheet" href="css/github.css" type="text/css" />
<style>
td {
vertical-align: top;
}

img {
max-height: 75vh;
}

header {
background-color:#f5f5f5;
font-size: 75%;
padding: 0.5em;
}
footer {
background-color:#f5f5f5;
font-size: 75%;
padding: 0.5em;
}
.responsive-google-slides {
position: relative;
padding-bottom: 60%; /* 16:9 Ratio = 56.25%, 4:3 ratio = 75% */
height: 0;
overflow: hidden;
}
.responsive-google-slides iframe {
border: 0;
position: absolute;
top: 0;
left: 0;
width: 100% !important;
height: 100% !important;
}
</style>
<script src="https://unpkg.com/@stackblitz/sdk/bundles/sdk.umd.js"></script>
</head>
<body class="centremaxwidth960">
<header><a href="index.html">DATT4520 & DIGM5520: Generative Art in Mixed Reality / Spatial Computing in Responsive Environments</a></header>
<ul>
<li><a href="#working-with-git-and-github">Working with Git and Github</a><ul>
<li><a href="#installing-git">Installing Git</a></li>
<li><a href="#clone-a-repo">Clone a repo</a></li>
<li><a href="#committing-a-change">Committing a change</a></li>
<li><a href="#synchronizing-with-the-remote-repo">Synchronizing with the remote repo</a></li>
<li><a href="#working-with-branches">Working with branches</a></li>
<li><a href="#forks">Forks</a></li>
<li><a href="#resolving-conflicts">Resolving conflicts</a></li>
</ul>
</li>
</ul>

<h1 id="working-with-git-and-github">Working with Git and Github</h1>
<ul>
<li>See <a href="https://www.w3schools.com/git/">https://www.w3schools.com/git/</a></li>
<li><a href="https://www.w3schools.com/git/git_intro.asp?remote=github">https://www.w3schools.com/git/git_intro.asp?remote=github</a> </li>
</ul>
<blockquote>
<p>Git is a version control system.
Git helps you keep track of code changes.
Git is used to collaborate on code.</p>
</blockquote>
<p>Version control systems like <code>git</code> emerged from the problem of how to let a lot of people work on one code base at once, without ever losing anybody&#39;s work or breaking the project etc. </p>
<p>There are two ways to interact with <code>git</code> -- either using a command line terminal (including the one built into the VS Code editor), or using a visual app (like the Github app). I strongly recommend learning to use the command line version, partly because it works everywhere, and partly because sometimes the the Github app gets stuck and you have to go to the command line to fix it anyway. </p>
<p>The basic idea: </p>
<ul>
<li>you have a <strong>repository</strong> (or <em>repo</em> for short) representing your project and all the code in it. </li>
<li>The repo looks like a regular folder structure on disk, but it is actually a database that stores the entire history of the project inside it -- so you can at any time roll back to an earlier version (an earlier <strong>commit</strong>). That&#39;s why it is called &quot;version control&quot;. </li>
<li>Git repos can also contain multiple <strong>branches</strong>, rather like parallel timelines of history. You can branch a repo from any point in its history, commit changes to this branch to create a new timeline history on this branch, and then later <strong>merge</strong> the branch back to re-integrate it with the other history. </li>
<li>You can <strong>clone</strong> a <strong>remote</strong> repository from a public URL (like a Github project) to create a local copy of the repo on your machine, then work on this local copy by committing changes to it, which you can then <strong>push</strong> back to the remote repo. You can also <strong>pull</strong> (or <strong>fetch</strong>) changes other people have added to that remote repo, to update your local copy and keep it in sync. </li>
<li>If at any time two people have made changes on a branch that are not compatible with each other, git will flag this as a <strong>conflict</strong> and give you the chance to work out how to resolve it before pushing it back to the remote. All work is kept in the history so no work is lost. </li>
</ul>
<p>Remember, <strong>Git</strong> and <strong>Github</strong> are different things. </p>
<ul>
<li><strong>Git</strong> is the software that lets you perform all of this process. </li>
<li><strong>Github</strong> is a service for hosting remote repos online, managing teams and issue tracking and so on. </li>
</ul>
<h2 id="installing-git">Installing Git</h2>
<p>First, check whether you already have it, by typing this into your terminal console and pressing &#39;enter&#39;:</p>
<p><code>git --version</code></p>
<p>If you get a message back saying that the <code>git</code> command can&#39;t be found, you need to install Git. Follow the instructions here: <a href="https://git-scm.com/book/en/v2/Getting-Started-Installing-Git">https://git-scm.com/book/en/v2/Getting-Started-Installing-Git</a></p>
<p>Before using git you need to configure it with your name &amp; email, so that your code changes are properly identified:</p>
<pre><code class="language-sh">git config --global user.name <span class="hljs-string">&quot;your name here&quot;</span>
git config --global user.email <span class="hljs-string">&quot;[email protected]&quot;</span>
</code></pre>
<h2 id="clone-a-repo">Clone a repo</h2>
<p>First, you need the appropriate address of the repo to clone. On Github this can be found in the green &quot;Code&quot; dropdown button on the main page.
E.g. our project&#39;s Github URL is: <a href="https://github.com/worldmaking/2024-datt4520-digm5520">https://github.com/worldmaking/2024-datt4520-digm5520</a>
The Git URL for this repo is: <a href="https://github.com/worldmaking/2024-datt4520-digm5520.git">https://github.com/worldmaking/2024-datt4520-digm5520.git</a> (notice that it ends with <code>.git</code>)</p>
<p>Then, make sure that you are in the right parent folder in your console/terminal, and then:</p>
<pre><code class="language-sh">git <span class="hljs-built_in">clone</span> --recursive https://github.com/worldmaking/2024-datt4520-digm5520.git
</code></pre>
<p>This will create a local copy of the &quot;main&quot; branch of the repo, which you can now work on locally, making edits as needed. </p>
<p>At this point the usual workflow is to: </p>
<ul>
<li>Make changes to files, up to a point where you are happy they are stable. </li>
<li>Commit changes:<ul>
<li>if this involved adding files or folders, use <code>git add filename</code> for each new file</li>
<li>use <code>git status</code> to verify the list of what has changed</li>
<li>use <code>git commit -am &quot;description of change&quot;</code> to add this to your history</li>
</ul>
</li>
<li>Synchronize with the remote repo:<ul>
<li>use <code>git pull</code> to pull in the latest changes from the remote repository, and handle any conflicts if they happen</li>
<li>after resolving any conflicts, use <code>git push</code> to push your changes to the remote repository</li>
</ul>
</li>
</ul>
<h2 id="committing-a-change">Committing a change</h2>
<p>If you edited a file that was already tracked in the repo, it will already be staged. You can verify this with </p>
<pre><code class="language-sh">git status
</code></pre>
<p>If this command lists any untracked files that should be part of the repo, you need to add them:</p>
<pre><code class="language-sh">git add myfilename
</code></pre>
<p>Again you can <code>git status</code> to verify this has worked. </p>
<p>Now you can commit the change to your local history. A commit requires a descriptive message, typically just a few words, to say what changed:</p>
<pre><code class="language-sh">git commit -a -m <span class="hljs-string">&quot;I fixed problem X&quot;</span>
</code></pre>
<p>Or just</p>
<pre><code class="language-sh">git commit -am <span class="hljs-string">&quot;I fixed problem X&quot;</span>
</code></pre>
<p>The <code>-a</code> part means commit everything staged. The <code>-m</code> part means &quot;here is the message describing this change&quot;. </p>
<p>Now the changes are part of your history, and you have just created a new version. </p>
<h3 id="what-not-to-add">What not to add</h3>
<p><strong>Do not add large files to git repos</strong>: Git is only designed for working with small files, like simple text files. Large media assets should never be in a git repo. We have to find a different solution for managing these if we need them. </p>
<p><strong>DO not add temporary or system files</strong>: Things like _DS_Store files or other normally-hidden files, or temporary files, or locally-generated files (like <code>node_modules</code>) should not be part of the repo. We can tell git to ignore certain paths and file types using the <code>.gitignore</code> file. For example, our project&#39;s <code>.gitignore</code> file currently contains things like the following -- any file with these pathname patterns will be ignored by git:</p>
<pre><code class="language-sh">---

<span class="hljs-comment"># Logs</span>
logs
*.<span class="hljs-built_in">log</span>

---

<span class="hljs-comment"># Dependency directories</span>
node_modules/

---

<span class="hljs-comment"># dotenv environment variable files</span>
.env

---

<span class="hljs-comment"># temp and cache directories</span>
temp/
.temp
.cache
</code></pre>
<h2 id="synchronizing-with-the-remote-repo">Synchronizing with the remote repo</h2>
<p>After committing, the next thing we need to do is make sure we are up to date with the remote repo, because maybe somebody else has been pushing changes since you last did this. <strong>Always pull the latest changes before you push your own.</strong></p>
<p>Get the latest changes with:</p>
<pre><code class="language-sh">git pull
</code></pre>
<p>At this point, usually everything goes well and you get the message that you are <code>up to date</code>. This is the point where git combines your changes with all the other changes that have happened to the repo since you last pulled it. </p>
<p>However, there is a chance that at this point you get a <strong>conflict</strong> -- which means that your changes cannot be combined with somebody else&#39;s changes without losing work. So at this point git will ask you to resolve the conflict before you can do anything else. Follow the instructions that it gives you to do this. </p>
<p>Once any conflicts are resolved, we can then <strong>push</strong> our changes to the remote repo like this:</p>
<pre><code class="language-sh">git push
</code></pre>
<h2 id="working-with-branches">Working with branches</h2>
<p>Branches are a way to store a parallel version history, which we can merge back later if we wish to. </p>
<p>There are two common cases where we want to use branches:</p>
<ul>
<li><p>We want to make sure that the branch we are working on during development is not the same branch that is currently the live server (or the version that people will get when they download the repo). </p>
<ul>
<li>It could be a &quot;main&quot; and &quot;develop&quot; pair, where &quot;main&quot; is what people download, but &quot;develop&quot; is where you do work. </li>
<li>It could be a &quot;live&quot; and &quot;develop&quot; pair, where &quot;live&quot; is what is on the server, whereas &quot;develop&quot; is where you do work. </li>
<li>When the team is happy that the develop branch is stable and ready, you can merge it into the &quot;main&quot; or &quot;live&quot; branch. </li>
</ul>
</li>
<li><p>We want to create a temporary branch to work on a specific &quot;feature&quot; in isolation from other development. This is called a feature-branch workflow. </p>
<ul>
<li>Create a branch locally to start working on the feature. </li>
<li>If you want to work on this feature branch with others, you can push it as a branch on the remote too, so they can check it out. </li>
<li>Once the feature is tested and correct, merge it back to the &quot;develop&quot; branch, and push it. You might also delete the branch if you don&#39;t need it anymore. </li>
</ul>
</li>
</ul>
<p>Here are the important commands</p>
<p>List all branches:</p>
<pre><code class="language-sh">git branch -a
</code></pre>
<p>Switch to a different branch:</p>
<pre><code class="language-sh">git checkout thebranchname
git pull

git checkout develop
git pull

git checkout main
git pull
</code></pre>
<p>When you do this, you&#39;ll see all your local files on disk change to match the state of the branch on the repo. </p>
<p>Now you can make changes on this branch, and use <code>git status</code>, <code>git add</code> and <code>git commit</code> to add and commit files as normal. These commits go to the branch you are now working in. And you can push these changes to the remote branch using <code>git push</code>. </p>
<h3 id="creating-a-new-local-branch">Creating a new local branch</h3>
<p>This is typically what you need to do a feature-branch. First you need a simple name for the branch, e.g. &quot;feature_mything&quot;</p>
<pre><code class="language-sh">git checkout -b feature_mything
</code></pre>
<p>Now you can use <code>git status</code>, <code>git add</code> and <code>git commit</code> to add and commit files as normal, and the commits will go to your local &quot;feature_mything&quot; branch. </p>
<p>If you want to push this work onto the remote repo, so that others can see your new branch, or just to make sure it is stored in the cloud, you can <code>git push</code> it. However the first time you do this, git doesn&#39;t yet know where to push it to, because it is a new branch. So the first time you push your branch, you need to set it up to also create a branch on the remote origin repo. You can do it like this:</p>
<pre><code class="language-sh">git push -u origin feature_mything
</code></pre>
<p>From this point on, the relationship between your local and remote &quot;feature_mything&quot; branches is set up, and now you can just use <code>git push</code>. </p>
<h3 id="merging-a-branch">Merging a branch</h3>
<p>Let&#39;s say your &quot;feature_mything&quot; branch was branched from the &quot;develop&quot; branch. You&#39;ve worked on the &quot;feature_mything&quot; branch for a while and you are happy that the feature is working and ready to merge back into the &quot;develop&quot; branch. Here&#39;s what you need to do. </p>
<p>Make sure all your changes are committed (use <code>git status</code> to verify)</p>
<p>Switch to the receiving branch (&quot;develop&quot;) and make sure it is up to date:</p>
<pre><code class="language-sh">git checkout
git pull
</code></pre>
<p>If it is all up do date, now you can merge in your feature branch:</p>
<pre><code class="language-sh">git merge feature_mything
</code></pre>
<p>If any conflicts arise these need to be resolved immediately. </p>
<p>Otherwise, your merge is now complete. You can now <code>git push</code> the develop branch. </p>
<p>If you are finished with the feature branch, you can delete the local branch like this:</p>
<pre><code class="language-sh">git branch -d feature_mything
</code></pre>
<p>To delete a remote branch:</p>
<pre><code class="language-sh">git push origin -d feature_mything
</code></pre>
<h2 id="forks">Forks</h2>
<p>Another way to collaborate via git is to create a Fork. You can do this on Github for any public project. A Fork is a copy of a repo that has the same history but is no longer connected to it. But after making changes to a Fork, you can submit a &quot;Pull Request&quot; to whoever manages the original repo, and they can review your changes before pulling them into their own repo. </p>
<h2 id="resolving-conflicts">Resolving conflicts</h2>
<p>Conflicts can happen sometimes when collaborating on code, where different people can create edits that <code>git</code> can&#39;t merge by itself. In these cases, <code>git status</code> will tell you <code>you have unmerged paths</code></p>
<p>See <a href="https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line">https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line</a></p>
<h3 id="when-two-people-have-modified-the-same-line-in-a-file">When two people have modified the same line in a file</h3>
<p>After committing your change, and then running a <code>git pull</code>, you get a message saying there is a conflict in a file (&quot;both modified&quot;). </p>
<p>Open that file in a text editor (e.g. VS Code). Search the file for the text <code>&lt;&lt;&lt;&lt;&lt;&lt;</code> to see where each conflict begins. </p>
<p>Conflicts are marked in the text file like this:</p>
<pre><code>unchanged content
&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
your changes
=======
the other person&#x27;s changes
&gt;&gt;&gt;&gt;&gt;&gt;&gt; branch-a
unchanged content
</code></pre>
<p>Edit the file manually to the point that it should be, removing the <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD</code>, <code>=======</code> and <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt; branch-a</code> accordingly. </p>
<p>Do this for every conflict in every file that had conflicts. </p>
<p>Verify that your edits are correct and the code is working properly. </p>
<p>Only after verifying this, add your changes using </p>
<pre><code class="language-sh">git add .
</code></pre>
<p>And commit with a message, e.g. </p>
<pre><code class="language-sh">git commit -m <span class="hljs-string">&quot;Resolve merge conflict by incorporating both suggestions&quot;</span>
</code></pre>
<p>It would be a good idea to <code>git pull</code> again to ensure the conflicts are done, and <code>git push</code> if you are collaborating on a remote branch so that other collaborators get your work too. </p>
<h3 id="when-one-person-edits-a-file-and-the-other-deletes-the-file">When one person edits a file and the other deletes the file</h3>
<p>Here <code>git status</code> will give you a message &quot;deleted by&quot; for each file in question. </p>
<p>Open the file to have a look at the latest changes, and verify whether the file should be kept or deleted. </p>
<p>To delete it, use <code>git rm filename</code>. To keep it, use <code>git add filename</code>. </p>
<p>Once you have run either <code>git rm filename</code> or <code>git add filename</code>, and you have resolved all other conflicts, you can then commit the changes:</p>
<pre><code class="language-sh">git commit -m <span class="hljs-string">&quot;Resolve merge conflict by incorporating both suggestions&quot;</span>
</code></pre>
<p>It would be a good idea to <code>git pull</code> again to ensure the conflicts are done, and <code>git push</code> if you are collaborating on a remote branch so that other collaborators get your work too. </p>

<footer>DATT4520/DIGM5520 2021-22</footer>
</body>
<script src="js/connect.js"></script>
</html>
Loading

0 comments on commit 6028527

Please sign in to comment.