Skip to content
NetDwarf edited this page Jul 14, 2021 · 8 revisions

Introduction

This is an example setup and workflow for git. Especially the setup process is meant for new users which have no git project yet and not multiple Github accounts for different repos.

In general you can also use GUI tools for it, however in my opinion they hide too much and make git harder to understand than the command line version.

Setup git (bash) in Windows

Create a fork on Github

  1. Sign up on Github
  2. Login on Github
  3. Visit https://github.com/Dawn-of-Light/DOLSharp
  4. Click fork

Install git bash

  1. Download git bash
  2. Install git bash (you can leave everything as is)
  3. Open (file) explorer -> right click the folder you want the DOLSharp repo to be in and select "git bash here"

Setup git

  1. Clone your forked repo: git clone <your fork of DOLSharp>
  2. Set main git repo as upstream: git remote add upstream https://github.com/Dawn-of-Light/DOLSharp
  3. Configure your git:
    1. set username:
      git config --global user.name "<githubUsername>"
    2. set e-mail:
      git config --global user.email "<githubUsername>@users.noreply.github.com"
    3. set editor:
      git config --global core.editor <pathToEditor>

Creating Feature Branch

  1. cd DOLSharp to navigate to the git repository folder
  2. git checkout -b <FeatureBranchName> creates a branch and checkout this branch. Take a good name for your branch, to organize your changes.
  3. git pull --rebase upstream/master updates your branch. This should always be done before opening a PR.

Workflows

Information Gathering

git status: shows open merges and (un)staged files
git log [--oneline]: shows commit history
git diff <commit>: shows the difference to <commit>
git reflog: show all your actions on the current (local) repo
git show <commit> shows diff of this commit alone (patch style)
git show <commit>:<filePath> shows file at the point in history where this commit is

It's important to note, that (commit) history is detached from the file system. So if you change a file this change is obviously not in the commit history. This can be seen when doing git status (in red). Before you commit anything you need to tell git what you want to actually commit and this happens by staging via git add. Files that are staged are shown in green in git status. Note: Files can both be staged and unstaged at the same time, that means that only parts of the file changes were staged.

This also explains git reset where only the history is being changed but the files are not. (See: reset workflow)

Create up-to-date Branch

  1. git checkout master
  2. git pull upstream master
  3. git checkout -b <branchName>

checkout changes to master branch (and updates files underneath to that history). pull fetches history from upstream/master and also merges it. checkout -b <branchName> is the shortcut for creating a new branch and checking out this branch as in git branch <branchName> && git checkout <branchName>.

Update Working Branch

git pull --rebase upstream master

That's it. All commits from upstream/master are inserted before your commits.

Push your changes to your Github fork

git push -u origin <branchName>

Again, that's it. For any subsequent change you only have to do git push.

What you do instead of reset --hard or nuking

  1. Save everything you want to save in your repo folder (especially in Debug/config or Release/config)
  2. Close everything that accesses files in the repo (like Visual Studio)
  3. git add -A && git commit
  4. git checkout master
  5. rm -rf build Debug

Saves changes in case you change your mind. Moves file system to master and removes all files which are in .gitignore. rm -rf build Debug removes all build artifacts (this assumes Debug builds). If you want to have a prestine repo you need to do git clean -Xdf, which also removes all repo specific settings in Visual Studio.

Change history (edit commit messages, squash commits, edit commits etc)

git rebase -i master

It opens a text file which explains what to do. It's the most valuable tool. Instead of master you can also take another point in history like HEAD~2 which would be two commits behind.

Revert a mistake in git

  1. git reflog
  2. git reset <reflogReference>
    (3. git restore .)

This reverts your history based on your actions. You maybe messed up a rebase or a merge and now you want to go back. In this case look in git reflog where you made that mistake and copy the reference below it (either the hash or the ones in the form of HEAD~{..} ). Then do the git reset with this reference. Voila! Your history is now correct. To sync files to history do 'git restore' on all files.

!!BEWARE, not all actions in git are reversible - most notably git reset --hard(Do this instead). And if you already know you are testing something open a new branch via git checkout -b <testbranch>. This way you can just switch to the known good branch. Branching doesn't cost you anything (beside storage space).