How can GitHub be used to increase productivity

This is a GitHub entry level article for beginners to Git. We’ll discuss some of the most important questions for beginners, such as why we use GitHub, what its applications are, how it can help us be more productive, and what its basic uses are.

Want to see in this paper, the related resources link friend, can direct access to my Chinese blog:https://www.terencexie.com or click here to read the original text.

Before we start talking about GitHub, it’s important to clarify a concept that may not be clear to beginners: Are GitHub and Git the same thing?

I don’t know about the others, but when I first came across GitHub, I barely noticed that GitHub and Git were two different things. To top it all off, I’ve even gone so far as to imagine in my head “HMM, maybe Git is an acronym for GitHub.” Now think of it is of course extremely ridiculous, but as a rookie to have to face a reality is: the reason why the rookie is a rookie is not because he is weak in one aspect, but in all aspects. Making an inference like this, without any research, without any official documentation or experimental data to back it up, and accepting it as a truth, is an important factor in further chaos.

Git and GitHub are two related but fundamentally different things. In a less strict way, GitHub is a service on the remote side that supports Git. It’s like your cloud service, keeping all the records of your native code versioning. With git introduced again, we’ll clarify and expand on this concept once again.

What is a git

Git is a code version control tool invented by Linus, the creator of the Linux kernel. While the motivation is to serve the code, it’s actually a useful tool for the average user, who isn’t a developer.

What is version control?

Let’s start with the familiar game archive. When playing an RPG, a very important basic feature is the ability to store the current state of the game. Because it’s almost impossible to get through all at once without stopping completely. There are many factors that can stop your story from unfolding, such as:

• You play the game slowly, and when it’s time to go to bed, you have to stop and play again.

• You tragically suffer a sudden computer outage and have to re-enter the game.

• Everything goes well, but you get killed by the big boss of the game.

With the game save feature, on the one hand you can pick up where you left off, and on the other hand, if your game has multiple branching stories, you can pick up where you left off and take a different route to a different experience.

So git does exactly the same thing. Git provides an archive function for all files in a specific directory (that is, the directory in which git init is run). From git’s point of view, the file directory state at each point in time can be used as a storage node (like a game archive). The ability to store the state of a file at various time points is called version control. In terms of using Facebook, git provides a timeline of everything that happens in the file directory, which acts like a game archive.

For example, suppose we have two files file1. TXT and file2.txt in MyDirectory where git init is run. TXT and file2. TXT each contain two lines of text, as shown in the following figure.

As a tutorial for beginning programmers, I need to say a few more words here to explain why this example works

git

As shown in Figure 1.0, this can be used as a current point in time file state for MyDirectory. When any file in MyDirectory changes,

The state of the moment, then, is just like the hero moving a position on the map in the game, which can be stored as the state of the file at another point in time (Figure 1.1).

As you can see, the discussion so far has nothing to do with GitHub and remote servers. Because git use can be local only, it has nothing to do with network connections. Therefore, for ordinary users, it is completely possible to use Git to archive your office files and personal files. The difference between archiving and backup is that the latter can store only one file state, while the former can store multiple file states, that is, the entire timeline of the file is stored. With it, you will be able to understand the entire evolution and growth history of this document, so as to have a deeper understanding and understanding of it.

One is Udacity’s How to Use Git and GitHub, and the other is Pro Git, which provides a downloadable digital version of git in a variety of formats.

Common git commands

Provides version control for file directories

The initial command, of course, is git init, which provides git functionality for versioning a file directory. For example, if you want to provide version control for file directories /Users/Terence/Documents, there are only two steps:

1. Switch to the target file directory: CD /Users/Terence/Documents.

2. Run git init.

At this point, the /Users/Terence/Documents directory has version control (essentially creating a.git hidden folder in this directory).

File modification and submission under version control

Next, I’ll discuss the states a file can present in a directory with Git monitoring. Under Git, a file can have four states:

• Untracked

• Unmodified

• Modified

• Staged

The same file in different states can exist independently of each other at the same time. Git 2.2 Pro Git 2.2 Pro Git 2.2

The state transitions associated with these arrows are explained from top to bottom.

First is the untracked state of the file, which is a file that hasn’t been incorporated into git’s archive system yet. Although the file directory is archived with git init, it does not specify which file timeline can be archived. So the state of the file that is not archived is untracked. It can be put into a staged state by command git add

. (This is a jump to describe its final state switch from having a file in its passively archived state enter the Git repository by commanding git commit

. The git repository becomes unmodified.

Then there is the unmodified state of the file. File names are usually blue in git interface. The first requirement for a file to become unmodified is that it has been included in the archive system and that it has been archived. That is, it must have been in a staged state after executing git commit

(commit to a Git repository, i.e. store the current state).

Then there is the file’s modified state, which is when a file has been modified. Git displays file names in red. For example, assuming that all files in Figure 1.0 are unmodified, we modify file2.txt to figure 1.1. In this case, file2. TXT is in the modified state.

Finally, there is the staged state of the document, which is to be stored. File names are usually green in git interface. This staged state is a very subtle state that can coexist with the Modified state.

For example: Now let’s assume that git add file2. TXT is run on the basis of Figure 1.1, and the file state becomes:

That is, the Yoga line becomes black, which is the unmodified state. If we modify it again, add the text L1:

In other words, the row with L1 added is now all red. You may be wondering why the whole line is affected when I just added the character L1. This is because Git looks at changes in files in units of behavior. Compare each line accordingly, and treat the entire line as if it has changed if there is a difference.

Git add file2. TXT

You can see that passage from staged passage (passively staged) has turned green.

Here’s the subtlety: If, instead of submitting our staged temporary state, we had continued to modify file2. TXT by deleting the newly inserted string L1, we would have obtained two states for this file:

• One is in a staged state (FIG. 1.4);

• The other is in modified state Figure 1.5

Note that although Figure 1.5 and Figure 1.1 are the same, the meanings of the hands are completely different. Figure 1.1 is formed from the state without Yoga and after adding Yoga string. Figure 1.5 is formed by removing the string L1 from state yoga.l1.

At this point, if we run git commit file2.txt again, the code we commit to git repository will become Figure 1.6 with yoga.l1

At the same time, the modified state figure 1.5 remains unchanged.

Hopefully this example helps you see the nuance here.

To sum up, the commands we cover here are:

• Git init enables git storage for files and directories.

• Git add
  
  adds a file untracked, or modified, into staged state.
  

• Git commit
  
  adds passively stateful files to your Git repository to become unmodified.
  

What is a lot

GitHub is a company that provides users with a remote (cloud-based) Git repository. The idea is that you have a local version control repository of files that keeps a timeline of all your files. However, if you change a computer and try to recreate the previous machine’s version control repository, it can be a hassle. So one solution was, why not put my warehouse system in the cloud. You can either put local changes to the cloud at any time and incorporate them into the official code base, or you can keep a copy of your own code repository locally and make your own changes.

Even more appealing, once your code is in the cloud, you can collaborate with others on the same project in different parts of the world. Everyone keeps their own changes to the code, making the cloud code base the official repository of Main Stream that everyone recognizes. People can check their code changes into the cloud repository, GitHub, once they’ve got each other’s approval (for the Pull Request (PR)).

So, in this sense, GitHub is a Git repository platform that provides cloud-based code versioning. In this sense, GitHub is indeed a social platform for technical staff. Posting moments and Facebook status messages on social platforms is equivalent to constantly showing your code changes and updates. Everyone is showing their work progress and the latest project progress through their project status. A close look at the history of version control reveals the entire history of the project, of the engineer.

In my opinion, GitHub serves two main purposes:

• Learn from someone else’s code and want to reproduce the results of the project or contribute your own.

• Or move your work to GitHub so it can be backed up in the cloud, or make it easier to collaborate with people in different locations.

Here, I’d like to expand on the details of these two points and the question points for beginners. They don’t themselves require too much technology to solve. However, they can be a barrier for beginners. Clarifying these vague concepts can greatly improve the effectiveness of GitHub for beginners.

Use GitHub to learn other people’s code

Writing code is like writing articles. To do good work, you need a lot of quality reading. GitHub has plenty of great projects to read. The essence and techniques of Programming are hidden in these excellent code details.

It’s easy to clone the good code locally with general references, or simply download the entire project into your local directory.

Then there’s the problem: you have the source code, but how do you turn it into the desired target software product? Compile, run? But where to compile and run?

This question relates to the practical difference between small projects in schools and real big projects in industry. Maybe in school, when learning C, Java, Python, just need to click on the command line or IDE interface to run.

However, in a real complex project, compiling the code involves more detail and steps. More environment configuration, resource preparation, and script running are required before compilation. Here are some examples when your project is complex enough:

• The source code itself, or part of it, that needs to be compiled needs to be generated by some text document. How to extract the required information from the text document into the appropriate code is controlled by a script.

• Before compiling your source code, you need to provide some third-party code libraries or packages. For example, third-party JAR packages for Java. Do you need to prepare these third-party resource files in advance? Or can it be obtained automatically from a script?

• The tool scripts mentioned above may be written in one or more specific languages. Does your current environment provide support for these languages?

The problems and possibilities mentioned above are far from extrapolating from the source code alone. So it’s not unusual to feel overwhelmed when you get this pile of source code.

So how to solve this problem?

My answer is, in your luck.

If you happen to be working on a project written by a programmer who isn’t comfortable or well-documented, or if the contributors themselves don’t want you to know about the build environment, you’re probably staring at the pile of code.

If you’re lucky, a really serious project will specify in its own documentation (usually a README file at the root of the project) how to deploy the build environment: it includes which build tools to prepare ahead of time, which third-party code libraries, how to invoke compiled scripts, and so on.

So when you see a project on GitHub, don’t go to Download just yet. Read the project’s documentation carefully to see if it’s good enough. In general, there is a positive correlation between the quality of documents and the quality of projects. The reason, in industry parlance, is that writing documentation is writing code, and if documentation is bad, the code is usually a mess.

How do I work on GitHub

If you simply use GitHub as a repository for your code backups, it’s not that complicated. You’re constantly modifying your code locally and checking in your approved code to the remote GitHub code base.

What’s really fun is working with others on the same project on GitHub.

To collaborate, first add your collaborator’s GitHub account to your project. This is just a matter of adding your Collaborators in GitHub’s project interface, click Settings — > Properties. This gives your collaborators permission to make changes to the project and to submit code to the project repository on GitHub.

If you both belong to an Organization on GitHub, the administrator of that Organization usually sets up its members to automatically have the right to change all projects in the Organization.

Here’s how it works on GitHub. As the core of Git, it is driven by branch. As the master branch, make sure it is running and tested. You can do your own feature development, experimentation, and testing on other branches without affecting the master Branch of the code base.

Well, it’s the same on GitHub. When several people work on a project as a team, each member should not simply submit code directly to Master Branch, even if you have the authority to do so. As a good practice, you should always make code changes and experiments on your own private branch, then push that branch to GitHub and perform a Pull Request on that branch on GitHub for the rest of the team to review your code. Only after a Reviewer has approved your code can you merge your change branch into master. That is, before anyone can submit code to master, there must be someone else’s code review step; You can’t submit code to the Master branch without someone else’s coder Review, even if you have permission to do so.

During the Pull Request, the reviewer and the reviewed can discuss each line of code in depth. For each line of code, a comment can be inserted for further study. These discussions are the essence of the entire code design, and the real key to improving the code. To return to the old adage that writing documentation is writing code, the spirit is that it is your thoughts and opinions that support the core of the code. The writing of a specific programming language is just an expression of this idea. You can’t write clean code until you have a clear idea of the problem you want to solve.

Even in the process of so-called cooperation, which is actually led by the master and apprentice, the value of these code reviews will be much higher than push code. Because push code is just a result, and comments on code review are the core to help you correct problems and change bad habits.

Often beginners don’t understand this, mistake comments for side dishes, get impatient with them, and just want to check code into the repository. Therefore, as a mentor, he is actually responsible for pointing out this difference and priority to his apprentice.

Let us emphasize once again that the comments and exchanges in the review process are the core of the whole code, and they are the guiding ideology and spirit of the whole project, no matter as an apprentice or as an equal partner. Once you clear up the problems step by step during the review process, you will be able to make changes to the code more easily and confidently, and ensure that the quality of the code base is maintained. Any behavior that belittles code Review or comments in review is naive self-deception. You need to be as serious about code review as you are about writing code, about commenting on the review process.

A recent review

Building products that Make Users scream for themselves, October 2017 Writing Summary, Platform Framework-101

If you like my article or share, please long press the qr code below to follow my wechat official account, thank you!

VIP appreciation area