How to propagate changes from one branch to other branches of the team?

Now let's say I create a setup script for the project (I am product owner) and there are 5 developers working in five branches. How do I pass on my changes?

ChatGPT said:

Yes. In your situation, you should also work on a branch, even though you're the Product Owner.

The cleanest approach is:

main
  │
  ├── dev-1-task
  ├── dev-2-task
  ├── dev-3-task
  ├── dev-4-task
  ├── dev-5-task
  │
  └── setup-script   ← your branch

Your setup-script workflow

Suppose you create:

Bash
git checkout main
git pull
git checkout -b setup-script

You add:

setup.ps1
README.md
.env.example
requirements.txt
...

Then:

Bash
git add .
git commit -m "Add project setup script"
git push -u origin setup-script

Now you have a few options.

Option 1 — Recommended: merge your setup branch into main

If your setup script is independent of the developers' work:

setup-script
     │
     ↓
    main
     │
     ├── dev-1
     ├── dev-2
     ├── dev-3
     ├── dev-4
     └── dev-5

Once your PR is merged into main, the developers can bring your changes into their branches:

Bash
git checkout dev-1
git pull origin main

Or, if you want to be more explicit:

Bash
git fetch origin
git merge origin/main

Now Developer 1 gets your setup script.

The other developers do the same.

---

Option 2 — If you don't want to merge into main yet

You can merge your branch directly into each developer's branch:

setup-script
    │
    ├────────→ dev-1
    ├────────→ dev-2
    ├────────→ dev-3
    ├────────→ dev-4
    └────────→ dev-5

For example:

Bash
git checkout dev-1
git merge setup-script

Then:

Bash
git checkout dev-2
git merge setup-script

etc.

But I wouldn't recommend this as your normal workflow, because now your setup changes have to be manually propagated to five branches.

---

An even better team workflow

If you have 5 developers working simultaneously, I'd consider having an integration branch:

                    main
                      │
                      ↓
                   develop
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
    dev-1           dev-2          dev-3 ...

You create your setup changes:

main
 │
 └── setup-script

Merge:

setup-script → develop

Then developers periodically update their branches from develop:

Bash
git checkout dev-1
git fetch origin
git merge origin/develop

This gives you:

main = stable/releasable code

develop = current team integration

feature/* = individual developer work

---

One thing I'd strongly recommend

For a setup script, don't make developers copy/paste your changes manually.

Put the script in Git:

project/
├── setup.ps1
├── setup.sh
├── README.md
├── .env.example
├── src/
└── ...

Then the repository itself becomes the source of truth.

A developer can simply do:

Bash
git clone <repo>
cd project
.\setup.ps1

And when you improve the setup script later, they can get the updated version through Git.

---

For your specific situation

Since you're the PO and the 5 developers are already working on branches, I'd use:

main
  │
  └── develop
       │
       ├── feature/dev1
       ├── feature/dev2
       ├── feature/dev3
       ├── feature/dev4
       ├── feature/dev5
       │
       └── setup-script

You don't need a special "PO branch." Your setup script is simply another piece of work, so treat it like a normal feature/change and merge it into the team's integration branch.

If the setup script is very small and independent, I'd actually merge it to main and have everyone pull main. That's simpler than introducing develop just for this.

When to create Git branches?

If there are five developers on a project working on separate task but (likely) common files: should I create one branch for all, or five branches for five developers?

ChatGPT said:

If 5 developers are working on 5 separate tasks, the usual and safer approach is:

✅ Create 5 feature branches — one per developer/task

For example:

main
│
├── feature/login
├── feature/dashboard
├── feature/payment
├── feature/reporting
└── feature/notifications

Each developer works on their own branch:

Bash
git checkout -b feature/login

and commits only their task:

Bash
git add .
git commit -m "Add login functionality"
git push -u origin feature/login

Then they create a Pull Request into main (or usually a develop/integration branch).

Why not one branch for all 5?

If everyone works on one shared branch:

feature/all-developers
       ↑
  5 developers

you can run into problems:

• Developer A's unfinished code gets mixed with Developer B's work.

• It becomes difficult to review changes.

• One developer's bug can block everyone.

• Reverting one developer's changes becomes harder.

• Merge conflicts become harder to understand.

• You lose a clean history of which work belongs to which task.

But what if they modify common files?

This is the important part.

Common files do not mean you need a common branch.

For example:

Developer A → app.py
Developer B → app.py
Developer C → utils.py
Developer D → app.py
Developer E → config.py

You should still normally have:

feature/A
feature/B
feature/C
feature/D
feature/E

Git will handle the branches independently. When the PRs are merged, conflicts can be resolved if two developers changed overlapping parts of app.py.

A good workflow for your team

I'd recommend:

                 main
                  │
          ┌───────┴────────┐
          │                │
       develop          (optional)
          │
    ┌─────┼─────┬─────┬─────┐
    ↓     ↓     ↓     ↓     ↓
   Dev1  Dev2  Dev3  Dev4  Dev5
    │     │     │     │     │
 feature feature feature feature feature
   /A     /B     /C     /D     /E

Each developer:

1. Starts from the latest integration branch.

2. Creates their own feature branch.

3. Does their work.

4. Pushes the branch.

5. Creates a PR.

6. PR is reviewed.

7. Merge into develop.

8. Periodically merge develop into main.

One important practice when files are shared

If Developer A and B are both likely to modify app.py, tell them early.

For example:

A: I'll modify the authentication section of app.py.

B: I'll modify the API routing section of app.py.

Even better, if practical, split large common files into smaller modules. That reduces Git conflicts substantially.

In short

Situation	Recommended
5 developers, 5 tasks	5 branches ✅
1 developer, multiple related changes	1 branch
Everyone working on exactly the same feature	Possibly 1 branch, but usually still separate branches + PRs
Shared/common files	Still use separate branches
Experimental work	Separate branch
Production code	Don't have everyone directly commit to main

Rule of thumb: one branch per unit of work, not one branch per project.

And if you're already working with branches like fixes_and_enhancements_20260917, the same principle applies: make the branch represent a specific set of changes, rather than becoming a permanent shared development branch.

Git and GitHub Notes by Megha (Pg4)

« Previously

# Git + GitHub Notes — Last Page [4]

## Connect Local Repository to GitHub

### Clone / SSH Notes


git clone 


- Clone the repository from GitHub to the local computer.
- SSH key can be used for authentication.

### SSH Key

- Generate an SSH key.
- Copy the public key (`.pub`).
- Add the SSH key to GitHub.

The notes appear to refer to adding the SSH key under GitHub account settings.

## Initial Local Repository Setup


touch index.md
git add .
git commit -m "..."
git push origin main


- The `git add` + `git commit` + `git push` sequence is used to commit local changes and push them to GitHub.

## Configure Git


git remote -v
git config --global init.defaultBranch main
git branch -M main


- `git remote -v` — check the remote repository URL.
- `git config --global init.defaultBranch main` — set the default initial branch name to `main`.
- `git branch -M main` — rename the current branch to `main`.

## Steps to Push Local Repo to a Remote GitHub Repo

1. Create a repository on GitHub.
2. Copy the repository URL.
3. Add the GitHub repository as the remote:


git remote add origin 


4. Check the remote:


git remote -v


5. Change/rename the branch to `main` if required:


git branch -M main


6. Push the local `main` branch to GitHub:


git push -u origin main


7. Pull changes from the remote repository:


git pull


- `git pull` will bring the changes made by others into the local repository.

## GitHub Desktop

- Download GitHub Desktop.
- Create repository.
- Open with VS Code.
- Click the **+** button to stage changes.
- Publish repository.
- Pull requests.
- Create pull request.
- Merge someone else's branch into your branch.

> The handwritten note also mentions that publishing may require connecting/authenticating with GitHub.

## Fork

### What is a Fork?

A **fork** means creating a copy of another person's repository in your own GitHub account so that you can make changes without directly affecting the original repository.

text
Original Repository
        |
        ↓
      Fork
        |
        ↓
Your own copy
        |
        ↓
Make changes
        |
        ↓
Create Pull Request


- A fork is useful when you do not have direct write access to the original repository.
- You can make changes in your fork and then create a pull request to contribute those changes back to the original repository.

« Previously

Git and GitHub Notes by Megha (Pg3)

« Previously    Next »

# Git + GitHub Notes — Page 3

## Resolve Merge Conflict (Manually)

- Just open the file.
- Keep or delete the unwanted/conflicting changes.
- Save the file.
- Then run:


git add .
git commit -m "..."


## Git Stashing

**Stashing:** If you have made some changes but you need to do some emergency/other work, you can temporarily save your current changes using `git stash`.


git stash
git stash list
git status


- `git stash` — temporarily saves your current changes.
- `git stash list` — shows the saved stashes.
- `git status` — should show a clean working tree after stashing.
- When you want the changes back:


git stash pop


- `git stash pop` — brings back the stashed changes.

## Best Practices

1. Create an isolated branch for each feature.
2. Never develop directly on the `main` branch.
3. Delete merged branches.
4. Use meaningful branch names.
5. Keep branches short-lived and merge them as soon as possible.

## Git Tags

Git tags can be used to mark specific points/versions in the repository.

### Types of Tags

1. **Annotated tag**
   - Contains additional information/metadata.
   - Example:


git tag -a v1.0 -m "my release"


2. **Lightweight tag**
   - A simple tag pointing to a specific commit.
   - Example:


git tag v1.1


### Other Tag Command


git tag


- Lists the tags in the repository.

## Git Rebase


git rebase master


- Rebase can be used to replay the changes from one branch on top of another branch.
- This can help avoid unnecessary merge commits.

« Previously    Next »

Git and GitHub Notes by Megha (Pg2)

« Previously    Next »

# Git + GitHub Notes — Page 2

## Notes

(10) Again, I’ll make commit to check how some new changes to Git history.

    git add .
    git commit -m "updated xxx.yyy"

(11) git restore [filename]
     → to discard changes.
     Again: git add and so on, so forth.

(12) git restore --staged filename
     git restore filename → then change back [??]

(13) git branch
• Instead of doing some work on main branch we can do it on independent branch.

(14) git branch
     → It will show: current/available branches

(15) git switch 

(16) git ls-files
     → files to be tracked by Git.

• If you want to merge the changes you have done in your branch [to the main branch]:

    git switch master

(17) git merge [branch]

     It will make [changes] from new branch to be applied on "master" branch.

(18) git branch -d [branch]
     (delete branch)

(19) If you have some file on one branch, you pushed to main branch & again if you try to push the same file from another branch into main branch, then that is: [merge conflict].


## Main Commands Visible on This Page

git add .
git commit -m "..."

git restore 
git restore --staged 

git branch
git switch 
git ls-files

git merge 
git branch -d 

## Branching Workflow

main branch
    |
    +---- new branch
             |
        make changes
             |
        commit changes
             |
       merge into main
             |
          main branch

## Key Concept

**merge conflict**: when changes from different branches affect the same file or the same part of a file, Git may require the conflicts to be resolved before the branches can be merged.

« Previously    Next »

Git and GitHub Notes by Megha (Pg1)

Next »

# Git + GitHub Notes

### Git
- Distributed version control system.
- Works offline as well.

### Version Control Systems

**Centralized**
- All data is in one server.

**Distributed**
- Every developer has a copy.
- Changes can be made in the local repository and then pushed/shared.
- GitHub is an online platform where repositories are hosted.

### Steps — Install Git

1. Go to the folder location you want to track.
2. Open CMD:
   
   git --version
   
3. Check Git status:
   
   git status
   
4. Configure username:
   
   git config --global user.name "mayank"
   
5. Configure email:
   git config --global user.email "mayank@gmail.com"
   

### Git Workflow

**Working Directory → Staging Area → Local Repository → Remote Repository**

- Add:
  
  git add 
  

- Commit:
  
  git commit -m "..."
  

6. Example:
   
   git add index.css
   

7. Commit:
   
   git commit -m "my first website ready"
   

8. View commit history:
   
   git log
   
   or
   
   git log --oneline
   

9. `.gitignore`
   - Used to tell Git which files/folders should not be tracked.
   - Example: ignore files/folders that should not be pushed to the repository.

10. Git does **not track empty folders**.
   - To keep an otherwise empty folder in Git, create a placeholder such as:
   text
   .gitkeep
   
   - Then Git will track the folder through that file.

### GitHub

- GitHub is an online platform where repositories are hosted.
- A developer can push a local repository to GitHub.
- GitHub allows repositories/code to be shared and collaborated on.

### Important Flow

text
Working Directory
       ↓
   git add
       ↓
Staging Area
       ↓
 git commit
       ↓
Local Repository
       ↓
   git push
       ↓
Remote Repository / GitHub

Next »

See All Posts on GitHub    « Previously

Git Checkout vs. Git Switch: Comparing and Contrasting Two Branch Commands

Git provides several commands for working with branches, but two commands that often cause confusion are git checkout and git switch. Both can be used to move from one branch to another, but they are not equivalent in purpose or design. Understanding the difference helps you write clearer Git commands and avoid accidentally performing the wrong operation.

1. Why Are There Two Commands?

Historically, git checkout was the main command used to change branches. However, it eventually became a multi-purpose command that could do several unrelated things, including switching branches and restoring files.

This created a common source of confusion. For example, the same command could mean "move to another branch" in one situation and "restore this file" in another.

To make these operations easier to understand, Git introduced git switch and git restore. The idea was to separate the responsibilities that had previously been handled by git checkout.

The key idea: git switch is specifically designed for changing branches, while git checkout is a broader, older command that can change branches as well as check out files and specific commits.

2. Using Git Checkout to Switch Branches

Before git switch existed, developers commonly used git checkout to move from one branch to another.

git checkout feature-login

This tells Git to move the current working directory from the current branch to feature-login.

For example, suppose you are currently on main:

git branch

* main
  feature-login
  bugfix

Running:

git checkout feature-login

changes the current branch to feature-login.

3. Using Git Switch to Change Branches

The same operation can be expressed more explicitly with git switch:

git switch feature-login

The meaning is immediately clear: switch the current branch to feature-login.

This is one of the main reasons git switch was introduced. Its purpose is narrower and therefore easier to understand.

4. Comparing the Basic Syntax

Operation	Git Checkout	Git Switch
Switch to an existing branch	git checkout feature	git switch feature
Create and switch to a new branch	git checkout -b feature	git switch -c feature
Switch to another commit	git checkout abc123	Not its primary purpose
Restore a file	git checkout -- file.txt	Not supported for this purpose

5. Creating a New Branch

Both commands can create a new branch and immediately switch to it.

Using git checkout

git checkout -b feature-payment

The -b option tells checkout to create the branch and then move to it.

Using git switch

git switch -c feature-payment

Here, -c means create a new branch and switch to it.

The result is essentially the same: a new branch named feature-payment is created and becomes the current branch.

6. The Important Difference: Checkout Does More

The biggest difference between the two commands is not what they can do when switching branches, but what checkout can do beyond branch switching.

Historically, git checkout has been used for several different tasks:

• Switching between branches.
• Creating and switching to a new branch.
• Checking out a particular commit.
• Restoring files from another commit or branch.

By contrast, git switch focuses on branches. It does not replace every capability of git checkout.

7. Checkout Can Move to a Specific Commit

One common use of git checkout is moving to a particular commit rather than a branch.

git checkout abc123

This places Git at the specified commit. Because that commit is not necessarily the tip of a branch, you may end up in what Git calls a detached HEAD state.

git switch is intentionally focused on branch switching, so checking out an arbitrary commit is not its primary role.

Important: Being in a detached HEAD state is not inherently an error. It is useful when you want to inspect or experiment with a particular commit without moving an existing branch pointer. However, commits created there can become difficult to find if you do not create a branch to keep them.

8. Checkout Was Also Used to Restore Files

Another source of confusion was that git checkout could operate on files. For example:

git checkout -- README.md

Historically, this was a way to replace the working copy of README.md with the version from the current commit.

Modern Git provides git restore specifically for file restoration:

git restore README.md

This separation makes Git's commands easier to understand:

git switch   → work with branches
git restore  → restore files
git checkout → older, multi-purpose command

9. Switching to a Remote Branch

git switch also provides a convenient way to create a local branch that tracks a remote branch.

For example:

git switch --track origin/feature-login

This creates a local branch associated with the remote-tracking branch and switches to it.

With modern Git versions, Git can often infer the remote branch when the local branch does not yet exist:

git switch feature-login

If Git finds an appropriate remote-tracking branch, it can create the local branch and establish the tracking relationship.

10. Why Git Switch Is Easier to Understand

Consider the following two commands:

git checkout feature-login
git switch feature-login

Both can switch branches, but the second command communicates its intention more explicitly. When you see git switch, you immediately know that the operation concerns branches.

This is particularly useful for beginners because it reduces the number of unrelated meanings they need to remember for one command.

11. Are They Completely Interchangeable?

No. They overlap when the task is switching branches, but they are not interchangeable in every situation.

Capability	git checkout	git switch
Switch branches	Yes	Yes
Create and switch to a branch	Yes, with -b	Yes, with -c
Track a remote branch	Yes	Yes
Move directly to a commit	Yes	Not its intended role
Restore files	Historically yes	No
Dedicated to branch operations	No	Yes

12. Which Command Should You Use?

For everyday branch operations, git switch is generally the clearer choice in modern Git.

For example, prefer:

git switch main
git switch feature-login
git switch -c feature-payment

rather than relying on git checkout for every branch-related operation.

However, you should still understand git checkout. You will encounter it frequently in older documentation, scripts, tutorials, Stack Overflow answers, and existing projects.

13. A Simple Mental Model

A useful way to remember the difference is to think about the verbs represented by the commands:

git switch → "I want to switch branches."

git restore → "I want to restore files."

git checkout → "I am using the older, multi-purpose command that historically handled both kinds of operations."

14. Final Comparison

git checkout and git switch overlap significantly when it comes to changing branches. If you run:

git checkout develop

or:

git switch develop

the intended result is the same: your working tree moves to the develop branch.

The difference is that git checkout is a broader, historically overloaded command, while git switch was introduced to make branch switching a distinct and easier-to-understand operation.

Therefore, a good modern rule of thumb is: use git switch when your intention is to work with branches, and learn git checkout so you can understand existing Git commands and older workflows.

See All Posts on GitHub    « Previously