Team work ability has always been one of the important assessment indicators of our recruitment of developers. The reason to measure this ability is simple: most companies don’t have just one development… When it comes to collaborative development, good collaborative ability and habits can significantly improve the efficiency of the entire team. Time is money!

When it comes to collaboration, of course, the most important thing developers need to collaborate on a daily basis is code collaboration. Due to the popularity of Github in China, many companies have already hosted their code on Github or internal Git services, so people are gradually introducing git skills into the interview.

Here are some personal git related issues and their analysis.

Based on some

What Git tools do you use?

In addition to git’s own command line tool, Xcode’s own Source Control function is certainly the most accessible for iOS development, but both of these two tools have some shortcomings.

• Xcode: Xcode itself supports Git, but it has one particular bug: cards… And the bigger the file, the more card, and even Crash. As a result, Xcode is largely unlooped for collisions with large files like.pbxproj, and its Git support is a bit thin.

• Command line: can only say ten of the nine dishes, there is a god, although the command line provides all the functions, but many GUI tools can be very convenient to solve the problem, the command line do more trouble. Of course, this is not to discourage you from going to the command line, through the command line to have a deeper understanding of the function and principle of Git.

Because of these shortcomings, we often use some third-party GUI tools to improve our Git repository management efficiency:

• SourceTree: the author daily use of a graphical Git enhancement tool, and the most useful function lies in its integration of GitFlow, so that developers can be more simple, more standardized to do some Git operations; It also provides a more user-friendly merge interface, but it is not very handy because it only supports deletion of whole rows.

  

• SmartGit:

  

• Tower: Tower is known as the best Git client for Mac platforms. The software greatly simplifies the use of Git, users can complete the operation by dragging, more convenient, more efficient. Note that it costs $60 to use the full feature after 30 days.

  

• Atom: Atom itself is not a git management tool, but an open source IDE that supports multiple development languages. The reason for this is that merge-Conflicts, a plug-in that provides a slightly more useful merge interface than SourceTree, uses Atom to flag conflicts directly based on the current content. Developers can make changes directly in the marked areas just as they would in normal text, and ultimately choose the part they are happy with as the content after the merge.

Key points of investigation:

• How well you know your Git tools;
• Initiative, whether you can take the initiative to find ways to solve the pain points in the current job.

Key points to answer:

Don’t just say what you use. It’s about analyzing the strengths and weaknesses. Why use which tool? Why not use one tool?

What is the difference between Git Add and Git stage

To answer this question, you need to understand the three components of a Git repository: Working Directory, Stage, and History:

• Workspace: Normal directories under Git management are all workspaces, and our usual editing work is done in the workspace.
• Staging area: temporary area. It holds a snapshot of the file to be committed.
• History area: Record area after git commit.

Then there is the conversion relationship between the three zones and the commands used for the conversion:

Then we can talk about Git add and Git stage. In fact, they are synonymous with each other, so, surprise, surprise, surprise? This question turns out to be a trap… Git stages are introduced for interesting reasons: SVN add is to add a file to version control, while Git add is to add a file to temporary storage. Because SVN was used a lot before Git came out, in order to avoid misleading, Git introduced Git stage and then git diff –staged as the same command for Git diff –cached. For this reason, we recommend git stages and Git diff –staged.

Key points of investigation:

• Understanding of Git Working Directory, Stage, History and transformation relationship;
• Knowledge of Git Add and Git stage.

Key points to answer:

• Working Directory, Stage, History, and transformation relationships should be included.
• Git stage is synonymous with git add;
• I use Git stage.

What are the differences between Git reset, Git Revert and Git Checkout

This question also requires understanding the three components of a Git repository: Working Directory, Stage and History.

The first is what they have in common: they are used to undo some changes in the code repository.

Then there are the differences:

First, from the commit level:

• Git reset can point the end of a branch to a previous commit. The next git garbage collection will throw away any commit after the commit. Git Reset also supports three tags to mark the impact of the reset directive:

  • — Mixed: Affects the staging area and the history area. Is also the default;
  • –soft: affects only the history area.
  • Hard: Affects the workspace, staging, and history areas.

  Note: Because Git reset deletes commit records directly, which affects other developers’ branches, do not do this in a public branch such as Develop.

• Git Checkout allows you to move the HEAD to a new branch and update the working directory. Since local changes may be overwritten, you need stash or commit changes to the staging and workspace before executing this directive.

• Git Revert does the same thing with Git Reset, but it undoes a commit by creating a new commit. Also, since local changes may be overwritten, you need stash or commit changes and workspace changes before executing this command.

Then, from the document level:

• Git reset only takes files from the history area to the staging area. It does not affect the contents of the workspace and does not support –mixed, –soft, or –hard.
• Git Checkout brings files from history to workspace without affecting the contents of the staging area.
• Git Revert does not support file-level operations.

Key points to answer:

• At the Commit level and at the file level, the three instructions themselves function quite differently.
• Git Revert does not support file-level operations.
• Do not do git reset in a public branch.

GitFlow basic flow and your understanding

GitFlow is a Git workflow standard developed by Vincent Driessen. Including the following key branches:

The name of the	instructions
master	The main branch
develop	The main development branch, which contains the code identified for release
feature	New function branch, generally a new function corresponds to a branch, the separation of functions needs to be more reasonable, in order to avoid some later unnecessary code conflicts
release	Release branch, the branch used for release, and the bugs found during general testing are fixed in this branch
hotfix	Hotfix branch for emergency bug fixes

The advantages of GitFlow are as follows:

• Parallel development: GitFlow makes it easy to implement parallel development: each new feature creates a new onefeatureBranch, thus isolating the functionality that has already been completed, and only if the new functionality has been developedfeatureBranches are merged into the main development branch (as we often say)developBranch). In addition, if you are working on a feature and a new feature needs to be developed, you only need to commit the currentfeatureAnd then create another onefeatureBranch and complete new function development. And then cut backfeatureThe branch can continue the development of the previous function.
• Collaborative development: GitFlow also supports multi-person collaborative development, as eachfeatureAny code that changes on a branch is just to make something newfeatureCan run independently. It’s also easy to see what everyone is doing.
• Release phase: When a newfeatureWhen development is complete, it will be merged intodevelopBranch, this branch is mainly used to temporarily save content that has not been released, so that new development is neededfeature, we just need to start fromdevelopBranch Create a new branch that contains all the completed branchesfeature 。
• Support for emergency fixes: GitFlow also includeshotfixBranch. This type of branch is created from a published tag and makes an emergency fix that only affects the published tag, not the new one you are developingfeature.

Then there are the most classic flow charts of GitFlow, which must be understood:

Feature branches are created from the Develop branch and then merged to the Develop branch for release.

When we need to publish, we create a Release branch from the Develop branch

The release branch is then released to the test environment for testing, and if problems are found, they are fixed directly in this branch. Until all issues are fixed, we will keep releasing -> testing -> fixing -> re-releasing -> re-testing the process.

After the release, the release branch is merged into the Develop and Master branches to ensure that no code is lost.

The Master branch only keeps track of code that has already been published, and a COMMIT merged on the master can only come from the Release and hotfix branches.

The hotfix branch is used to fix bugs on the fly.

They are created from a tag on the Master branch and then merged into the Develop and Master branches after the fix.

Look at key points

• Branch types and functions included in GitFlow;
• Advantages of GitFlow;
• Understanding of GitFlow feature, release and hotfix processes.

Answer key points

• The basic content and advantages of GitFlow;
• Feature processes are initiated from the Develop branch and merged back to the Develop branch via PR/MR.
• For the release process, there are a few things to note:
  • If there are bugs that need to be fixed on the Release branch, do so directly on the Release branch;
  • Bug fixes on the Release branch are continuously incorporated back into the Develop branch via PR/MR;
  • The release branch was merged directly into the Master branch when the release was finally confirmed.
• For the Hotfix process, there are a few things to note:
  • Originating from the master branch;
  • Once fixed, merge into Develop and Master at the same time.

Explain the difference between PR and MR

PR and MR are pull Request and Merge Request respectively. Before explaining the difference between the two, we need to know about Code Review, because PR and MR were introduced for the purpose of Code Review.

Code Review is a systematic Review of Code during development. The usual goal is to find defects in the system, ensure code quality and improve the developers themselves. Code Review is a lightweight Code Review. The costs of a lightweight Code Review are significantly lower than those of a formal Code Review and can have a more positive effect if the process is correct.

Reasons for Code Review:

• Improve code quality
• Early detection of potential defects and bugs, reduce the cost of accidents.
• Promote knowledge sharing within the team to improve the overall level of the team
• The review process is also a process of thinking reconstruction for reviewers to help more people understand the system.

Then we need to learn about fork and Branch, since these are the collaborative processes that PR and MR belong to respectively.

Fork is a collaborative process on Git. Generally speaking, it is to back up the warehouse of others to their own warehouse, and then submit the modified things to the other party for review. After the other party agrees, you can achieve the small goal of helping others to change the code. Fork contains two processes:

• Fork and update a repository

  

• Synchronization of the fork

  

Unlike fork, branch does not involve any other repository; operations are done in the current repository.

So that’s the big difference between PR and MR.

Key points of investigation:

• Code review;
• Details of the process to which PR and MR belong.

Key points to answer:

Don’t just say the difference when answering this question. Instead, we should analyze the causes of PR and MR, the processes they belong to, and then draw the differences between the two.

The advanced part

Step to the next step: iOS Interview Guide.