This article has participated in the third “topic writing” track at the Diggings Creators Camp. For more details, check out diggings program | Creators Camp

preface

Git is a free, open source distributed version control system designed to handle all projects from small to large quickly and efficiently. Git is easy to learn, takes up little space, and is lightning fast. It goes beyond SCM tools such as Subversion, CVS, Perforce, and ClearCase, with features such as cheap local branches, convenient staging areas, and multiple workflows.

Git is not only a version control system, it is also a content management system (CMS), work management system, etc.

If you have a BACKGROUND in USING SVN, you’ll need to do some thinking shifts to accommodate some of the concepts and features that Git offers.

Git and SVN:

  • 1. Git is distributed, SVN is not: this is the core difference between Git and other non-distributed version control systems, such as SVN, CVS, etc.

  • 2. Git stores contents as metadata, while SVN stores them as files: All resource control systems hide file metadata in folders such as.svn,.cvs, etc.

  • The Git branch is different from the SVN branch: the branch is nothing special in SVN, it is just another directory in the repository.

  • 4. Git does not have a global version number, whereas SVN does: this is by far the biggest feature Git lacks compared to SVN.

  • 5. Git content integrity is better than SVN: Git stores content using the SHA-1 hash algorithm. This ensures the integrity of the code content and reduces repository damage in the event of disk failures and network problems.

Creating a new warehouse

Create a new folder, open it, and execute it

git init
Copy the code

To create a new Git repository.

Check out the repository Run the following command to create a clone of the local repository:

git clone /path/to/repository
Copy the code

If the repository is on a remote server, your command would look like this:

git clone username@host:/path/to/repository
Copy the code

workflow

Your local repository consists of three “trees” maintained by Git. The first is your working directory, which holds the actual files; The second is the staging area (Index), which acts like a cache and temporarily holds your changes. Finally, HEAD, which points to the result of your last commit.

Add and Submit

You can propose changes (add them to the staging area) by using the following command:

git add <filename>
git add *
Copy the code

This is the first step in the basic Git workflow; To actually commit the changes, run the following command:

Git commit -m "Code commit info"Copy the code

Now, your changes have been committed to HEAD, but not to your remote repository.

Push changes

Your changes are now in the HEAD of the local repository. Run the following command to commit these changes to the remote repository:

git push origin master
Copy the code

You can replace master with whatever branch you want to push.

If you have not cloned an existing repository and want to connect your repository to a remote server, you can add it using the following command:

git remote add origin <server>
Copy the code

Then you can push your changes to the added server.

branch

Branching is used to insulate feature development. Master is the “default” branch when you create the repository. Work on the other branches and merge them into the main branch when you’re done.

Create a branch called “feature_x” and switch to it:

git checkout -b feature_x
Copy the code

Switching back to the main branch:

git checkout master
Copy the code

Delete the new branch:

git branch -d feature_x
Copy the code

The branch is invisible unless you push it to a remote repository:

git push origin <branch>
Copy the code

Update and Merge

To update your local repository to the latest changes, perform:

git pull
Copy the code

To fetch and merge remote changes in your working directory. To merge another branch into your current branch (such as master), execute:

git merge <branch>
Copy the code

In both cases, Git tries to merge the changes automatically. Unfortunately, this may not be successful every time, and may lead to conflicts. This is when you need to modify these files to manually merge the conflicts. After making the changes, you need to execute the following command to mark them as successful:

git add <filename>
Copy the code

Before merging the changes, you can use the following command to preview the differences:

git diff <source_branch> <target_branch>
Copy the code

The label

Creating labels for software releases is recommended. This concept has been around for a long time, even in SVN. You can create a tag called 1.0.0 by executing the following command:

1 b2e1d63ff git tag 1.0.0Copy the code

1b2E1d63FF is the first 10 characters of the submission ID that you want to mark. The submission ID can be obtained using the following command:

git log
Copy the code

You can also use fewer of the first few bits of the commit ID, as long as it points to something unique.

Replace local changes

If you make a mistake (which, of course, should never happen), you can replace the local change with the following command:

git checkout -- <filename>
Copy the code

This command replaces the files in your working directory with the latest contents in HEAD. Changes that have been added to the staging area and new files will not be affected.

If you want to discard all your local changes and commits, you can get the latest version history from the server and point your host branch to it:

git fetch origin
git reset --hard origin/master
Copy the code

Practical Tips

Built-in graphical Git: gitk

Git output in color:

git config color.ui true
Copy the code

When history is displayed, only one line of information is displayed for each submission:

git config format.pretty oneline
Copy the code

Interactively adding files to the staging area:

git add -i

Copy the code

That’s all for this post, thank you very much for reading here, if this article is good or a little bit of help to you, please like, follow, share, of course, any questions can be discussed in the comments, I will actively answer, thanks again 😁