<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-03-seq-03-ver-01" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@42faff439b4f4a43b57e045bb7983186">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@42faff439b4f4a43b57e045bb7983186" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/42faff439b4f4a43b57e045bb7983186.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>If you are already familiar with these tools, you can jump ahead to the activities which will get us started on making concrete contributions to a project. Don't skip those though! They are simple steps, but ones we'll build upon in future sections to ramp up the size and scope of our contributions.</p>
<p></p></div></div>
</div>
</div>
<div class="vert vert-1" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-01-html-01">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-01-html-01" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-03-seq-03-ver-01-html-01.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><h3 id="what-is-scm-vcs-">What is SCM/VCS?</h3>
<p>SCM stands for Source Control Management (sometimes Source Code Management). VCS stands for Version Control System. SCM and VCS are interchangeable terms used for systems that manage changes to the source code of software.</p>
<p>If you've written any code you'll know that in the end any feature, bug-fix or any change to software usually boils down to changes across a number of text files. Whether you work on Python, Ruby, JavaScript, C++, C#, Java or any other programming language, you'll be making changes to your code over time.</p>
<h4>Keeping track of the history of the code</h4>
<p>Often in order to understand why something doesn't work the way it used to, it can be invaluable to see the state of your code as it was days, weeks, or even months ago. When you run into such an issue, you'll quickly realise that the undo button of your editor only goes so far.</p>
<p>The simplest solution here is to keep copies of your code at different points as it changes. If you take a backup after each logical change to your software, after it's in a running state and has been tested you will have a way to see your code as it exists at different points of time.</p>
<p>This is essentially what SCM/VCS software is specialised to do by storing this information in a hidden folder along with your code. It also keeps this information in a condensed form so it's easier to store and transmit.</p>
<p>SCM/VCS software, like Git, are tools that are specialised to keep track of changes to code and other artefacts. They allow easy switching between the code versions at different points of time in its history. While you can store different file types in version control systems, they are usually optimised to handle text files and are most efficient to track changes within those files.</p>
<p>When you use such a tool, you will generally make some changes, use the commands or UI the tool provides to save/commit the changes to a "repository" along with a message describing the changes you've just made. A repository in this case is just a set of data files that stores the history of changes made to your code.</p>
<h4 id="working-with-others">Working with others</h4>
<p>One important aspect of developing software we've left out so far here is working with others. When working on any software, and especially when working on open source software, you need to work with other people.</p>
<p>For multiple people to work together they all need access to the latest version of the code at all times so that they can work on it. Even so, as different people work on different parts of the code, they will undoubtedly end up in situations where they make conflicting changes, or when two people are working on different versions of the same code base.</p>
<p>If you were manually maintaining copies of your code, this could become unwieldy as different people could be making different changes in the code, and you'd need to merge them together regularly. For instance if Alice and Bob needed to work on the same code at the same time, they'd both make backups of the existing code, make changes, however Alice wouldn't have Bob's changes and vice-versa, they'd need to coordinate with each other to make sure the final product includes both changes.</p>
<p>When using an SCM the tool will often help you see and track only the changes you've made to the code. It will make it clear to people when files they haven't accounted for have changed, or if two people have made changes to the same files. If two or more people have changed the same file(s) they can often handle that gracefully as well unless the differences overlap with each other.</p>
<p>Such tools will often warn you when you run into such conflicting situations so you can incorporate the changes others have made into your own code and add changes to your updates in case needed.</p>
<h4 id="a-brief-intro-to-git">A brief history of SCM</h4>
<p>If you've heard of the term SCM, VCS or have heard of GitHub/Gitlab you might have also heard of Git.</p>
<p>Git is a VCS/SCM that has become the de-facto standard for version control. The history of version control is filled with other tools such as CVS, SVN, Perforce, BitKeeper, Bazaar, Fossil, Mercurial, etc, Git is one of the latest generation tools that incorporated the trends and ways people work on software collaboratively and gained high popularity. If you work on software it won't be long before you will be introduced to it.</p>
<p>The history of Source Control software is long, but given it's immense popularity we will focus mostly on Git.</p>
<p>Since version control software are designed to not only help you track changes to code over time, but also work together with others on the same code, it traditionally operated in a centralised manner.</p>
<p>With CVS and SVN for instance you'd need to run a server that would maintain the history of the code, and would also allow developers to "lock" files so that only one person could modify a file at a time. If this central server was offline, you could no longer see the history of the code, or save any changes to the code history.</p>
<p>Modern VCS software like Git take a different decentralised approach. Instead of requiring a single central place for maintaining all the source code history and metadata, and only keeping minimal information locally with the code, these tools keep everything locally.</p>
<p>When working with Git you can make changes, commit changes, and keep a full local history before interacting with another remote system.</p>
<p>In this sense the repository at a site hosting a Git repository like GitHub, isn't any different than a local copy. They may provide additional features for easily navigating the code and its history, or for reviewing changes, but those features layer over Git, they are not a part of it.</p>
<p>With Git you can send/sync changes between any two repositories, not just from your local copy to one hosted by GitHub for instance. That is how they earn the name of distributed version control systems (DVCS) even though often in common operation you still need some central place where you can collaborate with others.</p>
<p>It is important to note that Git isn't the only SCM you're likely to encounter out there. For open source software it is definitely the most popular, but you might also see SVN and Mercurial in use. In the closed source/proprietary world there are proprietary SCM/VCS tools like Perforce Helix, or Microsoft Visual SourceSafe that you might find in use.</p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-03-seq-03-ver-02" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-02-html-02">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-02-html-02" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-03-seq-03-ver-02-html-02.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>Branches allow for parts of software to be developed in parallel. Large projects require many roles to be filled, including developers, build managers, and quality assurance personnel. Further, multiple releases on different operating system platforms may have to be maintained. Branches allow contributors to isolate changes without destabilizing the codebase, for example, fixes for bugs, new features. These changes may be later merged (resynchronized) after testing.</p>
<p>A <i>development branch</i> or <i>development tree</i> of a piece of software is a version that is under development, and has not yet been officially released. In the open source community, the notion of release is typically metaphorical, since anyone can usually check out any desired version, whether it be in the development branch or not. Often, the version that will eventually become the next <i>major</i> version is called <i>the</i> development branch. However, there is often more than one subsequent version of the software under development at a given time.</p>
<p>Some revision control systems have specific jargon for the main development branch; for example, in CVS, it is called the "MAIN"; in Git it is called the "main" or formerly "master". A more generic term is "trunk".</p>
<p>Further explanation about the branching model and graph structure of version control is available at <a href="https://en.wikipedia.org/wiki/Version_control#Graph_structure" target="[object Object]">https://en.wikipedia.org/wiki/Version_control#Graph_structure</a> and <a href="https://en.wikipedia.org/wiki/Branching_(version_control)" target="[object Object]">https://en.wikipedia.org/wiki/Branching_(version_control)</a> </p></div></div>
</div>
</div>
<div class="vert vert-1" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-02-html-03">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-02-html-03" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-03-seq-03-ver-02-html-03.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><h3>Time for a demo!</h3>
<p>Go to <a href="https://learngitbranching.js.org/?NODEMO=&locale=en_EN" target="_blank" rel="noopener">https://learngitbranching.js.org/?NODEMO=&locale=en_EN</a></p>
<p>in the terminal within this website, type the command</p>
<p><code>import tree</code></p>
<p>and copy/paste the content of</p>
<p><a href="https://gitlab.com/-/snippets/2220501/raw/main/braching.json" target="_blank" rel="noopener">https://gitlab.com/-/snippets/2220501/raw/main/braching.json</a></p>
<p>you will see the graphical representation of a "version tree" with branches:</p>
<ul>
<li>main is the "MAIN" branch as explained above</li>
<li>bugfix1 is an attempt to fix a bug from version C6 that was integrated into the "MAIN" branch in version C10</li>
<li>feature1 is a new feature that was created from version C1 and that was integrated into the "MAIN" branch in version C12</li>
</ul>
<p>Now, let's look at a real example! Veloren is a <a href="https://en.wikipedia.org/wiki/Voxel" target="_blank" rel="noopener">Voxel</a> game written in the Rust programming language, look at this amazing graph representation of the branches!</p>
<p><a href="https://gitlab.com/veloren/veloren/-/network/v0.8.0" target="_blank" rel="noopener">https://gitlab.com/veloren/veloren/-/network/v0.8.0</a></p>
<p>Can you see when the branch 'xMAC94x/release_numbers' was integrated into the branch 'master' ? </p>
<p>What verb is used to say that the branch was integrated into the other branch ?</p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-03-seq-04-ver-01" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-04-ver-01-html-01">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-04-ver-01-html-01" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-03-seq-04-ver-01-html-01.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><h4>Getting familiar with GIT</h4>
<p>If you're not familiar with GIT we recommend that you brush your knowledge of GIT with the online tool "LEARN GIT BRANCHING" by going to <a href="https://learngitbranching.js.org/" target="_blank" rel="noopener">https://learngitbranching.js.org/</a> and doing some levels. They describe the learning tool as "the most visual and interactive way to learn Git on the web; you'll be challenged with exciting levels, given step-by-step demonstrations of powerful features, and maybe even have a bit of fun along the way."</p>
<h4>Installing GIT</h4>
<p>Once you have played and learned some git branching, you will have to setup git locally and test the installation. We recommend that you open the official <a href="https://git-scm.com/book/en/v2" target="_blank" rel="noopener">GIT documentation book</a> and go directly to corresponding parts: "Installing Git" and "First-Time Git Setup".</p>
<h4>Playing with GIT locally</h4>
<p>create a local repot with git init</p>
<p>create a file</p>
<p>add a file to your local repository</p>
<p>commit the file with a message</p>
<p>modify the file</p>
<p>commit the modification</p>
<p>see the log</p></div></div>
</div>
</div>
<div class="vert vert-1" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@673480e462e54e3e81f98db59ab827d6">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@673480e462e54e3e81f98db59ab827d6" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/673480e462e54e3e81f98db59ab827d6.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>If you want to go further with git we recommend a fun game bellow:</p>
<p><a href="https://ohmygit.org/" target="[object Object]">https://ohmygit.org/</a> An open source game about learning Git!</p>
<p>You will also gain knowledge of Git during during your mission to contribute to a FLOSS project !</p>
<p><a href="http://teachingopensource.org/learning-material/interactive-visualization-git/" target="[object Object]"></a></p>
<p></p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-03-seq-03-ver-05" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-05-html-02">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-03-seq-03-ver-05-html-02" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-03-seq-03-ver-05-html-02.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>As we've seen, there are multiple different version control systems, and each uses their own, unique language to describe how to interact with code and branches. Let's take a look at some of the most common concepts and commands that all version control systems use, as well as a look at how these commands are implemented in Git. We'll keep in mind that various systems may call these by different names, but we'll be looking specifically at Git syntax moving forward - Git is used by many large projects (such as the Linux kernel, Android, and React), is free and easy to use, and generally has the strongest feature set for developers <em>[note: I cannot find any statistics to support this, just a lot of assertions]</em></p>
<ul>
<li><strong>clone: </strong>to completely copy the contents of one repository ("repo") into another, usually you clone a remote repository (from a server) to a local repository (into your working computer). Most of the time when you are developing on an open source project, you will first use a clone command to make your own copy of the repo.</li>
<ul>
<li>Cloning an existing repo to your local machine: <code>git clone <repo-url> <local-directory></code></li>
<li><strong><em> downstream</em></strong> and <em><strong>upstream</strong></em>: As a reminder, your clone of the repo is called a <em>downstream</em> clone, as opposed to the <em>upstream</em> repo you just copied from - think about it this way: when you've made a clone, information has flowed <em>downstream</em> to you. When you make changes you'll want to send those changes back <em>upstream</em>, and you'll also want to be periodically grabbing changes from <em>upstream</em> back into your <em>downstream</em> repo.<code></code></li>
</ul>
<li><strong>branches (concept)</strong>: we've already seen this, but just a reminder that branches are a collection of code which duplicates another branch, and can be modified independently of other branches. Now we can talk about:</li>
<ul>
<li><strong>branch</strong>: the command to create a new branch. This command will ask you to specify which branch you'd like your new branch to be based off of - it will often be off the repo's main branch, but there are good cases to branch off of an existing feature or bug branch.</li>
<ul>
<li>Listing all the branches in your repo: <code>git branch</code></li>
<li>Creating a new branch (off of whatever branch you're currently on): <code>git branch new-branch-name</code></li>
</ul>
<li><strong>checkout</strong>: this command gives you a local copy of a branch. An example of how this command is used is you might be working on multiple branches, and to switch between those branches you would use the <em>checkout </em>command.</li>
<ul>
<li>Checking out the new branch you just created: <code>git checkout new-branch-name </code></li>
<li>Making a new branch and checking it out at the same time: <code>git checkout -b new-branch-2</code></li>
</ul>
<li><strong>commit</strong>: when writing code on your local machine, your work remains "unsaved" until you decide to <em>commit</em> it, or, record the changes that you make in one bundle. When making a commit, you will write a <em>commit message</em>, which is a concise description of the changes you've made in that commit. Some projects use <a href="https://www.conventionalcommits.org/en/v1.0.0/" target="[object Object]">conventional commits</a>, which is a structured format for commit messages. Note that commits you make are only saved locally, <em>not </em>in the central version control (for example on a remote repository), until you <em>push</em> them.</li>
<ul>
<li>Commit all changes command: <code>git commit -a</code> (this will pop up an editor for longer commit messages)</li>
<li>Commit with a shorter commit messages: <code>git commit -a -m "Short commit message"</code></li>
</ul>
<li><strong>push:</strong> this command takes the commit(s) you have committed locally and sends it to the remote repo. You can push one or many commits at the same time. Your local code changes are usually not saved automatically in the remote repository until you push them. The first time you push a new branch <em>upstream</em>, you may have to use a special push command to make sure the server receives an entire copy of that branch.</li>
<ul>
<li>Pushing an existing branch upstream: <code>git push <remote-repo-name> my-branch</code></li>
<li>Pushing a new branch upstream: <code>git push --set-upstream <remote-repo-name> new-branch</code></li>
</ul>
<li><strong>pull</strong>: this command grabs new commit(s) that have been pushed to the remote repository and applies those commits to your local branch. If the commits don't contain code that is in the area of any commits you already have on your local branch, they will apply<em> </em>cleanly in a <em>merge</em>. However, when the changes do occur in the same places you'll have to deal with a <em>merge conflict.</em></li>
<ul>
<li>Basic usage, when on a local branch pulling from the <em>upstream</em> branch: <code>git pull</code></li>
</ul>
<li><strong>merge</strong>: merging is both a concept and a command. To merge code simply means to take a set of code changes from a branch (in the form of one or more commits) and apply those changes to another branch (known as the <em>base branch</em>). One will encounter merges when doing <em>pulls</em> locally, as well as when dealing with <em>pull requests</em> or <em>merge requests</em>.</li>
<ul>
<li>When working on branch <code>feature-branch</code>, first checkout your target branch (that is, switch to the branch that will receive and merge the commits) then merge your original branch into it: <code>git checkout main; git merge feature-branch</code></li>
</ul>
<li><strong>merge conflict</strong>: a merge conflict occurs when the changes from the branch that wishes to merge to the base branch overlap with the code that is present on the base branch. Merge conflicts need to be resolved by the author(s) of the code on the requesting branch - they will need to <em>resolve </em>the conflicts before a merge can occur.</li>
<ul>
<li>Dealing with merge conflicts can be tricky; a good code editor can be really helpful, otherwise a series of command line tools can help: <code>git status</code> shows where conflicts are, <code>git diff</code> can show what they are. Edit those files to resolve conflicts, then <code>git commit</code> your changes.</li>
</ul>
<li><strong>pull request or merge request (concept)</strong>: a <em>pull request</em> or <em>merge request</em> is a way of asking if the code on your branch can be <em>merged</em> into another branch (the "base branch", which is often a project's main branch). Pull/Merge requests initiate a <em>code review</em>, where project members examine the code and provide their feedback. Pull/Merge requests often have a graphical interface (which differs from site to site), but most enable a way of viewing the code additions and deletions (the <em>diff</em>) from all commits, and providing a method for reviewers to leave feedback. Frequently these graphical interfaces contain a button that allows the merge to happen automatically.</li>
</ul>
</ul>
<p>The above commands are the most basic commands that exist in version control. We explained <em>push</em>, <em>pull</em>, and <em>merge</em> in the context of branches, but do note they also apply to cloned repos as well. Your downstream repo, for example, <i>pulls</i> changes from the upstream repo.</p>
<p>Here are a few more commands that you may well encounter, and you should know as well:</p>
<ul>
<li><strong>revert: </strong>this command reverses commits that have been made on a branch. In some systems, this will leave the commits present on the branch and introduces a new, "revert" commit that undoes their changes. (<code>git revert <commit-hash></code>)</li>
<li><strong>squash</strong>: some projects ask that you <em>squash</em> your commits prior to merging them. Squashing means to take all of your commits - some of which may be big feature changes, while others are small bugfixes or test commits - and compress them to a small number of logical changes with well-crafted commit messages. Squashing can be a complicated process so don't be afraid to ask for help. (use an <a href="https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History" target="[object Object]">interactive rebase</a>; this opens up an editor to help you squash the previous three commits: <code>git rebase -i HEAD~3</code>)</li>
<li><strong>reset</strong>: if present, this is a helpful, but tricky, command that can help you undo commits locally (or even throw their changes away entirely). This command is tough to understand, but <a href="https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified" target="[object Object]">the official Git explanation of reset</a> is very helpful.</li>
</ul></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-03-seq-03-ver-06" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@problem+block@e6c3c9ee90d9410da4fa0e757eb8fbcf">
<div class="xblock xblock-public_view xblock-public_view-problem xmodule_display xmodule_ProblemBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-block-type="problem" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@problem+block@e6c3c9ee90d9410da4fa0e757eb8fbcf" data-request-token="8ed52cee903711ee8c631237928d7ffd" data-graded="False" data-has-score="True">
<div class="page-banner"><div class="alert alert-warning"><span class="icon icon-alert fa fa fa-warning" aria-hidden="true"></span><div class="message-content">Multiple Choice is only accessible to enrolled learners. Sign in or register, and enroll in this course to view it.</div></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>