[Dev] Git Tips and Tricks and Onboarding

As suggested by @Armageddon1 , a thread for Git tips and tricks. I figured if it isn't separated out from the Assembling the Team thread, any tips/tricks will be lost in that thread.

------

Tip #1: If you are new to Git, use a GUI client.

I'm not sure how much it matters which GUI client (though it probably does matter some), but these will let you ease in to the complexity of Git.

I've been using TortoiseGit for years. Windows only, integrates with Explorer to give you right-click context menus for frequently-used actions. It's probably not as great as TortoiseHg or TortoiseSVN, and learning Git was still difficult (in 2013, when documentation was not as good as it is today), but it has some nice visual features like log, diff, blame, commit, etc.

SourceTree is another free option. Windows or Mac. I've only really used it with Mercurial, and not extensively at that. It appears to have better support of partially-committed files than TortoiseGit, although that's an advanced feature IMO.

GitKraken has a free license for open-source projects. Windows/Mac/Linux. They claim to try to make things easier for newcomers, which would be good, and they have an "Undo" button, which really does sound like a good thing if you're new to Git.

Fork was recommended by Armageddon, though it does not appear to be free. Windows/Mac. It is a one-time cost though, unlike some premium options that are subscription-based.

Armageddon can chime in with more detail on the latter two.

-----

Tip #2: Checking out a fork.

Let's say someone has forked the repo and opened an MR, and you want to examine it locally. Their GitHub name is bob, and their branch is someNewBranch. To check it out, run:

Code:

git remote add bob https://github.com/bob/Prototype.git
git fetch bob
git checkout bob/someNewBranch

Note that you'll have to use https instead of ssh unless you have ssh access to bob's repo. The fetch step is also important here.

(side note: should we be encouraging just using branches in the main repo? I've never really worked with the fork model before as all my projects have been within one organization)

 

Heh, I was actually thinking I might start making PRs from my own fork instead of working in branches. But mainly when I work on the GitHub Actions scripts. It dawned on me far too late that I *can* test on-demand scripts without all the commit spam, as long as I do it in a fork.

But also, managing branches may be more difficult for some than using GitHub online UI to fork and later make a PR and just operate on their own fork without ever thinking about branches. And also a lot of public projects ask that you make a fork and submit a PR from there, so it's a pattern that people may have seen or may find useful to know in the future. Not everyone who codes and submits to public repos actually needs to learn branching. (Although I highly encourage coders, scripters, and config file jugglers to learn git and branching.)


I'm pretty proficient with git on the command line, but I could get along very well with just VSCode's git integration and GitHub's online UI if not branching. Not that I'd discourage anyone from using a desktop GUI git. GitHub seems to keep trying to push a bespoke CLI and desktop client on me, but I want to keep using tools that will work with any git, be it GitLab, VSTS, Stash Bitbucket, or a bare directory.

 

I usually like branching from the main repo because it's easier to track what people are doing in their branches, otherwise you have to look at their forked repo to see what they're up to. With lots of developers though it makes the main repo hard to read with lots of open branches and commits, so I can see why the fork model is used in a lot of open source projects. I'd be OK with working on a forked version of the repo and submitting PRs from there.

As for the "Fork" git client, I haven't paid for it, although looking at their web page they make it seem like you eventually will have to pay for it. I'd never pay for a git UI client... plenty of free ones available