This lesson is adapted from materials from a previous course, ITMG 533. Gemini Code Assist was also active during the development of these materials, and some text was generated with its help.
By the end of this chapter, you will be able to:
git init: Initializes a new git repositorygit clone: Copies a repository from the cloudgit pull: Pull changes from the cloud to an existing local copygit add: Adds changes to the staging area - ready for commitgit commit: Create a commit comprising all changes in the staging areagit push: Push all commits to the cloudgraph TD
E[Clone/Pull from cloud] --> A[Make changes]
F[Initialize repo] --> A
A --> B[Stage changes]
B --> C[Commit changes]
C --> D[Push changes to cloud]graph TD
E[Clone/Pull from cloud] --> A[Make changes]
F[Initialize repo] --> A
A --> B[Stage changes]
B --> C[Commit changes]
C --> D[Push changes to cloud]
Git will not guess what you want, and git will not automatically do things for you. You have to tell it what to do.
For anyone who is annoyed when your text editor automagically knows what you want better than you do and reformats your entire document, this is a feature.
A number branching strategies have been proposed, each with different use cases (Haddad 2022).
GitFlow is a heavy, structured branching strategy proposed by Driessen (2010) that has received a lot of attention over the years.
master or main: Stable, production-ready codedev or develop: Latest integrated code for the next releasefeature/*: New features developmentrelease/*: New production release preparationhotfix/*: Quick patches to production issues
GitHub Flow is a simpler, continuous-delivery-focused strategy (“GitHub Flow” n.d.), where the main branch is always in a deployable state.
feature branch from main.feature branch.feature branch into main.main stable.
GitLab Flow is a hybrid strategy that combines elements of GitFlow and GitHub Flow (“What Is GitLab Flow?” n.d.).
production, staging) in addition to the main branch.feature branch from main.main.main branch is automatically deployed to a testing environment.main into a staging branch, which is deployed to the staging environment.staging into a production branch, which is deployed to the production environment.
Trunk-based development is a strategy where developers merge small, frequent changes directly into a single, shared “trunk” or main branch.
Core principle: All developers work on the same branch.
Key practices:
main branch is always in a releasable state.Simplicity vs. Complexity: Choose a strategy that matches your team’s size and project’s needs.
Release cycle: A strategy should align with your release cadence (e.g. frequent, continuous, or scheduled).
Team discipline: The simpler the strategy, the more discipline is required from the team.