Git workflow and operations

The difference between Git, GitHub and GitLab

Git

Git is a distributed version control system.

  • A version control system is a system used to record changes in the content of one or more files to facilitate checking the revision status of a specific version.
    Before using a version control system, if you need to record modifications to different versions of the same file, you may use naming methods such as “file_v1”, “file_v2”, and “file_v3” to save the addition, modification, deletion and other operations of files at different times. .

  • The distributed system can completely mirror the code warehouse, which is equivalent to everyone’s computer being a complete version library.

  • Centralized version control system: The version library is stored in a central server. When working, we use our own computer. Therefore, we first need to pull the latest version from the central server, and then start working. When the work is completed, Then submit your work to the central server. (To borrow a metaphor from Teacher Liao Xuefeng, the central server is like a library. If you want to change one of the books, you must first borrow the book from the library, then change it, and then put it back into the library after the change. )

  • Distributed version control system: There is no concept of a central server. What is extracted locally is not just the latest files, but a complete mirror of the code warehouse, which is equivalent to everyone’s computer being a complete version library. In this case, if any server working together fails, any mirrored local warehouse can be used to recover. Even if the network environment is poor, there is no need to worry, because the version library is on the local computer.

The difference between centralized and distributed version control systems

  • The historical warehouse of the centralized version control system exists in the central warehouse, and every code comparison and submission must be connected to the central warehouse;
  • The local warehouse of the distributed version control system contains the code library and history library, that is, the version history can be viewed locally.

GitHub

GitHub is a hosting platform for open source and private software projects. It only supports git as the only version library format for hosting.

GitLab

GitLab is an open source project for warehouse management systems. It uses an MIT license and has wiki and issue tracking functions. It uses Git as a code management tool and builds a web service on this basis.

GitLab has a complete management interface and permission control, and is generally used to build Git private servers in internal networks such as companies and schools.

What GitHub and GitLab have in common

  • GitHub and GitLlab are both web-based Git remote warehouses. Both provide a platform for sharing open source projects and provide development teams with a centralized cloud storage place to store, share, publish and collaborate on development projects.

The differences between GitHub and GitLab

  • GitHub provides both public and private warehouses, but if you use a private warehouse, you need to pay; GitLab can create a private free warehouse. From the perspective of code privacy, GitLab is a better choice. But for open source projects, GitHub is still the first choice for code hosting.

The general workflow is as follows:

After installation, you can right-click on any folder to open the git bash terminal, which supports common Linux commands.

  • Clone Git resources from the remote repository as a local repository;
  • Checkout the code from the local warehouse and modify the code;
  • Submit the code to the staging area before submitting it to the local warehouse;
  • Submit modifications to the local warehouse; save various historical versions of the modifications in the local warehouse;
  • When you need to share code with team members, you can push the modified code to the remote warehouse.

Git’s workflow diagram is as follows:

Download and install

  • win
    Git – Downloading Package (git-scm.com)
  • linux
    • debian & ubuntu: sudo apt-get install git
    • centos & redhat：sudo yum install git

User information configuration

Before use, perform local user configuration.

  • Configure local user information:

    git config --global user.name "John Doe"
    git config --global user.email [email protected]

  • View local user information

    git config user.name
    git config user.email

  • Save username and password so you don’t have to enter them every time

    git config --global credential.helper store

  • Clear local user password

    git credential-manager uninstall

  • User information is only used for marking during configuration, not remote authentication information.

Register this machine to the remote warehouse

Why do this

A pair of public and private keys is generated, the private key is kept locally, and the public key is sent to the administrator of the remote warehouse. The latter adds the public key to the list of approved public keys, and the device is recognized remotely.

When pulling updates from a remote service, the remote server can encrypt the data with your public key, and then decrypt it with the local private key after receiving it locally. Because only you have the private key, only you can decrypt it, thus protecting the permissions of the warehouse.

When pushing updates from the local to the remote repository, use the private key to encrypt the data, and the remote repository uses the public key you started submitting to decrypt the data.

Operation process

Generate local public key

Executing ssh-keygen on the Linux terminal (or gitbash on Windows) will generate a pair of public and private keys id_dsa and id_dsa.pub. Under Linux, it is in the ~/.ssh directory, and under Windows, it is under users/username/.ssh.

The content of the id_dsa.pub file is the public key, and the content inside is base64 transcoded.

Register the public key to the remote warehouse, taking gitlab as an example

Commonly used git commands

  • Create warehouse

    git init

  • Clone repository

    git clone https://xxx/mypro.git

  • view remote

    git remote

  • View current staging status

    git status

    Only files in the staged state will be committed.

  • Add files to track

    git add filename

  • Delete Files

    git rm somefile

  • Undo file tracking

    git reset somefile

  • Undo changes to a file

    git checkout somefile

  • Submit (tentative status)

    git commit -m "first commit"

  • Get remote updates

    git fetch remote_rep_name

  • Pull to local

    git pull

  • Push to remote warehouse

    git push

  • View submitted changes

    git show commitid filename

  • Revert to a specified version

    git rebase -i commitid

  • Undo N commits

    git reset --hard HEAD~N

  • Clear commit, restore version

    git fetch origin branchname

    git reset --hard origin/branchname

  • View local branch list

    git branch -a

  • View a list of remote branches

    git branch -r

  • Create a new branch

    git branch branchname

  • switch branch

    git checkout branchname

  • delete branch

    git branch -d

  • Submit branch to remote

    git push origin local_branch_name:remote_branch_name

  • Re-pull the current directory

    First delete the things in the directory, then git checkout .

  • Clear updates

    git checkout . & amp; & amp; git clean -xdf

The knowledge points of the article match the official knowledge archives, and you can further learn related knowledge. Git Skill TreeHomepage Overview 6647 people are learning the system