Git concept introduction, commonly used commands and workflow arrangement with pictures

First, attach a Git cheat sheet as a start for easy reference: https://education.github.com/git-cheat-sheet-education.pdf

Introduction to Git

Everyone must be familiar with Git, let me introduce it again symbolically: Git is a version control system , in other words, it can take named snapshots (ie save) of our code base throughout the development process, and when problems occur , we can easily roll back to any such saved state. If we write the wrong code, without Git, we need to find out what we changed and restore it manually, which is time-consuming and error-prone. With Git, if we save when our code is running fine, we can restore that state with a single command. We can also document our work step by step for each other. Git also has some functions related to collaboration, such as branch management, which can be well used for the development of new features and bug fixes.

Git workflow and common commands:

First of all, we need a picture to thoroughly understand the relationship between Git and GitHub installed on our system. We use each command to represent where to send the code. Next, when introducing various concepts and commands, please refer to this picture, and it will be very clear what we are doing every step of the way.

concept:

Git Repository : Git repository (Git Repository) is a database containing files and their historical versions. In the picture above, we have a warehouse localrepo on Local (local computer), which will be stored in the . Because in fact, you don't need to operate it directly). A remote repo stored remotely or online (such as on GitHub) is called a remote repository. Our git push and git pull happen between the local warehouse and the remote warehouse.

Working directory : The working directory is the latest code under the branch you are currently checking through git, that is, the far left of the above picture, the file content displayed in your IDE.

Staging area : The temporary storage area is before creating a Git commit commit, we put the files we want to include in the submission in the temporary storage area. It is equivalent to making a "buffer", not committing any changes.

Common commands:

git clone <remote warehouse link> : copy a code from the remote warehouse to the local, at this time our local working directory has all the codes, and establishes a connection with the remote warehouse.

git add <file name 1> : Add the changed file to the temporary storage area (corresponding to the understanding in the above figure).

git commit -m “<commit information>” : Submit the contents of the temporary storage area to the local warehouse. The submission will come with a submission id and submission information. The submission information is customized by you to describe the modification and change this time.

When performing git commit, try to commit a single modification separately, commit frequently and in a timely manner and attach a clear introduction to the submission information, and avoid merging a large number of modifications into one commit, which will be difficult to track and understand. Then do not submit some automatically generated files, such as the node_modules folder generated by npm install, the target folder generated by mvn site, etc. You can write a .gitignore file to put files that do not need to be tracked by git into it.

git status : Shows which files have been changed and which files are in the staging area.

git log : Display all commit information, etc.

git branch "<branch name>" creates a new branch named <branch name>.

git checkout <branch name> switches to the branch of <branch name>. Through the git checkout -b <branch name> command, if the relevant branch does not exist, it will be created and switched directly.

git push  : Submit local changes to the remote warehouse.

git pull : Get updates from the remote repository and try to merge them into the local working directory.

Workflow in teamwork

fork 与 pull request

Fork can be understood as copying a project to your own account, allowing you to modify the project freely without affecting the original project. A link relationship is maintained between the new project produced by Fork and the original project. This is great if you want to build on an existing project, or if you want to contribute to a project you don't have write access to.

Pull Request (Pull Request): When you make changes in the Fork project and feel that these changes are helpful to the original project, you can initiate a Pull Request. This is to the maintainer of the original project, hoping that they will merge your changes into the original project. After receiving the Pull Request, the original project maintainer can view the modified content, make comments and discussions, and then decide whether to accept these modifications. In team collaboration, using branches and Pull Requests allows team members to work on different tasks without interfering with each other. When the respective tasks are completed, the changes of each branch can be merged through Pull Request, so that all changes can be centrally managed and reviewed.

resolve conflicts merge conflicts

When you're about to accept a pull request, but Github notifies you of a merge conflict, it usually means that your branch contains the same changes as the branch you're merging into. If the conflict is simple enough, you can usually resolve it in the web editor by clicking "Resolve Conflicts" on the pull request page.

Once you have the file open, you should see some conflict markers like ">>>>>branch1" and "<<<<<branch2" in your conflict file. You can manually fix conflicts by removing the conflict markers and the changes you want to discard. Once you have resolved all merge conflicts, you can click "Mark as resolved" to proceed with the pull request.

Learn by doing:

This is an online web page for visual exercises to operate git: Learn Git Branching

This webpage looks like this. It will guide you through Git operations from the beginning of git. You can see the current branch changes while operating. It involves the most basic commit, branch, etc., and there are also a series of high-level operations.

Next, let's enter some common commands to see how they actually display for the branch.

git commit

Note that the arrow here does not point in the opposite direction, as c2 is the latest commit change, it "points" to the old state. Git does backtracking somehow in this way.

 git branch newImage, git checkout newImage

 Since it is still in the master branch, git commit will push the master forward at this time. If you want to advance newImage, you should first checkout to newImage and then commit.

Merge and Rebase

git mergeand git rebaseare both ways of merging branches in Git, but they differ in their approach and results.

git merge

git merge The command will create a new commit with two parents: one is the latest commit of the branch you are currently on, and the other is the latest commit of the branch you want to merge. This new commit is called a "merge commit". The advantage of merging is that it preserves the full commit history and context of the branch. However, this approach can also lead to complex commit histories, especially in active repositories.

git rebase

git rebasecommand moves commits from one branch to another. First, Git finds the closest common ancestor of the two branches, then fetches all commits in the current branch since then. These commits are called "patches". Git then checks out the branch you want to apply the patches to, and applies the patches one by one. The advantage of using rebase is that it creates a more linear project history, which is easier to understand. However, this approach also loses some context information (because the original order of commits is changed), and rebasing on a public branch may cause problems because it changes the commit history.

Reset and Revert

git resetand git revertare both commands used in Git to undo changes, but they work differently and for different purposes.

 git reset

git resetThe command is used to undo changes to the local warehouse, which is equivalent to deleting the commit you just made. git resetis a dangerous command as it will change your Git history. If you've already pushed changes to a remote repository, using it git resetmight cause problems. Do not use this command if you are connected to a remote warehouse.

git revert

git revertcommand to undo changes that have been committed to the Git history. This command creates a new commit that reverses the changes made in the specified historical commit. git revertThe advantage of this is that it doesn't alter the existing Git history, so it's a safer option, especially if you need to undo changes that have already been pushed to a remote repository.

 git cherry-pick

cherry-pick allows you to pick any existing commit and apply it to the current working branch. For example, if you are working on your feature branch, but someone made a bugFix to the main branch, you can apply the bugFix to your own branch through cherry-pick. In the above figure, the master has applied the changes of the two commits in another branch to himself.

It needs to be emphasized that each commit node in the graph records changes , not the current latest code status , so we can use cherry-pick to select those changes we want to apply at will. In the same way, the previous git revert is actually submitting a "change" that is completely opposite to the previous commit as a new commit.

summary:

This article introduces Git, a powerful version control system, introduces some basic concept commands, conflict resolution methods, and understands the specific meaning of some operation steps through practice and illustrations. Figuring out these basic knowledge is basically enough for daily study and work. Other deeper principles and advanced operations of Git have the opportunity to explore again~

Update : On the basis of this article, some high-level common operations of git are sorted out: Git advanced advanced operations_TranSad's Blog-CSDN Blog

Guess you like

Origin blog.csdn.net/weixin_44492824/article/details/130592598