Meteor uses Git and GitHub

Use Git and GitHub

GitHub is a social code storage space for open source projects based on Git as a version control system. I ts primary function is code sharing and project collaboration. In this chapter you can quickly find some ways to learn this book with GitHub.

This section assumes that you don't know much about Git and GitHub. If you already know them, you can jump straight to the next chapter!

Code submission

Git's most basic unit of work is Submit . You can imagine a commit as a snapshot of your code base at a specific time.

Instead of simply giving you the final code version of your Microsocope project, we prefer to provide snapshots of every step of the development process so that you can see them online on Github.

For example, this is what our last submission (the https://github.com/DiscoverMeteor/Microscope/commit/chapter3-2 chapter looks like this:

You can post_item.js of this file, in other words, where this submission changed the file. Because this file is new, you can see that everything is highlighted in green.

Let's compare another example of a file that will be used later in this book:

This time, only the modified lines of code are highlighted green.

Of course, sometimes we don't add and modify the code, but instead delete some lines directly:

Well, we now see the first benefit of GitHub: a glance at code changes.

Browse the submitted code

Git's submission view shows us the code changes for this commit, but sometimes we need to look at the code that has not been modified to make sure that their code looks reasonable.

Okay, let GitHub solve this problem again. On the submission page, click the Browse code button:

You can now see what the code base looks like at the time of a commit.

GitHub doesn't give us enough visual cues to let us know that we're looking at a commit, but you can compare it to the "normal" main view and you'll see a difference in the file structure:

Access local submissions

We've just seen how to browse the entire code of a submitted online on Github. B ut do you want to see it locally? For example, you might want to go back to a submitted code status test to test what it looked like then.

To do this you need to use git command line for the first time (perhaps not for the first time, but at least for the first time in this book). F or no starters, the first step is to make sure you've installed Git. T hen clone Clone (or download a local copy) of Microscope's code base. The command is as follows:

git clone git@github.com:DiscoverMeteor/Microscope.git github_microscope

The last item on github_microscope the local directory name that will store the code base. Assuming you already microscope folder, start with a new name (not the same name as the GitHub code base).

cd into this code base, and then we can use git command.

cd github_microscope

Now that we've cloned the code base from GitHub, we've downloaded all the code for the app, which means we're looking at the last commit.

Thankfully, we have a way to check out the code to fall back to a particular commit without affecting the other commits. Let's try:

git checkout chapter3-1
Node：checking out 'chapter3-1'.

You are now in the 'detached HEAD' state. Y ou can take a look at some experimental modifications and submit them. You only need to check out the code again to discard your commit without affecting any other branch.

If you want to create a new branch to keep your commit, you can do so (now or later), using the -b parameter when moving out of the code.

Example:

  git checkout -b new_branch_name

HEAD is now at a004b56... Added basic posts list template and static data.

Git informs you that you are now in the 'detached HEAD' state, which means that in the case of Git, you can discover past historical commits but cannot modify them. You can imagine a witch looking back at history with a crystal ball.

(Note that Git also has commands that let you change the history submission.) I t's more like time travel, but those aren't the areas we need to talk about in this book. ）

You can simply chapter3-1 because our implementation has tagged all Microscope commits. If your submission doesn't have a tag, you'll need to find your submission's hash, or ID, first.

Once again, GitHub makes it easy to submit a hash code in the blue commit box in the lower right corner of the commit. As shown in the figure:

This time let's try the hash code instead of the label:

git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
Previous HEAD position was a004b56... Added basic posts list template and static data.
HEAD is now at c7af59e... Augmented the postsList route to take a limit

Well, stop looking at history with the crystal ball, let's see the latest code status, we can get Git to check out the main branch master:

git checkout master

Note that you can also run meteor command now, even in the "detached HEAD" state. You may first need to run meteor update if Meteor prompts for a missing code package because Microscope's Git code base does not include package code.

Historical Perspective

There's also a common situation here: when you look at the code file, you see some changes you haven't seen before. M ost of the time you don't remember when you changed this file. You can check each commit one by one until you find that a commit caused the change, but a better approach is the history feature of GitHub.

First, look for a file in the code base on GitHub, and then find the History button:

You can now see all the submission histories that affect this file:

Accountability game

Let's take a look at accountability:

This concise view shows us line by line who modified the file and in which commit. (In other words, know who to look for if the software breaks down):

Git is already a fairly complex tool now - as is GitHub - so you can't cover all the features here. I n fact, we just learned a little fur. Still, this fur is enough for us to use in this book.