* 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.
Overall I agree with the approach, but just wondering, why do the first point if you are already doing the last two?
> * 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
To me the noise at the start of every message is unnecessary, and given a lot of interfaces only display 80 chars of the message by default, it's not negligible.
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.
This seems reasonable to me. Devs and BAs flesh out business processes and ultimately document decisions in our Jira issue comments. When you have an issue id handy, it's not that hard to go read what the rationale was for a feature.
I have been ignoring Jira's AI summary, but I suppose that could be useful if the comments were very long.
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!
In the US, the purpose of a resume is to get an interview and the standard is short and to the point. That's where I am coming from.
Think of how much work the website generates for the person treating it as a resume. There's processing the navigation, clicking links, trying to figure out what is relevant.
The site is more of a work sample than a resume and those serve different purposes.
Of course other cultures may have different standards.
I am in the exact same situation as you. I live in Sharjah. my github: https://github.com/hammadfauz
Most of the times, I want to make something, but I have no idea what. If you or anyone has something neat to do, I'll be glad to participate.
To me, it is not at all alarming. But it might be due to my inexperience in dealing with truly huge code bases.
No matter what framework, in the end it's all JavaScript. So even if I develop a flashy app using a nice fat framework, it is still going to run unless JavaScript itself is changed.
That said, I can build an app in Angular today, and when something flashier comes out, I can code new features/modules to my app using that.
I think the main problem is about fixes. Invariably, something is going to go wrong in the future with whatever framework you use. Either security related or else. Then your version of {{framework}} won't be supported anymore and you'll have to:
- fix it yourself
- give up: turn off your app
- ignore: let people deal with the issue/be vulnerable
If your version of {{framework}} is supported, likely all you'll have to do is wait for a patch.
Interesting read. As with all things, absolute extremes must be avoided. If we stop and work out solutions to problems already worked out every time, when would we find time to build upon the solutions? Transfer of knowledge is one way, we as a species succeed even with the limited lives we have.
In programming, for example, while it is important to learn how basics work, if I try to write everything from scratch instead of using a library, I am doing it at the expense of furthering human capability. I mean, I just need to know, that I _could_ whip something up, if it didn't exist. Since it does, my time would be better spent on using it to create something even more functional.
* 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.
reply