Welcome toTencent Cloud + community, get more Tencent mass technology practice dry goods oh ~

This article was published in the cloud + community column by Tencent Worker Bee

What is Git?

Git is a distributed code management container that keeps the same code locally and remotely. Git repository consists of three parts: native code, cache, and commit history. This is the essence of almost all operations, but for the sake of simplicity, I will not focus on this part of the article. Let’s get straight to Git’s common operations.

What are the general operations of Git?

Let’s take a look at some of the general Git practices that allow us to handle simple development requirements.

Cloning code

Clone remote code

Git clone + git cloneCopy the code

Strategies for viewing the local code state

// The state of the local warehouse can be explicitly displayed
// Which files have been changed and which files have been committed to the machine
// And some instructions.
git status
Copy the code

Strategies synchronize distal branch changes

// Pull changes to the specified branch
git fetch origin master 
// Pull all branch changes
git fetch 
// Remove all branches that do not exist at the remote end.
git fetch -p
Copy the code

Strategies synchronize remote code changes.

// Git fetch is performed first and then merge is performed
Git pull -r is a git rebase. Git pull is a git rebase
git pull origin master 
git pull -r origin master
Copy the code

Git merge git rebase git rebase git rebase

This section mainly introduces the code cloning, synchronization of remote code changes related operations. Next, let’s take a look at some operations on native code.

Operating the commit

The first step is to clarify the concept that each COMMIT is a complete code state, uniquely identified by a commitID.

In a sense, Git maintains a commitID tree that holds code in different states. So any changes you make to your code will eventually be reflected in the COMMIT.

✦ new commit

// Add the file to the cache and commit it to the local repository
git add files
git commit -m 'Submit notes'
Copy the code

✦ revoked the commit

// Commit records are rolled back, code is not rolled back
git reset b14bb52

// All commit records and code are rolled back
git reset --hard b14bb52

// Roll back some code files
git checkout -- files
Copy the code

Merge COMMIT Merge COMMIT, essentially merge two copies of code in different states.

Git provides two ways to merge a commit
git merge master
git rebase master
Copy the code

Git rebase and Git Merge Merge is a merge that adds a commit to the master after two branches process a conflict. Rebase is to append the commit record on someFeature branch to the main branch. It is worth noting that at this time, his commit has actually changed.

Git merge handles conflicts more directly, while Git rebase ensures clear commit records.

When you merge a COMMIT, conflicts usually occur. You can search globally for special characters such as <<<, find where the code needs to be processed, and then take a hard look at which parts of the code to keep.

Branching is essential in teamwork. So how do you operate on branches?

Operating branch

A branch is a pointer to commitID, you can go to.git/refs/heads.

In general, we suggest that branches can at least clearly mark the function name, and it would be better if they can mark users, such as Qixiu /feature.

Follow a Strategy to View a branch

You can see both the local branch and the remote branch at the same time. With git fetch -p introduced above, you can view the latest branch information as soon as possible.

Creating a local branch for strategies is simply creating a pointer to a commitID.

// git branch qixiu/feature + git checkout qixiu/feature
// Add a new branch qixiu/feature from the current branch
// In general, we should add branches from the master or other stable branches
git checkout -b qixiu/feature // Create a new branch
git checkout qixiu/feature // Switch branches
Copy the code

Removing a local branch for strategies is actually removing a pointer to commitID.

// Delete the local branch. If there is unmerged code in the local branch, it cannot be deleted
git branch -d qixiu/feature
// Forcibly delete the local branch
git branch -D qixiu/feature
Copy the code

Create a Remote branch Usually we create a remote branch by creating a local branch and then updating to a remote branch

git push origin qixiu/feature
Copy the code

Follow a strategy to delete a remote branch Similarly, we remove a remote branch by updating to a remote branch

Git push Origin -d qixiu/feaure
git push origin :qixiu/feature
Copy the code

Just to summarize

This may be a bit scattershot, but here’s a quick summary of some of the most commonly used operations:

git status // Check the local code status
git add files // Add code to the cache
git commit -m 'Comments on submission' // Commit the code to the local repository
git checkout -b branchName // Do not add -b to switch branches
git fetch -p // Synchronize the status of the remote branch
git pull -r origin branchName // Fetch the remote code locally and rebase the code
git push origin branchName // Update local code to remote
Copy the code

The above commands are sufficient for routine operations. More complex scenarios will be described later

Based on the basics, how can Git be used for collaboration in a real project?

What are the best practices for Git?

Git has some mature development processes. There are two mainstream ones: branch based development and GitFlow development. I prefer the former to the GitFlow development process for large and complex projects. Next, take a look at these two collaboration modes.

Collaboration patterns based on functional branching

The branch based development process is a simple one: the branch is used to host the development of the function, and when the development is finished, it is merged into the Master branch. Its advantage is that it keeps the master branch clean, while keeping the branch code logically centralized and CodeReview easy.

Branch naming convention

The recommended format is ownerName/featureName. In this way, it is not only easy to know the function of branch coverage, but also easy to find the branch owner. It is also convenient to clean up branches later.

The development process

Show a new branch from the master

git checkout -b qixiu/newFeature
Copy the code

Strategies for developing some new features, then submit suggested submission code more often to a local repository for greater flexibility to save or undo changes. In addition, clear comments are recommended to ensure the clarity of the submitted logs.

git status
git add files // Select documents that need to be submitted, or all of them
git commit -m 'Submit notes'
git push origin qixiu/newFeature
Copy the code

Strategies if your functionality is developed, you can initiate a CodeReview process strategies if the code tests pass, merge it into the master, and then go live

// Redundant versions are merged into master
git checkout master 
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // Handle conflicts
git checkout master
git merge qixiu/newFeature
git push origin master

// Compact version merged into master
git checkout qixiu/newFeature
git pull -r origin master // Update the master code and rebase to handle conflicts
git push origin master // Update the local code to the remote end
Copy the code

A few caveats: Don’t merge code in master, it’s important to keep master usable. Ensure that the correct operations are performed in the correct branches. Whether it’s dealing with conflicts or updating remote code, be in awe.

At this point, a normal development process based on functional branching is complete. Let’s look at another development process.

GitFlow development process

GitFlow is much more complex than the functional branching development process described above and is better suited for large, complex projects. It defines a strict branching model around the project release process, and all development processes follow this strict branching model. This model specifies the roles of each branch and how they communicate.

Let’s start by looking at the agreed branches of the GitFlow development process and what roles they play.

Strategies Master branch: Store online version codes and make it easy to copy codes. Follow Develop branch: Use to integrate Feature branches. Follow a strategy Feature branch: A branch for a function that splits from the Develop branch and merges back to the Develop branch when the function is complete, not interacting directly with the Master branch. Follow Release branch: Usually corresponds to an iteration. After all the functionality of a Release has been merged into the Develop branch, cut out a Release branch from Develop. This branch does not add new requirements, but fixes bugs, improves documentation, and so on. Keep in mind that once the code is published, it needs to be merged into the Master branch as well as into the Develop branch. Strategies for Hotfix Branch: Strategy Hotfix branch, the only branch that can be cut from the Master, once repaired can be merged into the Master branch and Develop branch.

As can be seen from the functions and conventions of each branch, it is not suitable for small-scale applications due to multiple processes and constraints. Of course, GitFlow has some auxiliary tools that can automate these tasks and also be very helpful for large projects.

I’ve covered the basics of what Git does, and then introduced you to the two main workflows. Let’s take a look at what special Git techniques are worth mentioning.

What are the tips for Git?

In addition to basic code management, there are a few tricks you can use to make your Git operations stand out.

Git reflog to check the operation records

I have to mention this first, because it has saved my code several times

If you look closely at the image above, reflog records all your Git command operations, which is a great help for undoing some unaccountable scenarios or rolling back misoperations.

Imagine a scenario where you use Git reset — Hard commitID to roll back local development code to a previous version without pushing it to the remote end. How can you retrieve the lost code? If you use git log to view commit logs, you will not be able to retrieve discarded commitiDs. Git reflog, on the other hand, keeps a detailed record of your commitID for every operation you do, making it easy for you to undo the current operation and recover the lost code. Of course, if you don’t commit any of your missing code, congratulations, your code is really lost.

Compress commit records

This is also a very useful feature. As mentioned earlier, we try to maintain a high frequency of code submission during development, so as to avoid accidental code loss. But we don’t want to have too many redundant commit records when we actually merge code, and when Rebase merges code, every commit is processed, which can sometimes lead to redundant work. So, compressing the log without leaving it behind makes the COMMIT record clean and easy to merge code with rebase.

So, how do you compress commit records? Follow git log find start commitID Follow git reset commitID Do not repeat git add && git commit strategies git push -f origin branchName with — Hard follow strategies git add && Git commit strategies git push -f origin branchName Follow merges into master, then updates the remote master.

There are two ways to compress logs: git commit –amend: add a commit to the last commit. Git rebase -i: Clean up messy history with interactive rebase that provides control over branch commit.

In practice, all three types of log compression are excellent. Git reset is simpler and Git rebase-i is more subtle.

Git rebase, merge code

Git merge git rebase git rebase git Rebase Git rebase can make your commit records very clean, whether it is on line rollback or CodeReview. However, it is a potentially dangerous operation and must be used with caution. Git merge is safer and simpler. However, some redundant COMMIT records are added.

Here’s a brief description of the rebase merge process and considerations. See below

There are three points to note: Follow strategies for rebase First find the common ancestor node fetch the submission record of pay branch from the ancestor node, then follow strategies for Rebase to master branch The commitID after follow strategies rebase has actually changed, especially the third point, often make people misoperate, So be careful.

Imagine what would happen if we rebase master branches frequently during development.

When you rebase your master, your local D’s become D’s, and your local branch’s commit record is already pretty bad because it has to be consistent with the remote pay branch.

Also, never use rebase on a public branch!!

So, for security, teams can consider merging.

Pull Request, convenient CodeReview

Git not only provides help with code hosting and development, but also provides similar functionality for code review. When we are finished with the functional branch, we can make a pull Request and select the two branches to compare

It creates a pull request and assigns people to review the code. In general, teams should encourage cross-review, and when it comes to common code, be sure to have it reviewed.

Git hook, git life cycle

Git operations have a life cycle of their own, and there are things you can do to automate them.

Two simple examples: Strategies for pre-commit we can do ESLint strategies for post-commit, we can do continuous integration using a tool like Jenkins

Of course, there are more declaration cycles, see Git hooks

Git submodule && Git subtree, which manages third-party modules

These two commands are typically used to manage common third-party modules. Some common underlying logic, middleware, and some common business components that may change frequently. Of course, there are differences. Git submodules are used to manage common modules or underlying logic for one-way updates. Git subtrees are particularly good for managing portions of reusable logic that require bidirectional updates. For example, some business component code that needs to be reused. In my previous practice, I also used subtree to manage build system logic.

Git alias simplifies git commands

You can simplify the git commands you need to enter by configuring git aliases. Git subtree requires a long git command. You can configure the.git/config file to do this.

// git stpull appfe demo/xxx
// git stpush appfe demo/xxx[alias] stpull = ! git subtree pull --prefix=$1 appfe $2\ && : stpush = ! git subtree pull --prefix=$1 appfe $2 \
        && git subtree split --rejoin --prefix=$1 $2 \
        && git subtree push --prefix=$1 appfe $2 \
        && :
Copy the code

What’s the summary?

Git strategies for Cloning code, Executing Commit, executing branch, etc. There aren’t a lot of Git commands that you can run on a regular basis. See part 1 for a quick summary.

Second, Git development process is introduced. This section mainly introduces two main development models: a light development process based on functional branches and a GitFlow development process suitable for complex projects. The two strategies have their own application scenarios, the former is enough for routine use.

Finally, some Practical Strategies for Implementing Git strategies are introduced, including reflog strategies, compressed logs, Strategies for rebase, Strategies for doing codeReview using pull Request, Strategies for automation using Git hook, etc.

reading

Successful Spark grayscale publishing on 100,000 level nodes

EMR common FAQ

The mon of Ceph deployment is 0.0.0.0

Machine learning in action! Quick introduction to online advertising business and CTR knowledge

This article has been authorized by the author to Tencent Cloud + community, more original text pleaseClick on the

Search concern public number “cloud plus community”, the first time to obtain technical dry goods, after concern reply 1024 send you a technical course gift package!

Massive technical practice experience, all in the cloud plus community!