I describe here how I use git
to support my software project development.
This might be useful to other people who have similar requirements.
E.g. global settings: (there seem to be per project settings too):
$ git config --global xyz $ git config --global user.name "Your Name Comes Here" $ git config --global user.email you@yourdomain.example.com $ git config --global core.editor notepad
Regards the latter setting for the editor, I would prefer to use
EMACS/emacsclient/emacsclientw for commit messages, but that does not
seem to be easy to set up. The main issue is that git
must know when
editing is finished. So when is emacsclient
finished?
You can check your configuration with
$ git config --list
To exclude binary files, use .gitattributes
so that git does not
touch them. To include empty directories put a .gitignore
dummy file
in there.
For details how to ignore files see https://labs.consol.de/de/development/git/2017/02/22/gitignore.html
$ git init
creates a new git repository from the current directory.
$ git add <dir>
adds all files in dir
.
$ git add -A
or
$ git add --all
adds all files and directories recursively of a project to staging, irrespective of which branch/subdirectory this command was issued from, whereas
$ git add .
adds all files and directories to staging, but only from the directory downward from where this command was issued.
Committing what is staged:
$ git commit -m "A message about this version"
Committing everything, without explicitely staging first i.e. staging everything:
$ git commit -a -m "A message about this version"
If you omit -m
, the editor specified in the EDITOR
environment
variable will be fired up for the commit message. Alternatively, there
is the git config
variable core.editor
for that (see above). The
editor will create a temporary file COMMIT_EDITMSG
in the same
directory. A default edit message template will be loaded in the
editor with a blank first line and some explaining lines with a "#" in
the first column. You add the commit message to the first line and add
subsequent lines if needed. The lines starting with "#" do not make
it in the commit message.
Show changes to a file since the last commit
$ git diff --ignore-cr-at-ol <file>
The option --ignore-cr-at-ol
helps to deal with Unix, DOS end of
line differences. Obviously, git cares and does not treat files just
as binary objects.
Showing the commit history:
$ git log
Below seven rules I copied from https://chris.beams.io/posts/git-commit/
https://git-scm.com/book/en/v2/
Git tutorial: http://www.flutterbys.com.au/stats/tut/tut19.1.html
Introduction (de language): http://pi.informatik.uni-siegen.de/lehre/Vertiefungspraktika/2016s/materials/slides/2016s_PEP_slides_git.pdf
Important commands: https://pgi-jcns.fz-juelich.de/pub/doc/git_gitflow.pdf
MS Azure git documentation https://docs.microsoft.com/en-us/azure/devops/repos/git
Install git
on WSL. In a Bash prompt:
$ sudo apt install git
Location of config files: https://www.onwebsecurity.com/configuration/git-on-windows-location-of-global-configuration-file.html
Line ending issues: http://www.edwardthomson.com/blog/git_for_windows_line_endings.html
A quote from https://forum.kicad.info/t/how-to-clone-a-project/3878/4 about using source code management for CAD/Kicad files:
"You probably don't want to hear this (most people don't), but git
easily does this for you. (Note that I'm talking about git
, not
Github.)
First: in your kicad project directory, just do
$ git init
This creates a repository that stores all your project versions.
Second: add the project files you want to keep track of. For kicad, there's really only three you need:
$ git add myproj.pro myproj.sch myproj.kicad_pcb
Third: store the current state of your project:
$ git commit -a -m "Some message about this version"
That is all you need to do to setup versioning. Then whenever you have a version you want to save, run the command
$ git commit -a -m "A message about this version"
If you also want to give the snapshot an easy-to-remember name, you can use the command
$ git tag my_version_tag
Then if you ever want to return to that version, use the command
$ git checkout my_version_tag
And if you want to see the history of your project, use
$ git log
I've seen plenty of tools that provide some form of 'archiving'.
They're pitiful when compared to using any modern versioning tool like
git
or Mercurial. If the tool builders were smart, they'd just provide
a button you could press to execute the commands I showed above."
A subproject is a generic term for one of three types of nesting:
https://gist.github.com/gitaarik/8735255
Linux kernel example: https://git.wiki.kernel.org
https://git.wiki.kernel.org/index.php/SubprojectSupport
https://developer.atlassian.com/blog/2015/05/the-power-of-git-subtree/
How to include a Windows compare tool: https://www.sep.com/sep-blog/2017/06/07/20170607wsl-git-and-beyond-compare/