[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 branchstatus
It’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, either
Untracked
orStaged
Causes 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 be
Modified state
Git 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 --mixed
Command: 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 --amend
You 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 refklog
See 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)
.git
Delete folder - then
git init
Initialize the warehouse - A meal
git add
After 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