Skip to main content
Software Dictionary

Learning path · Beginner

Working on a software team

Git, the way teams plan their work, and the habits that keep code healthy.

What your first week on a team feels like: sharing code with Git, the rhythm of agile work, and the testing and review habits that keep a codebase in shape.

35 pages3 chaptersabout 1 hours of reading

  • Version Control
  • Teams & Process
  • Testing & Quality
  • DevOps & Cloud
  • Software Architecture

Not started yet0/35 read

Start with Git

Progress comes from your reading history, kept only in this browser.

Chapter 1Sharing code

  1. 1GitVersion Control, p. 10Git is a free, open-source distributed version control system that tracks changes to files over time, so developers can collaborate and undo mistakes.
  2. 2RepositoryVersion Control, p. 34A repository is the storage location for a project, holding all of its files plus the complete history of every change recorded by a version control system.
  3. 3GitHubVersion Control, p. 25GitHub is a platform for hosting Git repositories and working on code together, with pull requests, code review, issues and the largest open-source community.
  4. 4CommitVersion Control, p. 5A commit is a saved snapshot of a project's files in Git, recorded with a unique ID, an author, a timestamp, and a message describing what changed.
  5. 5Conventional CommitsVersion Control, p. 6Conventional Commits is a specification for structured commit messages like feat: add search, so tools can write changelogs and pick versions automatically.
  6. 6Staging AreaVersion Control, p. 37The staging area in Git is a holding zone between your files and the next commit, where you place exactly the changes you want that commit to include.
  7. 7BranchVersion Control, p. 2A branch in Git is an independent line of development that lets you work on a feature or fix in isolation, without affecting the main code until you merge it.
  8. 8Git CheckoutVersion Control, p. 12git checkout switches to another branch or commit, or restores files to an earlier version; newer Git splits these jobs into git switch and git restore.
  9. 9MergeVersion Control, p. 29A merge in Git combines the changes from one branch into another, joining separate lines of development back together into a single, shared history.
  10. 10Fast-Forward MergeVersion Control, p. 8A fast-forward merge happens when the target has no new commits since the other branch split off, so Git just moves its pointer ahead with no merge commit.
  11. 11Merge ConflictVersion Control, p. 30A merge conflict happens when Git can't automatically combine two branches because both changed the same lines of a file, so a person must decide the result.
  12. 12Pull RequestVersion Control, p. 32A pull request is a proposal to merge changes from one branch into another, giving teammates a place to review, discuss, and test the code before it is merged.
  13. 13Code ReviewVersion Control, p. 4A code review is the practice of having other developers check code changes before they are merged, to catch bugs, improve quality, and share knowledge.

Chapter 2Ways of working

  1. 14AgileTeams & Process, p. 2Agile is an approach to software development that delivers working software in small, frequent increments and adjusts plans based on regular feedback.
  2. 15ScrumTeams & Process, p. 21Scrum is an Agile framework in which a small team delivers a product in fixed-length cycles called sprints, using defined roles, events, and artifacts.
  3. 16KanbanTeams & Process, p. 10Kanban is an Agile method that visualizes work on a board of columns and limits how many items can be in progress at once to keep work flowing smoothly.
  4. 17SprintTeams & Process, p. 26A sprint is a fixed-length period of one month or less, often two weeks, in which a Scrum team works toward one goal and produces a usable product increment.
  5. 18Sprint PlanningTeams & Process, p. 27Sprint planning is the Scrum event that starts each sprint, where the team agrees on a sprint goal, selects backlog items it can finish and plans the work.
  6. 19User StoryTeams & Process, p. 30A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
  7. 20Story PointsTeams & Process, p. 28Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
  8. 21Planning PokerTeams & Process, p. 16Planning poker is a team estimation technique in which members privately pick estimate cards for a task, reveal them at once, then discuss the differences.
  9. 22Daily StandupTeams & Process, p. 6A daily standup is a short daily meeting, usually 15 minutes or less, where a team checks progress toward its goal, plans the day, and raises blockers.
  10. 23TimeboxingTeams & Process, p. 29Timeboxing is setting a fixed maximum time for an activity in advance and stopping when it runs out, keeping work focused and forcing decisions about scope.
  11. 24RetrospectiveTeams & Process, p. 20A retrospective is a team meeting held at the end of each sprint to reflect on how the team worked and agree on concrete ways to improve next time.
  12. 25Definition of DoneTeams & Process, p. 7The Definition of Done is a shared checklist of quality standards that every piece of work must meet before a team can consider it complete.

Chapter 3Keeping code healthy

  1. 26Unit TestTesting & Quality, p. 35A unit test is a small, automated check that verifies one function, method, or class behaves correctly in isolation from the rest of the program.
  2. 27JestTesting & Quality, p. 13Jest is a popular JavaScript testing framework that bundles a test runner, assertions, mocking, snapshots and code coverage in one package with little setup.
  3. 28Integration TestTesting & Quality, p. 12An integration test is an automated test that checks whether several parts of a system, such as code, a database, and an API, work correctly together.
  4. 29Test PyramidTesting & Quality, p. 32The test pyramid is a model for balancing automated tests: many fast unit tests, fewer integration tests, and only a few slow end-to-end tests at the top.
  5. 30Test-Driven DevelopmentTesting & Quality, p. 34Test-driven development is a coding practice in which you write a failing test first, then write just enough code to pass it, and then clean up the design.
  6. 31LintingTesting & Quality, p. 14Linting is the automated analysis of source code, without running it, to flag likely bugs, style problems, and suspicious patterns before the code ships.
  7. 32CI/CDDevOps & Cloud, p. 9CI/CD is a set of automated practices that build, test, and release code changes frequently, so software can be delivered to users quickly and safely.
  8. 33Technical DebtSoftware Architecture, p. 45Technical debt is the future cost of extra work created when developers choose a quick or limited solution now instead of a better approach that takes longer.
  9. 34Code SmellTeams & Process, p. 5A code smell is a surface sign in code that often points to a deeper design problem, even though the code still works.
  10. 35RefactoringSoftware Architecture, p. 33Refactoring is the process of restructuring existing code to make it cleaner and easier to maintain without changing what the code does from the outside.

Along the way, compare

Pairs on this path that are easy to mix up, side by side.

More

Settings

EnglishTürkçe