Ducks Git Manual v2021.04.28.1

--- Installing Git

    1) Download Git for Windows
    
        https://git-scm.com/download/win
    
    2) Install Git
        
        https://phoenixnap.com/kb/how-to-install-git-windows
        
        Follow the above guide for the installation process unless where
        otherwise stated below. (If you know what you are doing, you can choose
        whatever you want, of course.)
        
        In step  7: Consider enabling checking for updates.
        In step  9: Pick an editor of your choice. (Do not choose vim unless
                    you are already at least sort of familiar with vim.)
        In step 10: Pick 'Use Git from Git Bash only'.
        In step 16: No need to view release notes unless you are curious and
                    have time to waste.
    
    3) If this is the first time you installed git on this particular machine,
       continue with the 'Configuring Git' section.

--- Configuring Git

    1) Set up your information
    
        Start Git Bash from the start menu, and run these commands while
        replacing the placeholders with your information. (These values will
        !publicly! appear as the author/commiter values in your commits in the
        git repository log.)
        
        git config --global user.name <your_user_name>
        git config --global user.email <your_email>
        
        NOTE: This only needs to be done once for each machine on which you
        install Git.
    
--- Setting up a new fork

    1) Fork the repository of interest in the Gitea UI
    
    2) Set up a local copy of the repository to work on
    
        In Windows Explorer, go to the directory where you want to keep your
        repository, right-click in it, and pick Git Bash Here. That will open
        a command line window, with path set to that directory, into which you
        will write the following commands.

        # Clone your fork
        git clone https://rhinoduck.net/gitea/<your_username>/<repo_name>.git
        
        # Switch to the repo directory.
        cd <repo_name>
        
        # Add the repository you forked from as a remote.
        git remote add upstream https://rhinoduck.net/gitea/rhinoduck/<repo_name>.git

--- Making changes and creating a pull request

    1) Start Git Bash in the directory where you placed your local copy of the
       repository of interest
    
        NOTE: If you do not have a local copy or have not even forked the
        repository, go through the 'Setting up a new fork' section first.

    2) Check that you have no uncommited local changes

        # To list files which have been modified.
        git status
        
        NOTE: See the 'Reverting local changes' section on how to get rid of
        the possibly unwanted changes easily.
    
    3) Get your fork up to date with the upstream repository
        
        # Fetch changes from the upstream remote.
        git fetch upstream
        
        # Make sure you are in your master branch.
        git checkout master
        
        # Apply the upstream changes to your local branch.
        git merge --ff-only upstream/master
        
        # Push the changes to your fork's master branch.
        # (This isn't really necessary, but it may save you some confusion when
        # browsing in Gitea.)
        git push origin HEAD
        
    3) Start a new feature branch
    
        # Make sure you are in your master branch.
        git checkout master
        
        # Create a new branch and switch to it.
        git checkout -b <feature_branch_name>
        
    4) Edit files
    
    5) Commit the changes
    
        # To see which files you modified
        git status
        
        # To see the changes you made.
        git diff
        
        # To add files to a commit
        git add <filename1> [[filename2]...]
        
        # To add all changed files to a commit at once (but not new/removed ones)
        git add -u
        
        # To see which files will be commited
        git status
        
        # Create a new commit
        # (See the 'The format of commit messages' section for details on how
        # commit messages should look.)
        git commit
        
        # To check your newly added commit's message
        git log
        
        # To check your newly added commit's changes
        git show
    
    6) Push the changes to your fork
    
        # This will also set up the local branch to track the remote branch
        git push -u origin <feature_branch_name>
        
    7) Open a pull request in Gitea from your feature branch to my master
    
    8) Wait 2 years for it to be merged

    9) ?
    
    10) Profit

--- Reverting local changes

    WARNING: Use with caution!
    
    # To revert uncommited changes.
    # (Run this from the topmost directory of the repo.)
    git checkout .
    
    # To remove the last commit, but keep the changes to the files.
    # (Can be used if you already created a commit, but found out you want to
    # still change or fix something.)
    git reset HEAD^
    
    # To remove the last commit and revert the changes to the files.
    # (Can be used when you discover you royally fucked up and you just want to
    # start over.)
    git reset --hard HEAD^
    
--- The format of commit messages

    The first line should contain a short description of what the commit does;
    it should be in the imperative form, and it should not be longer than 50
    characters. If no more information needs to be added, this one line will be
    the whole commit message.

    If more information needs to be added, the long description must be
    separated from the first line by a blank line, and each line of the long
    description must not be longer than 72 characters; other than that, the long
    description can be formatted freely.

    NOTE: Long links and other such "physically" or logically unbreakable long
    strings are exceptions to the above rule; they should not be broken up, and
    they should be placed on a line of their own.

    An example of a commit message:


Remove penis from foobar

The penis was too large and thus it foo'd the bar too hard. Maybe in
time, it will be possible to find a better fitting penis that will not
cause damage to the other sensitive components; for now, the penis will
just be completely removed without a replacement.

More on foobar penis damage can be found at:
https://proctology-online.xxx/articles/2004634-can-a-peenus-too-big-damage-your-foobar.html


--- What if...

...I made a typo in the last commit message?

    # To edit the last commit message just after commiting
    git commit --amend

...my herpes went sour?

    # Oh no!
    git call --quick doctor