Welcome to github.com/hsfxuebao/j… , hope to help you, if you feel ok, please click on the Star

preface

This section introduces some simple interactions between local and remote repositories, as well as some commonly used Git graphical interfaces to make Git easier to use.

Git bare library

Simply put, a git bare repository is a Git repository with no workspace. Servers, for example, serve only as code hosts and do not need or should modify the code on the server.

Git bare libraries can be created with the following instructions:

Git init --bare copies the codeCopy the code

Once created, look at the current file directory:

You can see that there is no workspace directory, indicating that the Git bare library is only used to hold and relay code submitted by developers.

Local repository and remote version repository

  • ** Local repository: ** is the same as beforegitWarehouse, divided into three areas: workspace, staging area and repository;
  • Remote version library: a remote online version library corresponding to the local version library, which is a raw library.

We typically make changes to files in the workspace and staging area of the local Git repository, commit them to the local repository, and eventually push them to the remote repository for hosting. The whole process is shown in the figure below:

The essence of a remote repository is a remote repository corresponding to a local repository, usually called a remote repository.

A remote repository (version library) exists to exchange information between multiple computers, equivalent to a third-party container in the process of exchanging two numbers.

Git push and git pull

These two commands are very common when we use remote repositories, and they are very important:

  • Git push: push code from a branch of a local repository to a branch of a remote repository; Note that the push operation is branch to branch, rather than pushing all branches of the local repository to the remote repository, as shown below (assuming push to remote branch with the same name) :

  • Git pull: pull files from a remote repository into a local repository, so the workspace is clean:

    In this case, st is the alias of status. Details about the alias will be explained later.

The full form of the push instruction:

Git push origin srcBranch:destBranch copies codeCopy the code

SrcBranch indicates a local branch, and destBranch indicates a remote branch.

The complete form of the pull directive:

Git pull origin srcBranch:destBranch Copies codeCopy the code

SrcBranch indicates the remote branch, and destBrach indicates the local branch.

SrcBranch indicates where it comes from, destBranch indicates where it goes.

There are three cases of Git push

  • ** Case 1: ** When only one user operates the remote repository, the local repository keeps track of all files and operations, so even if the local repository deletes the files pushed to the remote repository, there is no need to perform git pull again.

    For example, the remote repository has these files:

    Delete other files in the corresponding local repository, leaving only readme.md, and then push to the remote repository. The push process goes smoothly without requiring a Git pull operation to pull and merge files from the remote repository.

  • ** Case 2: ** Also only one user operates the remote repository, but does not update the remote repository by local push. Instead, it directly adds files to the remote repository, such as readme.md manually.

    The local repository does not keep track of the readme. md added to the remote repository.

    In this case, you need to perform the Git pull operation to pull, merge, and trace the newly added files in the remote repository before git push.

  • ** Case 3: ** Multiple users share the same remote repository, such as users A and B. In this case, the remote repository has files submitted by USER A but not by user B. Therefore, before implementing git push, B should first perform git pull operation to pull, merge and track the files that are not available in the remote repository.

The git pull the essence

During a pull operation, a merge is performed, which may or may not succeed:

  • ifmergeSuccess: indicates that two people did not modify the same file, or the same file in different places, sogitCan be used directlyFast-forwardMode automatic merge;
  • ifmergeFailure: indicates that two people may have modifiedThe same filetheThe same lineAt this time, it is necessary to carry outManually mergeTo resolve file conflicts;

Only after the merge is complete can the push operation be performed to push the code from the local repository to the remote repository;

The pull operation is a combination of the fetch operation and the merge operation:

  • The fetch command pulls all files from the remote repository into the version repository of the local repository.

  • The merge command merges and pulls local files.

2. Making and Gitlab

  • To have a firstGithubAfter theGitlab
  • GitlabFor IntranetGithub, i.e.,GitlabFor IntranetgitRemote server. The code is not open source and can only be used by Intranet users.
Github

The world’s largest open source and proprietary software project hosting and gay dating platform;

Gitlab

Gitlab can be used as a remote code hosting server for the Intranet. It is usually installed on Linux system:

Local repository -> Remote repository

1. Make connections

Two protocols can be used to clone projects on Github: HTTP/HTTPS and SSH:

When the HTTP/HTTPS protocol is used to establish a connection between the local warehouse and the remote warehouse, no configuration is required, but the account password is required each time you push the account. The SSH protocol, however, only needs to be configured once to achieve encrypted push.

The HTTP/HTTPS protocol
  • cloningGithubThe protocol can be used when:

  • This protocol can also be used when establishing a connection between a local warehouse and a remote warehouse:

    Git Remote add Origin github.com/AhuntSun/te… Copy the code

“Origin” means “remote repository”, but can not be called this name, but the convention is called origin. After executing this command, origin can be used to represent the URL for the remote repository.

However, the Github project has permission management, and no other users can push the code except the remote repository creator himself. Therefore, every time the code of the local repository is pushed, the account password needs to be entered to verify the identity of the pusher.

SSH protocol

HTTPS is recommended for encrypted transmission on the public network. However, there is only HTTP protocol on the Intranet of the company, and the user name and password need to be entered repeatedly each time the code is pushed. This is inconvenient. Therefore, SSH can be used for authentication, and the process is as follows:

  • First, the remote repository is associated with an SSH address:

    Git remote add origin [email protected]: AhuntSun/test. The git duplicate codeCopy the code

    Notice that Github has informed us that the current Github account does not have any SSH public keys.

  • After adding, view the remote warehouse address:

    Git remote show originCopy the code

    As shown in the figure, the local repository does not have access to the remote repository. This is because we did not deploy the local SSH public key to the remote repository. To solve this problem, we need to generate the secret key pair locally and deploy the public key from it to the remote repository.

Generate a secret key pair

There is a “known_hosts” file in the.ssh folder:

If you open this file, you can see that the Github IP address of the remote repository has been added to the local trust address:

Next, use the following command to generate the public and private keys for the local computer:

Ssh-keygen copies the codeCopy the code

During the generation, you can select an address for saving the public and private keys. The default address is the. SSH folder. You can also set the password or do not set the password. After two press enters, the public key and private key are generated successfully.

You can see that there are two more files in the.ssh folder:

Id_rsa indicates the private key and id_rsa.pub indicates the public key. We can view their contents respectively.

  • Public key:

  • The private key:

The deployment of public key

Next, we need to deploy the generated public key to the remote repository Github, as shown below:

In this interface, you can add multiple public keys, if the project team has more than one member, or if one person uses more than one computer, you can set multiple public keys:

As shown, you can customize the name of the public key. Note: The Allow Write Access option must be checked otherwise the local repository code cannot be pushed to the remote repository. In addition, you need to enter the Github account password to confirm:

After the public key is added, you can view the new public key on the original page. This gives the local computer using the public key access to the remote repository;

With the public key deployed, you can successfully view the address of the remote repository:

In practice, SSH protocol is usually used to connect local and remote warehouses. Because you only need to configure the public key once, it is very convenient to carry out secret-free push.

Adding an Account SSH

An SSH public KEY was previously added to the Test repository on Github, but this SSH KEY is only used for local communication with the Test repository and cannot be used in other repositories.

If we want all repositories on Github to use the same SSH KEY, we need to configure SSH keys for accounts. Click Settings in the upper right corner of Github:

On this page, you can create a global SSH KEY:

2. Push code

After establishing the link between the local repository and the remote repository, you can push files from the local repository to the remote repository:

Git push -u origin master copy codeCopy the code

-u indicates that the local master branch is associated with the remote master branch. -u indicates that the local master branch is associated with the remote master branch. The next time you push it, you can push it directly through Git push.

3. View the address of the remote warehouse

There are three ways to view the addresses of all remote repositories associated with the local repository:

Git remote show origin git remote show originCopy the code

Git remote show origin

  • Fetch URL: indicates the URL that pulls the file to the local remote repository;

  • Push URL: represents the URL of the remote repository when pushing;

  • You can see that there is a one-to-one correspondence between the local and remote branches for git pull and Git push operations.

4. Change the address of the remote warehouse

  • Method 1: Delete the original IP address and add a new URL

    Git remote rm origin git remote add origin gitee.com/ahuntsun/gi… Copy the code

  • Method 2: Modify the ORIGINAL URL of the remote repository

    Git remote set-url origin 163.com

  • Method 3: Directly modify the config file in the. Git repository

This method is not recommended. You are advised to use the command line. If you manually modify the file, only part of the file may be modified. This may cause some unmaintainable situations;

** Note: ** Avoid manual manipulation of files. Git provides instructions for common, reasonable operations that are safer and more efficient.

By default, git’s remote repository addresses are called Origin; To add multiple remote warehouse addresses to a local warehouse, use the following methods:

Git remote add newOrigin https://biliwa.comCopy the code

However, when pushing files from a local repository to a different remote repository, the association needs to be re-established:

Git push -u newOrigin master copies the codeCopy the code

Once associated with the relevant branch of the remote repository, you can push directly using Git push (the shorthand is explained in the next section).

4. Git graphical interface

Git has many graphical interfaces that operate differently. But the essence is the same. Git commands are executed to implement various operations in the graphical interface. Therefore, under the premise of mastering the underlying operation commands of Git, it will be more convenient to use Git graphical interface. Therefore, it is not recommended for beginners to get started with Git’s graphical interface.

Gitk, Git Gui, Github DeskTop and SourceTree are four common Git Gui interfaces

1.gitk

Gitk is git’s own graphical interface, enter the command: gitk, you can open the graphical interface as shown below:

In the GITk graphical interface:

  • The left side shows the submission history, from bottom up, old to new;

  • The two columns on the right are the user and time corresponding to each submission.

This interface shows the principle of git merge: three-way merge, as shown below:

Append 1 and Append 2 commit the merging process by finding their common parent node and adding a hello, and then merging the two nodes based on that node to create the merged master node. This node has two parent Pointers to append 1 and append 2.

The bottom half of the GITk interface looks like this:

  • The image aboveSHA1 IDRepresents the identification code for each submission, i.ecommit_id;
  • AuthorandCommitterRepresents the author of the code and the submitter of the code, usually the same person; But in some open source projects, the author of the code does not have the right to submit the code (e.gGithub). Only one patch can be submittedissue, only after the open source project author agrees to modify, the project author will submit the code instead of the code author;
  • Below is the detailed information about the modification of each file; As shown in the picture below,ParentThis is the last commit,ChildRepresents the next commit:

2.Git Gui

Git Gui is also a graphical interface built into Git. You can open it by typing Git Gui commands:

In the picture above:

  • Unstaged Changes: represents files or changes not added to the staging area, i.e. workspace files;
  • Staged Changes: indicates that a file or change in the staging area is about to be committed.
  • Modified,not stage: indicates that the file has been modified but not included in the temporary storage area;

Git add. Adds all changes to the staging area:

When you look at the Git Gui again after executing the above instructions, you will see that the file has been moved to the Stage Changes area. Then you can submit directly on Git Gui interface, as shown below:

Every step in the Git Gui is actually implemented through a command line instruction. In addition, the Git Gui menu bar provides many other functions:

3.Github DeskTop

This is the Github client application, which also belongs to Git graphical interface:

In the File option of the interface, you can add a local repository for management:

You can view the commit history and other relevant information of the local repository:

4.Sourcetree

This is a popular Git graphical interface. The official website is www.sourcetreeapp.com/

To install, you need to register an account:

Once installed, it is ready to use:

Function is very powerful, it is also very convenient to use, here will not be introduced in detail, interested in the online information can be consulted.

That’s all for this section, which briefly introduces the interaction between local and remote repositories using Git, as well as four common Git graphical interfaces. I believe that you have a certain understanding of the relationship between local and remote warehouses, and will have a lot of questions. That’s ok, the next section will show you in detail how to use a remote repository for collaborative development. See you in the next section!

Reference: juejin. Cn/post / 684490…