Source code Control--llorch Visual Studio Basic Tutorial (iv)

A generic example illustrates:

• This series of blogs discusses only the basics of the tool and does not discuss any language.
  • Don't even discuss shortcut keys:-)
  • You can complete this tutorial with the mouse
• The IDE default refers to Visual Studio Community Edition. At the end of this series of articles, you can skillfully use it to write programs.
• The default layout state after Visual Studio startup is called the main window, and the project name displayed in the title bar of the main window is not necessary.
• Several symbols describing menu actions are defined on the basis of daily spoken language and Windows Explorer: [], {},/, >>, =, (,).
• check that a setting item is represented by:
  • [Window name]/{menu name}/{submenu name}/{Set item Item name}= Set value of item
• For example, the default Debug configuration:
  • [Main Window]/{solution Configuration Manager}=debug
• When checking multiple settings items, write each one in the same way as a single set item
• When you check that a setting item has multiple values , parentheses are used to separate them with internal commas, such as:
  • [Solution Explorer]/{project name}/{reference}= (system,system.core,system.data,system.xml)
• To perform a left-click sequence is to replace the last check with "/", such as exiting the IDE:
  • [main window]/{file}/{exit}/
• The connection symbol for the right-click menu is >>, such as refreshing the Windows desktop:
  • [Desktop]>>{Refresh}/
• The representation of a setting item in a pop-up window is similar to
• The representation of the set item in the MDI child window is similar to the above, noting that in Visual Studio, the name of the MDI child window is in its upper-left corner or may be automatically adsorbed around the main window
• title bar and status bar as the promotion of the menu, applicable to the above presentation method
• Defect description
  • Welcome feedback, mailto:[email protected]
  • The preferred language for the author is C #
  • The author is a soft dog
  • The author's IDE does not have a Chinese language pack, so some nouns are not translated correctly:-(
  • Due to the lack of clarification of the relevant certificate issues, copyright reserved
  • Series of articles did not propose or solve new problems, the purpose is only science

Body

The purpose of today's programming is to not program tomorrow.

This blog discusses the intrinsic purpose of programming, i.e. source code management. The so-called source code management is only for the most stable code that can work. Stupid code and Smart Code are code snippets or programming caches, rather than source control in collaboration.

Source code and code Snippets

It's a good idea to save all the code you've written. It might be a little better for the developer to keep the code that you can use in order to reuse it at any time. Because the latter allows developers to focus on the design. The common way to track file history is version control, which is often referred to as source code management. But generally speaking, source control sounds more like a "character history."

A piece of code, only from its relationship with the overall program, can be broadly divided into two categories, one is immediately available, and the other is "I want to fix it." The former is called "Source code" and the latter can only be called "fragment (snippets?)". The difference to the developer's tip is that, in practice, programming is about manual work around release.

Beautiful code and stable code

Beautiful code usually uses some secret techniques to achieve a more bigger function. The stable code is not. For example, in the case of a difference set of two sets, the beautiful code may write a large number of statements in a loop, while the stable code may be written in 35 sequential loops. So, is beautiful code good or stable code good?

In fact, we will find that we are actually looking for beautiful code, but we have a stable version of it. A stable version of the code is often easier to debug and more concise to iterate through. We will eventually adjust the performance on the basis of maintaining stability.

Implement source code control for stronger purpose

At least one version is already running, both in the test and in the prototype. In addition to the source code management is to engage in academic research.

The concept of source code management should be higher than the project hierarchy. This is because, for the purposes of programming, a project is only a sub-part of the goal of achieving the programme.

Once source code control is targeted for strong purposes, the focus of the maintenance of source code management naturally falls into the complete tense of the work.

Source code control with IDE built-in git

In Visual Studio, the design philosophy of strong-purposeful source control (even if it can be easily abused) runs through it. This table now, without opening any solutions, [Team Explorer] is still available. Then there are some automatic simplifications on the merge of the branches.

Because of the limitations of practice, Llorch has not yet used team Foudation Server, so the content of this article is illustrated with Git support in Visual Studio in an exemplary way. Since the built-in Git features in Visual Studio 2013 are not complete, some users are accustomed to assembling other git plugins themselves. Llorch's tutorial mainly wants to provide a bit of reference for beginners, so it is assumed that the use of third-party plug-ins is "advanced user".

To configure Git in Visual Studio

[Main window]/{View}/{Team Explorer}/, open the [Team Resource Manager] child window, which is the primary Action window for source control.

[Team Explorer]/{drop-down list}= settings/{git settings}/, setting the identity information, cache directory that affects Visual Studio global.

Cloning a git repository online

[Team Explorer]/{drop-down list}= project/{connect to the team project}/{clone}/, fill in the Git warehouse address and the local cache directory and start cloning. The built-in Git tools can only work well with the HTTPS protocol's publishing URL, do not support SSH versions, and support the way Windows credentials log on.

If it has been cloned, the menu will automatically switch to pull. It's a good idea to take a look at the branch submissions to avoid overwriting useful work. Llorch tried a few times, as if there were no branches to submit, the pull will become gray.

[Team Explorer]/{drop-down list}= Project/{local git repository}/{library n}//, double-clicking (//) any of the locally stored libraries listed will jump to [Team Explorer-Home] Subwindow in [Team Explorer-Home]/{solution} You can choose to operate the branch or open the solution in the section.

Once the solution is turned on, manually switch to [Solution Explorer] to begin coding. (This is a bug in the user experience, not automatically switching past, can be improved by canceling the docking of Team Explorer.) ）

Commit changes to a local repository

[Solution Explorer]/{Solution}>>{submits the}/, which can be submitted after the submission message is filled in.

Commit changes to a remote repository

Visual Studio Community Edition has built-in Git tools that only support submission to remote repositories via the HTTPS protocol. In any case, in order to improve commonality, it should be cloned, modified, and then submitted.

[Team Explorer]/{drop-down list}= not synchronized commit/, if the project is cloned, click {Outgoing commit}/{push} directly, you can take advantage of the credentials saved in the clone step to commit once. If not, then you need to enter the credentials once.

Incorporate new scenarios into your local git repository

[Solution Explorer]/{Solution}>>{Add the solution to source control}/, exhale the [Select Source Control] window and select {Git}.

[Solution Explorer]/{Solution}>>{commits}/, which is committed to the local cache.

Committing changes to a remote repository is also applicable.

Branch Management

[Team Explorer]/{drop-down list}= branch/, in this interface Visual Studio simplifies the management of the branch to the extreme. Basic understanding of "branch" is what the meaning of children's shoes should be used, will not repeat.

Summarize

Tracking character history is applicable, and improving the purpose is more practical.

Visual Studio's built-in Git tools only provide support for the HTTPS protocol, and it has castrated a lot of the scalability of the tall. However, if you just concentrate on writing source code, it still applies.

The essence of source code control is branching and merging. This could be a project outside of Visual Studio.

Installing the system global git tool is not recommended. It is best to use dedicated shell tools (Cygwin, Gentoo-prefix-interix, etc.) for advanced operations. This not only avoids the extra complexity, but also gives you better control over the per-user environment variables, and even gives you more lovely features.

Thanks to the powerful plug-in community of Visual Studio, you can add a full-featured Git plugin. Built-in used to rather like the built-in simplicity, it is just a habit problem

Ps:llorch wrote this series of blogs with the aim of stabilizing the fundamentals of programming skills, and today's discussion is for tomorrow's discussion. As the source control discussion continues, it is nearing completion. Llorch will end the series with a discussion of the Assembly and then focus on the "fun" content.

Thank you for your attention and support!!

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Source code Control--llorch Visual Studio Basic Tutorial (iv)