usourcecontrol

Chapter 2

The desktop app

The daily loop: see what changed, lock what you are editing, commit, pull, and get anything back that you need back.

7 sections · Chapter 2 of 8

This is the chapter you will actually use. Almost everything you do with USourceControl on an ordinary day happens in one window, and that window is deliberately small: two panels, one for what your team did and one for what you did.

We start with the loop itself — commit, push, pull — then the thing that makes the loop safe on a game project, which is locking. After that comes getting work back when something goes wrong, and finally the three features you grow into: branches, shared plugins, and the settings that let the app keep working while its window is closed.

  ┌───────────┬────────────────────┬───────────────────────┐
  │           │  main ▾   Synced   │  Changes           4  │
  │  Project  ├────────────────────┼───────────────────────┤
  │  Tasks    │  ↓ 3 files to pull │  ☑ SK_Hero.uasset     │
  │  Releases │                    │  ☑ MainLevel.umap     │
  │  Settings │  HISTORY           │  ☑ P_Smoke.uasset     │
  │  Plugins  │  #24 Yuki  2h      │  ☑ MyCharacter.cpp    │
  │           │  #23 Marcus 5h     ├───────────────────────┤
  │           │  #22 Sarah  1d     │  message…    Push (4) │
  └───────────┴────────────────────┴───────────────────────┘
       nav          THEIR WORK              YOUR WORK
Figure 2-1. The two panels, and what each is for.

In this chapter

  1. 2.1Recording changesPick the files, write a message worth reading, link the tasks it closes, and push.
  2. 2.2Pulling your team's workHow incoming changes are classified, what the pull card is telling you, and why your local edits are never overwritten.
  3. 2.3File lockingClaim a level or Blueprint before you open it, so nobody can save over your day.
  4. 2.4History and undoing thingsReverting local changes, bringing back an old version, and reading what a commit actually did.
  5. 2.5BranchesTake a line of work away from main, then bring it back without leaving anyone's assets behind.
  6. 2.6Shared pluginsPromote a subfolder to a plugin, mount it into your other projects, and update it deliberately.
  7. 2.7Settings, tray, and background modeClose-to-tray, start with the system, the ignore-file editor, and where the build toolchain lives.

Summary

The loop is small: see what changed, lock what you are about to edit, commit with a message someone can read, push, pull. Everything else in this chapter is a variation on it.

The two habits worth building are locking before you open a binary file, and committing more often than feels necessary. The first prevents the only class of data loss the system cannot undo for you. The second costs nothing here and gives you somewhere precise to go back to.

You also know that nothing is destructive — reverts, restores, and deletes are all recoverable — and that branches exist for work that comes back, while editions exist for work that does not.

The next chapter is about the other half of a project: knowing what everyone is supposed to be doing, and turning that into release notes without writing them.

Was this helpful?

Back to top