[toc]

Git Learning Notes

Centralized management vs. distributed management

Centralized management (USING the SVN as an example)

Advantages:

The code is kept on a single server, which facilitates project management
Version snapshot stores the differences between versions and has a small storage space

Disadvantages:

When a server problem occurs, the code versioning function can be disabled or the history of the entire project can be lost
Because snapshots store only differences, the rollback is slow because snapshots are compared one by one

SVN mechanism is: the history of the whole project snapshots are stored in the server, and client save this project only the latest snapshot, so when a server fails, the light is caused due to a server failure can’t use version control, or the whole of the recorded history project lost, even if back also can only be restored to the latest snapshot of the client have

Distributed management (Using Git as an example)

Advantages:

Each client stores all historical snapshots of the entire project, and as long as one client is available, the project’s data (history) is not lost
Every snapshot saved by Git is a complete snapshot saved for the whole project, and the rollback speed is very fast

Disadvantages:

Since each snapshot is a complete history of the project, the storage space is slightly larger (but still small due to extreme compression algorithms)

Git folder structure description

Info contains a global exclusion file that stores log information. Objects stores all data. Refs This directory stores files that correspond to different branches The local configuration option file description is used to display the description of the current repository. The HEAD points to the temporary storage area of the index file of the latest versionCopy the code

Git initialization

Make a regular file directory a Git workspace

git init
Copy the code

Initial Git configuration

Description of the location of the configuration application

Git config –system is the configuration used by all users in the entire system. The corresponding configuration file is /etc/gitconfig in the Git installation directory
Git config –global This git configuration can only be used by current system users. The corresponding configuration file is the user directory /.gitconfig
Git config This git configuration only applies to the project in which git is managed (git init). The corresponding configuration file is /.git/config

== The git environment must be configured the first time you install it, and git bash updates will automatically follow ==

Personal Information Configuration

Git config -- user.email "yourEmail" -- git config -- user.email "yourEmail" -- git config -- user.email "yourEmailCopy the code

Personal Information Deletion

Git config --unset user. Name git config --unset userCopy the code

Query the configuration information of different locations

Git config --listCopy the code

Git’s three regions and three types of objects

Area:

The workspace Workplace
StagePlace staging area
Repository Repository

Object:

Git object
- Key-value is a key-value pair
- The Key is a hash calculated from the contents of the file
- A key-value pair is a bloB object inside Git
The tree object
Submit the object

Git object

Git objects are used to store data in key/value pairs. Git objects are used to store data in key/value pairs. Through the understanding and use of Git object and then lead to the tree object

The hash value is calculated based on the content

echo 'hello' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a

#Performed again

echo 'hello' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a
Copy the code

Writes to the database and gets a hash value calculated from the content

Echo "hello world" | git hash - object - w - the stdin # write the content of the echo#| is multiple commands serial operation Equivalent to performechoGit hash-object
#The -w parameter is used to setechoIs written to a Git object
#The stdin argument is used to read data from the standard input streamechoThe content of the)

#If you don't have -w you get the content computedhash, but the content is not written to the database
echo 'hello world' | git hash-object --stdin

#-- if stdin does not specify, it must be replaced with a file pathEcho 'fitz' > test. TXT # create a test. TXT file with fitz git hash-object -w test. TXTCopy the code

Go to the database corresponding to the Git object to view the stored data

git cat-file -p hash
Copy the code

View the type of data stored in the database

Git cat-file -t hash # blobCopy the code

Git object problem ==

You can only track changes in file contents, not changes in multiple files (versions), so it cannot be a snapshot of the entire project
Remember that miscellaneous hash values are not practical
Git does not save file names (hash values instead of file names)
Manipulating Git objects is simply about designing data access without Stage/Index places.

A Git object can only represent a snapshot of a single file from one version to another (a hash is appended rather than replaced with each change), and it is not a version of the entire project (it can only track a single file)

The tree object

The tree object solves the problem that Git objects can only be stored with hash values rather than file names. It also allows us to organize multiple files together as a version snapshot of the entire project. The operation of the == tree object involves the staging area ==

Tree objects can be thought of as folders,git objects as files. == Naturally, a tree object can contain another tree object (subtree object) and a Git object ==

Save the file to the staging area in preparation for building the tree object (creating a version snapshot)

At this point, the INDEX file appears in the. Git directory, which represents the status of the staging area

git update-index --add --cacheinfo 100644 hash fileName.ext
#The --add parameter indicates whether the current file is to be added to the staging area (this parameter is not required if the staging area already has a file object with the same name)
#100644 means this is a normal file and the other file modes are: 100755 executable file 120000 means symbolic link
#The cacheinfo parameter indicates that the file to be added is in a Git database (a Git object) rather than a file in the current directory
Copy the code

Create a tree object from git objects and place it in the staging area

Echo "" | # file name to create a new file git update - index -- the add file name
#The above two steps are equivalent toEcho "" | # file name to create a new file git hash file name - object - w # Mr Into git object git update - index - add - cacheinfo generated git object corresponding to the hashCopy the code

Form all the contents of the staging area into a tree object (build tree object) for a version snapshot

Git write-tree # will return the hash of the version snapshot
#According to the versionhashView the type of the version snapshotGit cat - file - # t ff75343fd58cff0477965bf65e2bab1e90fe1ab5 tree typeCopy the code

Query the status of the staging area

Note: files in the staging area are always incremental, == files in the staging area are not added or subtracted by branch unless you switch branches in a later high-level command

git ls-files -s
#Git write-tree does not clear the staging area
Copy the code

Example Query the file to be deleted

git ls-files --deleted
Copy the code

Add a tree object to the staging area, and then build to generate a new tree object (form parent tree object)

Git read-tree --prefix=bak git read-tree --prefix=bakCopy the code

Question:

In addition, the information about the version snapshot is not clear, so you cannot obtain the snapshot when, why, and who saved the snapshot

Tree objects can track changes in the contents of multiple files (Git objects), and they can also be stored in a staging area, and then form a version snapshot of the entire project when needed. Each tree object is a complete version snapshot

Submit the object

Creating a submission object

#When the submitted object is first createdEcho instructions regarding the submitted need | git commit - object hash tree tree
#When the submission object is created again, you also need to specify the parent submission object so that when you view the submission object's information, you know who its parent isEcho instructions regarding the submitted need | git commit - object hash tree tree - p father submit the hash objectCopy the code

Submit object is an object to the tree for package and then adding some information about the tree object (author, submission time, etc.), this step is just the tree object further beautification, because every version of the project requires version snapshot and its detail, so each submission object is a complete version of the project (more than the tree object description information only)

Common Linux Commands

Echo 'MSG' > test. TXT # create a file and add the contents of echo to mkdir # create folder CD # change path PWD # show current path ls # list all files in current path ll # list all files in current path and their details find path # List all files and directories in current path and their descendants find path -type f # Rm # delete files mv # rename files cat # View file contents vim # Edit files using the vim editor
## # # # # # # # # # # # # # # # # # # # about simple editor vim # # # # # # # # # # # # # # # # # #I Enter the edit mode, press ESC and enter: start to enter various VIM commands (used to save or exit the ViM editor). Forced exit wq After the modification, exit set nu and add the line numberCopy the code

Git daily Use (Git high-level commands)

Adding files to Staged

Git add * / file/directory # commit workspace changes to staging
#The preceding commands are equivalent to executingGit update-index [--add] --cacheinfo file/directory # Extract git objects from the repository and put them into stagingCopy the code

Commit the files in the staging area to the repository to create a version snapshot

Git commit -m
#The preceding commands are equivalent to executingGit # write - tree spanning tree get hash value object echo 'comment' | git commit - tree, a tree object's hash value git commit - a - m # in the repository has the same name of the file, With this command, you can skip the staging area (automatic git add) and write comments and commit to the repository. This is equivalent to git add + git commit git commit #

## # # # # # # # # # # # # # # # # # key # # # # # # # # # # # # # # # # # # # #Git commit -- Amend # You can commit the files in the current staging area, but a new version (commit object) is not generated to modify the last commit
#Example:
#When a file was missed or passively modified from a file added to staged memory, two objects with the same name in different states (Modified and unStaged) are generated in staged memory and accidentally committedGit test. TXT git git status Git commit-m "# was accidentally committed into the version library
#Best practices:
git add ./
git commit --amend

#The staging area is then recommitted, replacing the last committed object

## # # # # # # # # # # # # # # # # # key # # # # # # # # # # # # # # # # # # # #
Copy the code

Check the current status of the Git directory

Git status # Check the current git management directory statusCopy the code

Git manages the file status classification in the directory

Not tracking (Untracked)

Has been tracking (tracked)
- Has been staging (staged)
- The modified (modified)
- Submitted (commited)
- Deleted (does)

Compare file changes

#Compare workspace with staging area
git diff

#The staging area is compared with the version library
git diff --cached
git diff --staged

#Workspaces are compared to version librariesGit diff HEAD/hash valueCopy the code

File renaming

#Method 1Git add newFileName # Commit the file changes to the staging area git commit -m "# commit the rename operation to the repository#Renaming the file is equivalent to doing these things
#1. Rm deletes the old file
#2. Create a new file
#3. Add the contents of the old file to the new file

#Mode 2(Simplified Operation)Git mv oldFileName newFileName ##Git mv is equivalent to Linux mv + git addGit commit -m "# commit the renamed file from the staging area to the repositoryCopy the code

File deletion

Git add./ git add.
#The above operations are simplified to (simplified operations) using git commandGit commit -m"
#Git rm <=> rm fileName + git add fileName
Copy the code

View submission records of version snapshots

Git log -- git log -- git log -- git log -- git log -- git log -- git log Reflog # used when the bash window has closed and you need to bring up the previous version commit recordCopy the code

Git branch

If you suddenly need to add a new feature to a project, the best practice is to make a complete copy of the project and write the new feature in that copy. Rather than just coding new functionality in the original project because it’s not safe to do so, that’s the idea of branching

A git branch is essentially a copy of a commit and a name for that commit. Switching a branch is essentially switching the HEAD pointer to a branch ==. The HEAD pointer always points to the latest committed object for a branch. The default HEAD pointer object points to the latest commit object for the Master branch

View the branch list (including all branches)

Git branchCopy the code

Create a branch

# Create a branch and point it to a specific commit objectCopy the code

Switch branch

Git checkout -b git checkout -bCopy the code

Create & switch branches

Git checkout -b branch nameCopy the code

Delete the branch

#Deleting a branch requires switching to another branch firstGit branch -d branch name # Delete a branchCopy the code

View the last commit for each branch

git branch -v
Copy the code

Best practice for switching branches: Commit the current branch every time before switching branches, making sure the status is clean

Best practice reasons:

First we need to know that switching branches means three operations:

To change the HEAD pointer, switch the HEAD pointer to the corresponding branch
Modify the staging area
Modifying the Working directory

If before switching branches, the current branchstatusIt’s not clean but if you still switch branches, two things happen(Pit daddy)

The current file was never added to the repository (COMMIT) and is completely new, eitherUntrackedorStagedCauses files that have not been stored in the repository to be brought into the branch to be switched to (contaminates the branch to be switched).

The current file is already added to the (COMMIT) repository, and the state can only beModified stateGit prevents us from branching

Merging branches

Git merge branchesCopy the code

View all branches that have been merged

git branch --merged
Copy the code

Branch merging creates conflicts

Several modes of branch merging and possible conflicts:

Fast-forward mode: Because there are only additions and subtractions between branches (version lines are straight), Git directly merges branches (old ones) into branches (new ones) specified by the merge
Auto – merging mode: But Git uses auto-merging to merge the conflicting contents in the A file. We simply need to merge and commit the conflicting contents in the A file

Configure an alias

When a command is difficult to remember or lengthy, you can configure an alias for the command to simplify operations

Create the alias

Git config -- location alias. alias' command 'Copy the code

To delete an alias

Command mode

Git config --unset alias The aliasCopy the code

Delete the alias in the config configuration file corresponding to the location

Example:

Git config --global alias.st 'status' git config --global alias.st Git config --local alias. GCM 'commit -m' git config --local alias. GCM 'commit -m'#Run the GCM'comments'Git commit -m'comments'
Copy the code

== Recommend several useful command ==

git config --global alias.lol "log --oneline --decorate --graph --all" git config --global alias.lg "log --color --graph  --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"Copy the code

Git temporarily hides the workspace

The git Stash command is used when you are halfway through working on a branch and suddenly need to make an urgent switch to another branch, but you don’t want to create a commit object (as a version) from the branch where you are currently working to switch to the target branch

The git stash command saves the pending changes in the staging area on a stack

Git stash list # See all stash stacksCopy the code

You can use the following command when you need to resume the work you just hid when you are back on the branch of the hidden workspace

Git stash apply # Apply the hidden workspace at the top of the stack and do not remove the git stash record drop stash record (stash@{num}) # Remove the specific Git stash record git stash pop # Applying the hidden workspace at the top of the stack removes the Git Stash record#Pop is equal to the apply + drop
Copy the code

Git time machine

Workspace: Undo file modifications in the working directory, in two cases

If only the workspace is modified and no add is added, the most recent submitted object is undone
If you modify workspace for the first time -> Add to staging area -> Modify workspace again, undo state back to staging area (Workspace first modified)

Git checkout -- fileCopy the code

Staging area: Recall a staging area specific file to the workspace

Git reset HEAD file
#The above command is equivalent toGit reset --mixed HEAD file # --mixed is the default and optionalCopy the code

== Path reset Principle :==

reset --mixedCommand: HEAD and branches are moved, repository and staging are rolled back to the specified version, workspace remains unchanged
But because you specify a specific file rollback (path reset), Git cannot roll back an entire version just because a file is being rolled back
Therefore, the HEAD and branch will not be moved under the reset path, the version library will not be rolled back, the staging area will be rolled back before the specified version add, and the workspace will remain unchanged

File withdrawal from staging workspace using path reset principle:

Git reset --mixed HEAD file name: HEAD and branches do not move, repositories do not roll back, and working directories remain the same
The staging area will change, but it will change to the current version, so it will still be the same but will go back to before the current version of Add
At this time, the conditions of three areas are as follows: Work area 2 Modified/ => Temporary storage area 1 un> Version library 1

Version library: Overwrite the latest commit object of the version library (when the latest commit object has an error)

Git commit --amend # recommit the staging area (if the staging area is empty). The repository does not add new commits but changes the last one
#The above command is equivalent to
git reset --soft HEAD~
git commit -m ''
Copy the code

To change the current submission object, usegit commit --amendYou can commit the current staging file without generating a new version (submit object),Instead, replace the latest version (submitted object)== Comments used for COMMIT are incorrectly written and files in workspace and staging are not committed ==

Go deep into Git time machine –reset command

Git reset –soft: the version library returns the specified version (submitted object), == the difference between the HEAD and the version library is added to the staging area, and the workspace is not modified ==

== Operation HEAD, branch ==

#HEAD~ represents the last commit committed by the current branch, and each ~ represents the previous commit 
#Multiple previous HEAD~ digitsGit reset --soft HEAD~ / hash # Rollback the version to the specified versionCopy the code

Git reset — Mixed: Version libraries and staging areas fall back into a provisioned version (commit objects), staging areas are in an Unstaged state (before Git Add), and workspace == will not be modified

Operation HEAD, branch, staging area ==

Git reset [--mixed] HEAD~ / hash #Copy the code

Git reset –hard: The repository returns the specified version (the committed object), modifying the workspace and staging

Operation HEAD, branch, staging area, workspace ==

Git reset --hard HEAD~ / hash # rollback to the specified versionCopy the code

Hard and checkout are the same.

All modify the staging area, workspace, HEAD

Different:

Checkout only moves the HEAD, –hard moves the HEAD and branch together
Checkout will check the working directory to make sure that the files are not lost. –hard will replace the working directory completely and risk data loss

Git checkout: Git checkout path

Reset the staging area and workspace
Resetting the workspace

Git Checkout Hash file name#Reset the staging area and working directoryGit checkout -- name <=> git checkout -- name <=> git checkout -- name#Resetting workspace only
#If the staging area is clean, the working directory is rolled back to the most recent committed object
#If Staged staging areas (files were added) were then modified, roll back the working directory to the staging version
Copy the code

Git time Machine – Use reset to go back to the future

When using git reset –hard HEAD~~ to go back to the past version,git log –pretty=oneline will not be visible before the rollback commit

You can usegit refklogSee all the complete operations for this warehouse

Find the hash for “future commits “(no rollback previous commits are visible) and go back to the future version by git reset –hard the hash for future commits

However, because reset –hard is dangerous for data to be deleted without recovery, the best practice would be:

Create a branch on future releases
Perform related operations and write code on this branch
When done, switch to the master branch to merge with the “future version” branch

Tag the submitted object

Git can tag historical commits as important

Git tag tag name [HEAD] / hash # Create a tag for a specific submission object git tag -d tag name # Delete tag git tag # List all tags git show tag name # Display details about the submitted object corresponding to the tagCopy the code

Check out tags: This can be modified for previously tagged submission objects

Git Checkout tag # git Checkout tagCopy the code

Check out tags in a split header mode, where the HEAD does not point to any branch

At this point, we need to create a branch in the check tag, and then add, delete, change, check, etc

Git checkout -bCopy the code

Collaborative development of Git remote repositories

Since the transmission between the local Git repository and GitHub repository is encrypted through SSH, the communication between GitHub and the local repository needs to be encrypted, which requires us to generate the secret key

In the user’s home directory, check whether the. SSH directory exists. If so, check whether the id_rsa and id_rsa.pub files exist in the directory

== If.ssh is not available or the directory file is missing, we need to manually generate the secret key ==

Ssh-keygen -t rsa -c "email address"Copy the code

Then copy id_rsa.pub to Github –> Settings –> SSH and GPG keys –> New SSH key

Remote trace branch

Remote trace branches are branches that record the status of remote branches. Named remote/branch, they are read-only, non-removable local branches that move only when git fetch is used to pull the latest state of the remote branch

The local Origin /HEAD remote trace branch represents the latest version in the remote library

Although not very useful, Git allows you to change the direction of the default remote branch

Git remote set - head < > remote library name - a | - auto # based on the current remote library to automatically determine the git remote set - head < > remote library name - d | # -- delete to delete the default branch of remote library git remote Set-head < remote library name > < local branch name > # set the branch as the default branch of the remote libraryCopy the code

To be sure, it took me ages to find one (really ages).

Set-head is documented in git-remote documentation.

set-head

Sets or deletes the default branch (i.e. the target of the symbolic-ref refs/remotes//HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify origin/master.

If the set-head command is used to specify that the remote default branch is master, then origin is equal to origin/master

Let’s look at the application after I understand ==

Upload two branches of an existing local repository into an uninitialized remote repository, which will then initialize and generate corresponding remote branches

The initial experiment was my idea

This experiment confirmed my idea

One last experiment, and the conclusion was drawn

When a new branch is pushed to the remote repository for the first time that the remote repository does not have, the remote trace branch is generated locally and the remote repository generates the remote branch

Git push origin dev # git push origin dev # git push origin dev # git push dev # git push dev # git push devCopy the code

The local remote trace branch is also not automatically updated when the remote trace branch is deleted by the member. We can query/clear the local remote trace branch (the remote trace branch has been deleted but the local remote trace branch still exists) by using these commands.

Git remote prune --dry-run git remote prune --dry-run Clear useless remote trace branches locallyCopy the code

Example: Team member 1 deleted the issue branch of the remote warehouse. After a period of time, team member 2 wanted to see if there was anything interesting about the remote branch. As a result, a pull discovery error was reported: the remote branch did not exist. After asking others, they find that the remote tracing branch has been deleted long ago. Therefore, they run the command to delete the local remote tracing branch

Git remote prune Origin git remote prune OriginCopy the code

Remote branch

A remote branch is a normal branch on a remote repository

Tracking branch

The tracking branch is the local branch generated on the remote tracking branch or the existing local branch is associated with the remote tracking branch to form the tracking branch. The tracking branch can be regarded as the close combination of the local branch and the remote tracking branch (as an integral whole).

== In summary, we can think of ==

Local branch + Remote trace branch = Trace branchCopy the code

In this way, you can directly use git push and git pull commands in the local branch to operate on the remote branch, instead of using the remote trace branch as a medium

When we clone a repository, the local branch will be master and origin/master, and this ==master is a trace branch == by default, Git push

Merge an existing local and remote trace branch into a trace branch This operation requires that both the local and remote trace branches already exist, otherwise an error is reported

Git branch --set-upstream -- to=<upstream> <branch
#The above command can be abbreviated asGit branch -u <upstream> <branch# git branch -u origin/master master <=> git branch -u origin/master
Copy the code

Example: Create the trace branch dev and origin/dev as the trace branch => make dev the trace branch

git branch --set-upstream-to=origin/dev dev
Copy the code

== On the first push to the remote repository ==, “merge” the existing local branch with the remote trace branch (automatically created locally when pushed) into the trace branch this operation does not require the existence of the remote trace branch

Git push --set-upstream (" upstream"
#The above command can be abbreviated asGit push -u < repository alias > < branch name >Copy the code

For example, you can push an existing local branch problem to the remote repository. The requirements are as follows: Create a remote trace branch origin/ Problem locally and a remote branch problem in the remote repository

git push --set-upstream origin problem
git push -u origin problem
Copy the code

## # # # # # # # # # # # # # # # # # # summary # # # # # # # # # # # # # # # # # # #

git push -u origin dev
#This is equivalent to the following two commandsGit branch -u origin/dev dev $git branch -u origin/dev dev
#The corresponding non-shorthand notation

git push --set-upstream origin dev
#This is equivalent to the following two commands
git push origin dev
git branch --set-upstream-to=origin/dev dev

## # # # # # # # # # # # # # # # # # # summary # # # # # # # # # # # # # # # # # # #
Copy the code

Create a new local branch to merge with the remote trace branch as the trace branch

Use scenario: The remote repository has the master and dev branches, == Team members will clone the remote repository only from the master branch == But all members need to be developed under the dev branch, so simply create the dev branch locally and change it into the trace branch together with the remote trace branch == note: If the remote branch already has multiple branches, the first clone will generate the corresponding multiple remote trace branches locally ==

Git checkout -- b -- git checkout -- b -- git checkout
#The above command can be abbreviated asGit checkout --track remote trace branch # This will create and switch to a local branch with the same name.Copy the code

Example: Remote branch has issue, the new partner today needs to solve the problem (need to pull the remote branch)

git checkout -b issue origin/issue
git checkout --track origin/issue
Copy the code

Cancel trace branch

Git branch --unset-upstream <branchCopy the code

Example: Cancel the local bug tracking branch

git branch --unset-upstream bug
Copy the code

Common commands for remote collaboration

Check whether all branches are trace branches

git branch -vv
Copy the code

Associate a local repository with a remote repository

Git remote add < origin >Copy the code

Disassociate the local repository from the remote repository == This operation does not affect the remote repository ==

Git remote rm Specifies the alias of the remote repositoryCopy the code

Remote repository renames

Git remote renameCopy the code

Clone a clone repository. The default alias of the clone repository is Origin. If the clone repository has multiple remote branches, only the master branch will be cloned

Git Clone remote repository URLCopy the code

Push the local branch to the remote repository

Git push < remote host name > < remote branch name
#For example, git push < remote repository alias > < branch name > is a simplification
#Git push < remote repository alias > < local branch name >:< remote branch name >
#Git push origin Hello :world git push origin hello:worldGit push --set-upstream (" upstream ") git push --set-upstream (" upstream"Copy the code

Synchronize the remote trace branch locally with the remote branch update for the remote repository. The branch update of the remote warehouse cannot be automatically acquired by the computer side of the project collaborator (remote trace branch will not be automatically generated locally), so it needs to be fetched manually (the local representation is to generate remote trace branch).

Git fetch <remote> <branch>Copy the code

After the branch acts as a trace branch, updates to the remote repository are fetched to the local branch

Git pull < remote repository alias >Copy the code

To turn an existing local branch into a trace branch, require that there is a remote branch with the same name as the local branch

Git branch --set-upstream =< upstream >Copy the code

Change an existing local branch to a trace branch, no remote branch yet, but then create a local remote trace branch with the same name, remote library create a remote branch with the same name

Git push --set-upstream < upstream >Copy the code

View aliases for remote repositories (little information)

Git remote show git remote show git remoteCopy the code

View aliases and urls used by remote repositories (in information, commonly used)

git remote -v
Copy the code

View information about the remote warehouse (much information)

Git remote showCopy the code

Deleting a Remote Branch

git push <remote> --delete <branch>
#Git push origin --delete dev
Copy the code

Resolve the conflict

There are two types of conflicts: == Push and pull operations on local and remote libraries ==:

Case 1: When member 1 and member 2 modify the same file A locally, one member pushes to the remote library, and the other member also pushes to the remote library, conflict case 1 occurs

Member 1 Modifies the conflict1. TXT file locally and pushes it to the remote interface

Member 2 also makes changes to the conflict1.txt file in the local directory, and when pushed, conflicts occur

Conflict 1 solution: first pull the update of the remote library, resolve the conflict generated by the corresponding file, it can be pushed normally

Case 2: Member 1 modifies file B locally and has committed to the remote library. Member 2 also performs tasks on file B but this task relies on the changes made by member 1 to file B, which requires member 2 to update the file locally while editing file B. So there’s conflict

Member 1 modifies file B locally and has committed to the remote library

Member 2 also does work on file B but that work depends on changes made to file B by member 1

Solution to conflict situation 2: put the local change temporarily stash, then pull the remote library update and resolve the conflict manually, then it can be pushed normally

Pull Request

As we explore the Github/Gitee open source world, if we find some interesting projects. We might want to do a self-definition

So how do you make the next library easy and natural

Git cloneCopy the code

But there is a significant problem with this: == When we want to push a remote library after making a custom change to it, we are prompted that we have no permissions ==. This is because our Clone library belongs to someone else’s team. Without being invited to be a member of the team, we certainly can’t use the operation of adding, deleting and modifying warehouse code such as push. If everyone can do this, there will be chaos in the world

So in order to have full access to the warehouse, the simplest way is:

Clone someone else’s project repository
Clone down the local repository (directory).gitDelete folder
thengit initInitialize the warehouse
A mealgit addAfter the operations such as
After creating a remote repository under our Github/Gitee account, push the project that has been “private” so that we can modify it at will

Github/Gitee gives you the ability to quickly clone a copy of someone else’s project to your own account, called Fork

github Fork

gitee Fork

Test using Fork

The ability to customize and modify open source projects is just one of the features derived from the open source movement today. The Pull Request feature derived from the open source movement has a lot to do with it. It allows a group of experts to contribute to a project, and everyone can make a Pull Request to the project owner after making changes to the project, so that the project can develop better

When the code in the derived project is modified, the Pull Request can be made to the source project

Project authors can see Pull Requests that others have asked for

Can you adopt someone else’s code on a PR page or fight someone else online?

At this point, you’ve completed a Pull Request

Open source authors can even Request support from people who have made Pull requests

PR can be closed and opened at any time before Merge

Whether the project author can turn off PR depends on whether you allow the project owner to do it when you raise PR

If the project author turns off PR, does that mean he has been rejected

Write in the last

Off and on to learn a week, write is also rory wordy bar.

But strive for detailed, can give yourself as a reference in the future

Also hope this git study notes can help you

Welcome to point out the wrong place, you can communicate with him if you have any questions

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.

Git study notes (hope to be useful)

Git Learning Notes

Centralized management vs. distributed management

Git folder structure description

Git initialization

Initial Git configuration

Git’s three regions and three types of objects

Git object

The tree object

Submit the object

Common Linux Commands

Git daily Use (Git high-level commands)

Git branch

Branch merging creates conflicts

Configure an alias

Git temporarily hides the workspace

Git time machine

Go deep into Git time machine –reset command

Git time Machine – Use reset to go back to the future

Tag the submitted object

Collaborative development of Git remote repositories

Remote trace branch

Remote branch

Tracking branch

Common commands for remote collaboration

Resolve the conflict

Pull Request

Write in the last

Git study notes (hope to be useful)

Git Learning Notes

Centralized management vs. distributed management

Git folder structure description

Git initialization

Initial Git configuration

Git’s three regions and three types of objects

Git object

The tree object

Submit the object

Common Linux Commands

Git daily Use (Git high-level commands)

Git branch

Branch merging creates conflicts

Configure an alias

Git temporarily hides the workspace

Git time machine

Go deep into Git time machine –reset command

Git time Machine – Use reset to go back to the future

Tag the submitted object

Collaborative development of Git remote repositories

Remote trace branch

Remote branch

Tracking branch

Common commands for remote collaboration

Resolve the conflict

Pull Request

Write in the last

Related Posts

Introduction to Python Coroutines & Asyncio

Keep Hexo continuously deployed with flow.ci

How does ApiPost send a Post request using the return parameter of another interface as the Token of the current interface