This is the eighth article in a series on the basics of using Git. The other articles in the series are:
- Basic Git for DBAs: Getting Started with Git
- Basic Git for DBAs: Sharing Files Through GitHub
- Basic Git for DBAs: the Basics of Branches
- Basic Git for DBAs: Making Changes in GitHub
- Basic Git for DBAs: Merging Code Between Branches
- Basic Git for DBAs: What's a Pull Request?
- Basic Git for DBAs: Managing PowerShell Scripts
- Basic Git for DBAs: Ignoring Files and Customizing Your Environment
In the previous articles, we set up a repository, shared files, branched/merged code, and created pull requests. In this article, we will look at a few items that are important for customizing your git environment. This article will look at how we can ignore certain files and further customize our individual environment using some common things that a user will want to change.
Ignoring Files
One of the things that we often want to do in a repository is ignore certain types of files. For example, in Visual Studio projects, there are various file that are user specific files. I might have files that are *.user or *.userprefs files for my environment. These change constantly, and I don't want to include them in my git repository. For SQL Server, I might have temp files that a tool creates, or even maybe some output files that I use to keep some data.
No matter what types of files I have, I can ask git to ignore these by adding a .gitignore file to my repo. This is just a text file that contains a pattern or file(s) that I do not want git to track or commit to the repo. As an example, this is a sample .gitignore file for Visual Studio: https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
As a simple example, let's say I have my repo, as we've seen in previous articles. Everything here is tracked, and my status is up to date.
Let's say that I run my queries and end up with a new Excel file for my results, but I don't want to track this new file because it's a file I created as a test. Here is the repo:
And the status, which shows a new file that isn't tracked. We've seen this red message before.
It is important I use some naming here that I can find a pattern in. In this case, I'm going to note that steve_*.* files in this repo should not be tracked. I can specify this by creating a .gitignore file. In here, I'll type "notepad .gitignore" at the command prompt and then I'll get a new file. In it, I'll enter my file pattern.
If I save this and then run a git status, I see that the xls file is no longer listed. I do, however, have the .gitignore file as untracked. I need to add this and commit this file to the repo.
If I were in a team and we wanted this as a standard for this project, I could add additional lines in the file for Kathi, Kendra, and Grant as teammates. In that case, we'd want to ignore all files that started with our names like this:
Now, I can add a few more files to my repo. In this case, I'll add a few XLS files, along with some SQL files.
I've added some XLS files, one for me testing and one where I connected to Kathi's instance. I also added a new .SQL file, where I'm testing things and don't want this to be in the shared repo.
Note, these files are only in my repo.
If I now run a git status, I'll see the clean repo (I committed the .gitignore).
If I look on GitHub, I see this the files in my repo, with the gitignore, but not the files that start with Steve or Kathi.
My repository is ignoring these files, based on the list of patterns in my gitignore file. The same effect will exist for all my team members using this repo, or even anyone that forks this. The .gitignore file is a part of the repo and is shared. The files ignored, are not.
The gitignore doc explains how patterns work, and how you can customize the repo, or your entire installation, to exclude types of files from your repository. You can even specify a specific file, but including the name if that works for you.
The Default Branch
If you have git v2.28+, you can set a default branch. This is something that more and more companies are doing, with a move away from "master" as nomenclature in technology. The way to do this for your own repos is with this command.
git config --global init.defaultBranch main
If you use GitHub, BitBucket, Azure DevOps, or many other cloud providers, and create a project there, the default is often set to main already. If your organization has a different standard, you can substitute that for main.
Auto Correct
I learned this from Kendra Little recently. There is an autocorrect in Git. I've seen the guesses, which are a part of git. If I enter git stats, I'll see this:
Git tries to tell you what command makes sense, but you can have git actually run this command for you after a delay. For example, if I think I often just mistype something and git knows what I mean. I can have git actually run the command by changing the setting for help.autocorrect. The format is:
git config [--global] help.autocorrect xx
The global flag is optional. You can choose to set this for all repos (I'd do this), or just certain ones. The xx is tenths of a second to delay before running the command. If you want to cancel the command, you hit CTRL+C.
Here I'll delay for 5 seconds with this command:
git config --global help.autocorrect 50
After running this, if I mistype a command, I'll see the message below that the command will run in a 5 seconds. If I wait that long without doing anything, the command runs.
Five seconds is a little long. I typically set this to 2 seconds once I'm used to the delay.
Customizing Your Editor
When a user commits a change in git, a comment is required. If you don't include a comment, the default editor is launched, which is vim. For example, if I just type git commit when I have a file staged, I see:
If you don't want to use this, you can choose another editor. I don't like vim, but I do often use Sublime Text 3. I can set this as my default editor with the git config command and changing the core.editor setting. For example, to set this to notepad on my system, I type:
git config --global core.editor "'C:/Windows/notepad.exe'"
Note the slashes here, and the single quotes inside the double quotes. This opens notepad when I commit.
If I type a message in the first line (lines with # are ignored) and then save the file, I can close notepad, and I'll see the confirmation in the command line.
I can set any editor I want, but I need to ensure I have the correct path. On my Windows system, I've used these commands:
- Visual Studio Code - git config --global core.editor "code --wait"
- Atom - git config --global core.editor "atom --wait"
- Notepad - git config --global core.editor "'C:/Windows/notepad.exe'"
- Notepad++ - git config --global core.editor "'C:\Program Files\Notepad++/notepad++.exe'
- Sublime Text 3 -
Be sure you check the paths on your system for the editor.
One note, if I have the editor open and git just opens a file, sometimes the close doesn't register if I edit, save, and close just the file without closing the editor. As a result, I find notepad to work bet for me.
Aliases
As with PowerShell, you can alias commands that are useful to you. For example, if I am lazy and don't want to type git branch, I can do this:
git config --global alias.br branch
This will alias the branch command to br, so I can shortcut my typing.
I can also use other items, like a soft reset if I mess up a commit with this code:
git config --global alias.undo "reset --soft HEAD^"
Now if I make a mistake with the commit, which I do from committing too fast, I can "git undo" and I'll remove that comment.
You can alias most anything, and I've found a few blogs that provide some ideas. My advice is to try one for a few days, seeing if this helps you. If so, leave it. If not, get rid of it, and then make more.
- https://blog.scottnonnenberg.com/better-git-configuration/
- https://opensource.com/article/20/11/git-aliases
- https://haacked.com/archive/2014/07/28/github-flow-aliases/
These are stored in the .gitconfig file under the [alias] section.
