I would recommend playing with https://learngitbranching.js.org/ More on reddit.com

Let's say you have written a social networking website. You write a bunch of code, then your site goes live on January 1. We will call this version 1.0. After the site is up and running you want to write some new features, and plan to release them on April 1.

Uh oh. Mid February you get a report of a serious bug in your program. You need to fix that bug now. You could add the bug fix to all the code you've written since January, but that has some problems. All that code you've written since January is not ready to release. It needs more work and won't be ready until April. If you code your bug fix on top of all the new code, you either have to release the unfinished code, or wait until April. Neither of those options work.

Instead, what you do is you go back in your repository to version 1.0. You code your fixes on top of that "older" version, and call this version 1.1. You then release version 1.1 and things are good.

However, there's one small problem. The history of your project now looks like this.

      v1.0               new code for Apr
      |                    |
o--o--o--o--o--o--o--o--o--o
       \
        o
        |
        v1.1 (bug fix)

The history of your project is no longer linear. It has two branches. If another serious bug comes up again, you can code it on top of version 1.1 and release that.

      v1.0               new code for Apr
      |                    |
o--o--o--o--o--o--o--o--o--o
       \
        o--o
        |  |
        |  v1.2
        v1.1

Eventually, when all the new code will be ready for the April release. But there's one last problem to solve. The bug fixes you put into production (v1.1, v1.2) are not part of the new code for April release. To solve this, you merge the two branches into a single branch.

      v1.0                    v2.0
      |                       |
o--o--o--o--o--o--o--o--o--o--o
       \                     /
        o--o----------------'
        |  |
        |  v1.2
        v1.1

Now you have a version 2.0 that contains all the new features for April, and the bug fixes that you had to release in February.

More on reddit.com

In general, a branch is a separate version of your code while commits represent changes (as u/insertAlias pointed out, commits are not stored as whole separate versions of your code, just the differences from the previous commit). There are many philosophies on how to use git, so your branching model is going to determine the semantics of your branches. I think it's best to show by example: Let's say you're developing a game. Let's go with git-flow for git workflow. You would have a master branch, which would contain releases of your game which you publish on GOG or whatever. Then, you would create a new branch from master, develop. Here you would have the current development version of the game, which would contain stuff that isn't necessarily ready for release. Then, when you're happy with the changes you made on develop, it's time to get those changes to master. This is where pull requests and merging come in. In this situation, you would accomplish a merge simply by switching to master and pulling develop into master. This takes the changes you made on develop and tries to apply them to master. A better practice for when you're working with multiple people would be to create a pull request from develop into master. This basically says "hey, I have some changes in develop I want to put to master, whoever is in charge of master should take a look at them and merge them in if they like then". For the pull request, you would add some reviewers (like your boss or coworkers at work), and when they approve it, you can merge. You had a problem with merge conflicts. This is completely normal and it's not so intuitive for people starting with git. When multiple people work on the same codebase, it's inevitable that two people will change the same thing in different ways. If that happens and you try to merge, git basically says "hey, I can't figure out which of these changes should be the new state of the branch, I need you, the human, to help me figure it out". Let's say you pulled develop into master and there are conflicts. Then, your working copy of master will enter a "merging" state, where in places with conflicts, you will see both versions of the piece of code that is conflicted. You can then make edits to make it right (either pick one of the two versions, or you can keep both, or even mix and match). After you fix all these conflicts, you will do a commit and your changes will be successfully merged. From what I understood from your post, all three of you were working on the same branch, pushing directly to develop. This is not a good way of doing things, because what could happen is you start working on something, meanwhile someone else does something and pushes it to develop, and then when you try to push, it says NOPE, because your working copy is based on a commit that is not the latest on develop. That means you would have to painfully manually integrate your changes almost every commit, and imagine that on a team with 10+ devs. This is where feature branches of git-flow are useful. Let's say you guys want your game to have a feature of posting your score to Facebook. You talk about it and you decide that you personally will implement that. You then do a branch from develop and name it feature/add-facebook-integration or something like that. You will then do all the work needed to finish that feature, all on this branch. None of your colleagues will commit to this branch, so you don't have to worry about any conflicts until it's time to merge. So you can peacefully develop and test your new feature against some version of develop, until the feature is ready to go to develop. Then you either create a pull request or merge it directly, while resolving any merge conflicts in the merge commit (which is likely to happen if your feature takes some time to make and your colleagues did something in the meantime). So with three of you, you can see that all 3 can be working on 3 separate features, and you will not have any conflict problems, only once a feature is finished and needs to be merged with the other people's stuff. Fetching means just getting information about possible changes in the repository from the remote (for example from your Github.com repository). Pulling means taking the changes and actually putting them on your branch. Your colleagues could indeed work on your repo because you gave them the rights to do that, in practice, teams usually use some branching model where only a select few project leads are allowed to commit to develop and master, and all commits to these branches must be merge commits, which means that all development is happening on feature or similar branches, which are branched from develop, the dev does some work on it, and then makes a pull request for the repository administrators to review and potentially pull into develop. Here is an image I found within 10 seconds of googling showing a simple git history with master, develop and two feature branches. Note: I'm certainly not a "git ninja" and I massively oversimplified some things and completely omitted others, but there are a ton of great resources out there for learning git, so I encourage you to go out there and learn. If anyone finds any inaccuracies in my comment, please tell me, I'll be glad to learn something new as well. More on reddit.com

First, it sounds like you're already fucked. You might not be, but it definitely sounds like you didn't know that you should be using feature flags, or you don't have enough pull at your company to convince people that they should be. All of you problems get easier when you can do this, don't try to look for a way to solve this in git... it only gets more painful. Trust me I've been there. Here is my thoughts. feature flags every.epic.gets.a.featureflag at least one. you can have more. make sure the naming is predictable make sure your PO is documenting these on the epics if not the stories. no exceptions. no. stop crying, just do it. master auto deploy to dev environment only promise here is that it builds and doesn't break other devs workflow QA aren't allowed to complain that it's broken, only allowed to let you know it's broken. feat/abc-123-my-new-feature branches MUST have a ticket in the name branches MUST start with feat, fix, chore, feature can be feature/... fix/.... chore/.... whatever. it's the tickets that go towards completing a story which in turn indicate completion of an epic. these branches are allowed to PR into master or release/... create branch protection rules in github: block PR until you get ticks. turn on CODEOWNERS, learn it. implement it. use some kind of PR preview service if your code can make use of it. vercel does this automatically, but you can spin up one on demand via github actions too. squash merge, disable all other methods you won't need them. block PR if out of date with master turn on Merge Queue. require it. have unit tests, run them. block PR if they fail. have a linter. run them. block PR if it fails. if you are using a typed language. block PR if that fails. the theme here is that PR merged === a promise that it won't break the other devs builds (outside of any dumb shit they're doing on their branches). release/... make these from master ONLY once made, NEVER ADD MASTER AGAIN. these are snapshots that either get force pushed somewhere else to trigger a build or from which artifacts are created and pushed (github actions can easily do this) these branches are put onto your QA queue: send to staging QA ok it send it to prod problems? make a PR from the release branch back into the release branch. ( a hotfix ). but now you also have to merge these fixes back to develop by way of an intermediary branch. You can automate this, there are github actions out there that handle this. deployments if you have only one app in the repo, then its easy. master: when package.json#version changes, push to dev environment when no package.json#version changes it means a PR is merged and you should do some kind of calculate the next version step release/vx.x.x: when no package.json#version changes: change bump a buildnumber on vx.x.x-buildnumber of the version and commit back. write a github workflow that only runs when you manually run it. this workflow should allow you to choose the target environment from a dropdown if you have more than one app: and you have yet to migrate to a correctly done monorepo: start learning NXDEV. no do not move to turbo. ignore bazel, pants etc they're way too complicated for you. focus on nxdev. create an auxillary workfow that rewrites your release deployment workflow based on a template so that you now have two dropdowns: apps, target environments Why feature flags? allow you do push code out the door that business isn't ready to activate allows you to avoid those fucking orrible long lived branches that nobody loves rebasing. seriously fucks those branches. allows you to a/b test things now There's so many tools out there that do feature flags, but some things you need to keep in mind: don't be a noob and use a configuration file instead of a service. just don't. You'll end up hating yourself and the mangers will resent the push to feature flags because now you cant turn a feature off/on without a deployment. dont use environment variables, they won't allow you to react to users differently. it's not a developer only consideration, your PO and your BA all need to know and understand what it means. Do us all a favour and drag them out of the last century so when we change jobs there's less dumbshit managers around. dont home roll your own service, pick one that has big infrastructure behind it. it'll get called A LOT. just use launchdarkly or a service better than it. standardise the ways in which you'll identify your user to the feature flag service across your apps. MAKE.THEM.BE.EXACTLY.THE.SAME. you'll see what i mean when you inevitably ignore this piece of advice. Ok now for the detractors QQ y u no git tag creating a release branch with the version in the branch name means it's a lot easier to write CI rules for and to add further hotfixes to for inexperienced devs QQ y u call it master go away QQ feature flags are too much work cool story. enjoy your life of rebase hell. More on reddit.com