Frustrating teammates who don't know Git are no longer acceptable. In order to avoid teaching Git for every project, this essential Git collaboration tutorial for teammates is introduced (pushing an old article, unclear).
Learning Git requires practice, and mastery comes from practice
If teammates don't know Git, it's better not to team up
This article refers to Git Collaboration Tutorial | Crossroads of the Foreign Maze
Introduction
What is a Git Repository? A project is a Git Repository. More specifically, the location of the project folder is the Git Repository. To make a project folder a Git Repository, you need to run the git init command to create a local Git repository (local means on your own computer). Of course, creating a Git code repository doesn't necessarily have to be local, you can also create a Git code repository through the Github website.
What is Git? Git is a version control system that manages file versions of a Git Repository. It saves your operations on the Git Repository. When needed, you can restore historical versions from the operation records.
What is Github? Github is a website for hosting Git Repositories. Users can upload their Git Repositories from their laptops to the Github website, and then download and edit them on desktop computers, or synchronize and collaborate with others (such as in a team project, unclear).
Installing Git Program You can refer to the Git official website https://git-scm.com/ and various major blog websites for installation instructions.
It is recommended to use Git through the command line but it may be a bit challenging for beginners. You can also use graphical user interfaces.
There are many Git GUI (Graphical User Interface) options such as: Github Desktop, Sourcetree, GitKraken, and various IDEs with built-in Git GUIs.
Specific installation instructions are not repeated here, please search on Bilibili and major blog websites.
Starting with clone
Use the git clone command to download the Repository (code repository) we need from Git Repository hosting websites such as Github.
As shown in the figure, this is the link address we need. We only need to use the git clone command, plus the address we copied, to fetch the repository we want.
git clone https://github.com/github/site-policy.git
This code will fetch the official site-policy repository from Github.
If you clone the repository using the command line method, please note that the repository will be downloaded to the current path of the command line. You can use the cd command to modify the path. For specific instructions, please refer to major blog platforms.
If you have the ability, you can configure SSH Key for Github, so that you can clone code repositories using the SSH protocol Again, this is not explained here.
When we have cloned the code repository, it means that we also have a local repository on our own computer that is exactly the same as the remote repository on the Github website.
We call the code repository on our own computer the local repository, and the code repository on Github or other hosting websites the remote repository.
❗❗When you open the local repository on your computer, you may find a hidden folder named .git, and it is important to note that this .git folder contains all the modification records and remote connection information of the repository.
❗❗If you delete the .git folder, the current project will no longer be a repository and will be no different from a regular folder.
Git Code Changes and Uploads
As mentioned earlier, the project folder can be considered as a Git Repository.
For code files, it is inevitable that we will delete some errors and add some features, which involves creating, deleting, and modifying files.
Does pressing Ctrl+S update the code repository? Not exactly.
The Ctrl+S shortcut saves the file, but does not update the Git records. In other words, from our perspective, the code has indeed been modified, but from Git's perspective, the code has not changed.
The same applies to file creation and deletion.
So, how can Git detect file changes?
You need to use the git add command.
git add *
Here, * is a wildcard that applies to all files.
For other usages, you can refer to git add command | Runoob Tutorial or related blog posts on major websites.
Although Git detects your file modifications (the files are in the staging area), it does not generate operation records (the modifications have not entered the local repository).
Since this is the case, how do we update the Git repository?
You need to use the git commit command to commit the changes to the local repository. At this time, "operation records" will be generated in the git log.
git commit -m "my first commit"
Here, -m is a parameter passed to the commit operation, which serves as a summary of this commit.
Commit message template
Refer to conventional commits or Commit message and Change log writing guide - Ruanyifeng's Blog for simplicity and clarity.
For other usages of the git commit command, you can refer to git commit command | Runoob Tutorial and other tutorial materials.
At this point, we have successfully updated the local repository on our own computer
But along with it comes a problem - we have modified the local repository on our computer, but the remote repository on the Github website has not been touched. At this time, the two repositories are inconsistent.
We upload the updated version (the modified local repository) to Github to update the remote repository
This process uses the git push command
git push origin main
After executing the above code, the local main branch will be uploaded and overwritten to the remote main branch.
Refer to git push command | Runoob Tutorial for more syntax details. You can also refer to other tutorial websites.
Git Code Synchronization and Download
When the remote code repository on Github is newer than the local code repository on your computer, you need to download the code.
In this case, you can use the git pull command
git pull origin main
At this time, the remote main branch of the code repository will be pulled down and then update the local main branch.
For more information, you can refer to git pull command | Runoob Tutorial and other resources.
Code conflicts and resolution The following is an example of a code conflict taken from the internet.
<<<<<<<<<<<
A
===========
B
>>>>>>>>>>>
These markers are called conflict markers As shown above, A and B conflict with each other.
IDEs usually automatically recognize conflict markers, highlight the corresponding conflicting code (shown in green and blue in the figure), and provide a shortcut menu for conflict resolution, including options such as Accept Current Change, Accept Incoming Change, Accept Both Change, and Compare Changes. Click on the corresponding option to choose one of the two code segments.
Sometimes, conflict markers may not be recognized correctly, and you need to manually delete duplicate code and conflict markers, otherwise the merge will fail.
In fact, this situation can also occur when pushing code. The solution is similar.
Branch Management
Use the git branch command and git checkout command to create branches and switch branches. The usage of these commands is not repeated here, please refer to git branch command | Runoob Tutorial and other related materials.
Branch naming and functionality in Git:
- master/main (main branch, always a stable version, should not be developed directly on this branch)
- develop (development main branch, all new features are created on this branch, this branch is only for merging operations, should not be developed directly on this branch)
- feature-xxx (feature development branch, create branches on develop for developing specific features, merge to develop after feature testing is successful)
- feature-xxx-fix (feature bug fix branch, create branches on develop for fixing bugs found after merging feature branches to develop, then merge back to develop)
- hotfix-xxx (urgent bug fix branch, create on master branch, merge to master after fixing)
- bugfix/* branches (created short-term from develop)
- release/* branches (created short-term from develop)
The relationship between branches can be seen in the following figure.
As mentioned above, in projects with multiple collaborators, progress is often made in parallel with multiple branches. Directly pushing to the main/master branch and develop branch is not allowed.
Use Pull Request (PR) to merge code The PR method can avoid unexpected results caused by direct pushing, support code review, and introduce automated tools for assistance, etc.
Specifically, refer to Why you shouldn't push to master | Weitang Li's blog
How to create a PR can be seen in the figure below, follow the instructions on the page to operate.
Essential Development Process
A few important points must be emphasized.
Always perform a pull operation before development
Always pull before each development❗ to resolve possible conflicts and update the code. It also avoids redundant work.
Do not develop using the main (master) branch and develop (dev) branch
We prohibit pushing directly to the main branch and develop branch. It is best to develop on a corresponding feature branch.
The naming of feature-xxx branches can be based on the specific features being developed. Then use PR to merge the code.
Direction of PR: Submit from feat branches to dev branch, and then submit from dev branch to main branch, do not skip levels.
If you violate this step, it will lead to branch chaos, and the consequences will be extremely difficult to handle.
Clearly describe commit messages when submitting code and PRs
Tell your teammates what you have done❗ to save everyone's time. See the previous section for details.
Branch merging requires review
Usually, PRs are not directly approved and may require code review by other members of the team before they can be merged. Pay attention to the comments section of the PR page to receive feedback and modification suggestions in a timely manner.
If you are unsure, ask in the group
For example, if a code conflict occurs, it is not necessarily someone else's code that is wrong.
Or it may encounter unfamiliar issues, etc...
Searching for solutions is one aspect, but be sure to let other team members know, don't work in isolation😅
Good Luck
Good luck