Tutorials

Updated 2021-05-25

Git is a fabulous tool for source control management. While incredibly powerful, it can be a little daunting to learn at first. The following tutorials will help. They are organized from basic to more advanced.

• Learn Git Branching, an interactive tutorial is a very cool way to get your feet wet without having to download and install anything.
• GitFlow, a very good read on the basic workflow / process used for FlightNode development
• Forking Workflow, which was used in the FlightNode project for which this tutorial was originally written, with GitFlow-like branching structure at the core.
  • In your local clones, create a new remote called *upstream**, pointing to the main repository:
    git remote add upstream https://github.com/FlightNode/FlightNode.xyz
  • When you want to get the latest code from the shared repository, you’ll now be able to use
    git pull upstream <somebranch>.
  • 2021 update: this is still my preferred approach when working with a fork, although typically I am now working on a branch directly in the “origin” repository and don’t need to take this step.
• Pull Request Tutorial, with many nice screenshots and some advanced functionality, such as squash, rebase, and cherry-pick.
• Pro Git, the entire book, is available online for free.

Typical Workflow

Once you’ve created your forks on GitHub, and your clones on your workstation, a typical day might look like this:

1. Open Git-bash and cd to a workspace:
   cd /c/workspaces/FlightNode/FlightNode.Identity
2. Planning on working on Issue #10 today… so create a feature branch:
   git checkout -b feature/10
3. You don’t want to get out-of-date, or you may start running into major merge difficulties. Therefore:
   git pull upstream develop
4. Work on some code in your editor of choice.
5. Stage your code:
   1. New file:
      git add full/path/to/new/file.cs
   2. All existing files:
      git add -u :/
   3. All existing files in a particular directory:
      git add -u :full/path
6. Do some more work, stage some more work.
7. Commit your changes:
   git commit -m "10 - brief description"
   (for longer description, enter a brief description on first line, then hit enter to type the longer description starting on the next line. Finish with “).
8. Done for the day? Want to backup your code? Push to your fork:
   git push origin feature/10
9. Is the feature ready for other people to use? Then create a pull request in GitHub. In the pull request, add comments directly in the file if you want to explain something about your work. And invite others to review your code.

Graphical Git

SourceTree

Many people really like SourceTree, a tool from Atlassian. I have it installed and have not yet really used it, because I’m completely comfortable with using the command line. This tool is particularly useful when you want to visualize and compare many active branches.

Visual Studio Code

Visual Studio Code’s Git support is top-notch, when you don’t feel like using the command line. You can use the tool for all of the basic operations… and probably much more beyond the basics. But personally I generally use the command line for complex things.

Perhaps the best thing about VSCode’s integration: it makes the cumbersome process of un-staging and/or reverting your code changes very easy.

In this example:

1. Clicked a + icon (not shown) to move CONTRIBUTORS.md from “Changes” to “Staged Changes”.
2. Clicked on the file in “Staged Changes” in order to see the diff in the text editor.
3. Review the diff, confirm that it is what was expected.
4. Type in a message and click the checkmark to commit the change.
5. Click on ... to get the pull down menu.
6. Push changes.

That menu gives many more options, for example to help you create a new branch.

For more information, see Use Git version-control tools in Visual Studio Code.

Visual Studio 2015

2021 update: in VS2019, these features are now in the “Git Changes” panel and the user interface is further improved. See Git experience in Visual Studio for more detailed information.

Visual Studio 2015’s support is actually pretty good too. I was biased against it for a long time, probably because they automatically stage files (“tracked files”) and make you purposefully unstage them (“un-tracked files”). But for most people that’s probably not a bad thing. And while I haven’t used it in VS2013 in many months, I feel like the 2015 experience is somehow a little better and a little more powerful than its predecessor.

Posted with : Tech, Software Development Life Cycle, FlightNode: Citizen Science Bird-Monitoring