hammadfauz

If the pattern is consistent, it gets easier to ignore the noise when you don't need it. Like, a three/four digit number or a 3 letters and 3 numbers separated by a hyphen.

Sometimes, an issue might depend on another issue and contain commits from the other branch. Tagging each commit makes it easier to pinpoint the exact reason for that change.

If you do these things:

* File issues in a project tracker (Github, jira, asana, etc)

* Use the issue id at the start of every commit message for that issue

* Use a single branch per issue, whose name also starts with the issue id

* Use a single PR to merge that branch and close the issue

* Don't squash merge PRs

You can use `git blame` to get the why.

git blame, gives you the change set and the commit message. Use the issue id in commit message to get to the issue. Issue description and comments provide a part of the story.

Use the issue id, to track the branch and PR. The PR comments give you the rest of the story.

Hi HN,

I built Git-chain to help with branch management in trunk-based development workflows.

When you want to keep changesets small and reviewable, but still build new work on top of unmerged changes, Git can get messy fast. Git-chain makes it easier to track and manage these dependent branches cleanly.

Would love feedback — especially from teams doing trunk-based development!

Fixed. Thanks for pointing out.

Basically, I have created this as a substitute for a resume. I would like suggestions on what to include to make me more likely to be hired.