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.

Paint The Devil on The Wall (2026-Sep-10)

My Meditations    « Previously

There's a German saying that goes like "Don't paint the devil on the wall".

I just reversed that to match my life better. I ~~crave for~~ negativity, and so goes the title.

Now getting straight to the point:
"Who is the devil today?" It's Shalabh Gupta.

The reason I am feeling so negative today is because I think I might have got "3 strikes."

# Ignis (when it was at GitHub Actions stage)

# Leonis (which I didn't pick) POC

# PDF Reconciliation of Contracts

# Open-weights LLM Comparison

That's not 3, but 4 actually.
And my latest interaction with him goes like this: On an email requiring approval for budget GitHub Copilot, he wrote "let's talk tomorrow on Teams chat. Thanks"

That was at 10:20 PM yesterday.

Today, before 9:30 AM I pinged him:
"Saw your mail regarding the connect. Shall I call?"

To which he replied instantly: "Wait, I will call you"

And it's 11:30 AM now.
Now I am guessing that it's not a regular Connect. Most likely he will pass on some feedback (a guess again).

From the delay that he has introduced I am feeling the feedback is going to be horrible.

I am just praying that it doesn't happen around lunch — which is a typical "horrible feedback" time.

Moving on to the next point:

Imagining the worst...
"What if it's a layoff call?"
"If it is, then how prepared am I?"

And a dozen other questions like:

"Will there be a notice period?"
"Will I be paid for this month?" (Sep)
"Do I have enough for survival if I am released?"

"Do I have enough for this month and next month?"

"How will I disclose the news to my near-and-dear people: mom, ***, Anu, and rest."

"What are my monthly expenses today?"

"Did I take care of my baseline?"
"Did I pay enough attention to Tri Nagar?"

Now let's do some math:

Balance in current account : 1.1 Lakh
Expected expenses for remaining month of September: 20 K

Around left for next month of Oct : 90 K

Days worked in September : 10-12
Estimated salary to be credited for month of September : 1 L

That means cover for next month after Sep, Oct i.e. Nov : SECURED

That means 3 months to find a job before my bank balance goes zero. 

— * —

Next steps:

# Update resume

# Prepare for interviews

My Meditations    « Previously

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 »