This is a series of articles related to Source Control or Version Control issues, from a stand-alone app, such as MS SourceSafe, to a Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We tried to categorize this series of articles as Source Control or Version Control, but this site does not have these categories, so we put the articles in the as DevOps category, as explained in the wiki:
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.
The structure of this article series will cover:
- Stand Alone App:
- Server App
- MS TFS (Team Foundation Server)
- Online (Cloud) Centralized Service:
- MS Azure: DevOps
- Boards
- Repos
- Pipelines
- Test Plans
- Artifacts
- GitHub
- AWS GitHub Enterprise
- Distributed App:
Because these are huge topics, I will not go step by step, instead, each section will be relatively independent to become a reading unit.
- Source Control (1), MS Source Safe --- Stand Alone App
- Source Control (2), MS TFS --- Centralized Server App
- Source Control (3), MS Azure DevOps (GitHub, Jira) --- Centralized Service
- Source Control (4), Git --- Distributed App
- Source Control (4-1), Git --- Configuration --- this article
- Source Control (4-2), Git --- Configured to Connect to DevOps and GitHub
- Source Control (4-3), Git --- Cherry Pick in Visual Studio
- Source Control (4-4), Git --- Recover Git Tree: Reflog/Reset
- Source Control (4-5), Git --- Recover Deleted Branch
- Source Control (4-6), Git --- Revert
- Source Control (4.7), Git --- Get Specific Version or Commit
- Source Control (4.8), Git --- Get Specific Version or Commit in practice
- Source Control (4-9), Git --- Merge: Fetch, Pull, Push and Sync
- Source Control (5), GitHub access (setup connection)
- Source Control (6), DevOps access (setup connection)
- Source Control (7), GitLab access (setup connection and Clone to Local)
- Source Control (8), Git, Azure Repos, and Visual Studio (Interaction)
- Source Control (9), Push into Git Hub and DevOps
- Source Control (10), Git Hub, DevOps Publish
Introduction
Git has been a distributed Source Control since 2005. We have used it multiple times when we need it without paying much attention to the configuration, except when we try to integrate it with DevOps or GitHub, then we figured out that we need to do some basic configuration. This is a summary of the configuration, and in the next article, we will discuss some specific issues when Git is configured not fit for DevOps or GitHub.
This is the structure of this article,
- Introduction
- Install Git
- Config Git
- Set Global Git Configuration
- Change Editor
- Setup Windows Secure Channels Library Connection to DevOps Server
- Visually editing Global and System Configuration
- Summary
Install Git
Download Git from https://git-scm.com/download/win. The current version on Windows as of this document version is 2.33.1, but be sure to get the latest maintained version. For the most part, select default settings unless otherwise indicated below.
If you wish, select a new default editor for git.
Figure 1- Set git default editor
Also, be sure to select the “Use the native Windows Secure Channel library” option during installation. This will allow you to work over the VPN over HTTPS.
Figure 2- git Setup for Windows Secure Channel Library Connections
Note
Sometimes, you might not pay attention to it, Git has already installed associated with, say, Visual Studio's installation when you choose the code tools like this:
Configure git
Set Global Git Configuration.
- Open a command prompt using Run as Administrator.
- Type,
git config --global user.name "Firstname Lastname"
- Type,
git config --global user.email "[email protected]"
- Verify your configuration settings. Type,
git config --global -l
You should see something like this
- Set default pull to local branch from remote to do a rebase. This is so that when you are working on a feature and other developers have been making changes to the remote develop branch, when you pull to update your local develop branch it will fast forward the remotes changes to your local branch then apply your commits. Otherwise, you will see mixed commits, and creating a pull request will be harder.
git config --global pull.rebase "true"
- Set fetches from remote to prune local remote branches. Otherwise, you’ll need to remember to use the command line to clean up your remotes/origin branches when feature branches are deleted after pull requests are completed.
git config --global fetch.prune "true"
Note - You may set these global configuration settings from Visual Studio. Open Team Explorer, click Settings and then click Global Settings under Git. However, not all global settings are available in the UI, nor are any system or local repo settings. These settings require the command line.
- Since we are running on Windows, tell git to ignore the case in file system. Git, by its origins in Linux, supports case-sensitive filenames. This can cause issues if you rename folders or files by just changing case.
git config --global core.ignorecase “true”
Change editor used for interactive commit messages, squash, etc.
- By default, git uses VIM as the text editor for things like interactive commit editing, squash merge editing, and other editing needs. If you do not wish to use VIM, you may change it.
Change to use 64-bit Notepad++, type:
git config --system core.editor “’c:\program files\Notepad++\notepad++.exe’ –multiInst –noPlugins –nosession -notabbar”
For 32-bit Notepad++, type:
git config --system core.editor “’c:\program files (x86)\Notepad++\notepad++.exe’ –multiInst –noPlugins –nosession -notabbar”
For Windows notepad, type:
git config --system core.editor “notepad”
Set up for Windows Secure Channel Library connection to DevOps Server
- Verify that the git system configuration is set to use WSCL connections to DevOps Server.
Type:
git config --system -l
You should see something similar to this:
If the entries for http.sslbackend does not exist or is set to “openssl”, we need to fix it. Type:
git config --system http.sslbackend schannel
Visually Editing Global and System Configuration
- git has built-in support for editing configuration en masse using your defined editor. We will see how this looks.
Type:
git config --system –e
- Ensure the difftool and mergetool settings are as specified below, and change if not.
- If you made changes, simply Save and exit to update the system settings.
- Look at the contents of the system configuration file. It is stored in c:\Program Files\git\mingw64\etc\gitconfig. These configuration entries affect all workstation users and all repos.
- Do this for the global config next.
Type:
git config --global –e
- Look at the contents of the global configuration file. This is stored in c:\Users\{youraccountname}\.gitconfig. These configuration entries affect all repos, just for you.
Note: If you change to a root folder of a git repo and type git config -e, you will open the repos’ config file in the repo’s .git\config file. This affects only the particular repo, for all users.
Summary
This article discusses the basic configuration of Git in local machine, it might be important when we try to connect Git to either DevOps or GitHub.
References