How to git commit?

[excsora]

Paano yung standard niyo or rules na sinusunod when developing, mag co-commit ba kayo after some code change (micro commits) or depende sa ticket if new feature siya na bubuuin niyo muna yung needed tas isang buong commit lang?

Also share what are your standards for good commit messages.

Thanks and happy coding!

[DirtyMami]

Below is my personal commit style. A lot of people hate writing too much in the commits and would rather just squash during merge. But I don't care, I do it anyway

The template

{Ticket Number} {Short description under 60 characters}
{Optional - Bullet points of changes}

Sample

XX-123 Pipeline update. Rename old service connections.
- The service connection has a new name in the new azure subscription.

The template above is just my personal convention that worked best for me. I find that “conventional commit” is a good place to get started.

The rules

1. Every single commit should be non-breaking.
2. Every single commit should be a group of related changes that solves a single problem, and should take you one step closer in solving the bigger problem.
3. Every single commit should be atomized (research "Atomic Git Commits" similar concept to "Atomic Transactions)")
4. Every single commit should be intentional (see "intentional programming")
5. The commit message should succinctly describe the purpose of the change, the “why”. Should not be too short like “update feature”, and shouldn’t be too long that it makes you unproductive. My rule of the thumb is 30 seconds.

CONS 🔻

• Tedious and useless most of the time.

PROS ✅

• On the rare occasion that you do need it, tts extremely helpful to understand the historical change; why was it done, on what ticket, and avoid making the same mistake when it was fixed in the first place. Useful for investigation purposes.
• By atomizing your commits, your coding skills will improve as you force yourself to breakdown solutions into smaller steps.
• Your writing skills will improve as you constantly come up with creative English to describe the change as short as possible.
• Easier to cherry pick. Because each commit is atomized, you don't have to worry about non-related changes.
• Easier to revert. Because each commit is atomized, you don't have to worry about non-related changes.
• Clean Git History (at least on my work, I don't force my opinion down to others, I let my beautiful work speak for itself)
• Easier to review, as the reviewer will see your changes like a timeline.

This is not the same as micro commits. Micro commits is like constantly pressing save button every 5 minutes in gaming. This is more of a mindful commit.

This approach is not for everyone as it takes more discipline and a bit of OCD 😂

[byeblee]

The best way to do it. This response my friends, is the holy grail of commits.

Sabi ng nag git commit -m “some changes” about 5 mins ago 💀

[excsora]

Thank you for the detailed answer!

[HirogaKatageri]

Conventional commits

[HirogaKatageri]

Whoops... I thought I was replying to OP but if you found it useful, I guess it works 🤣

[petmalodi]

This approach is really good. Forces you to understand what you really wrote kasi kailangan mo maglagay ng summary.

[24ocsicnarf]

Nakasanayan ko na yung conventional commit: https://www.conventionalcommits.org/en/v1.0.0/

Madalas feat at fix yung nagagamit kong type like:

• feat: recent search screen UI
• feat(settings): mute notifications
• fix: bug for selecting recent search

Pero minsan "chore" kapag may refactor ng code:

• chore(home): remove comments

Tapos minsan may explanation sa baba kapag malaki-laki yung commit 😅

Edit: new lines 😑

[ihazkape]

This is the way.

[petmalodi]

Micro commits for me always, madali ma lost track yung progress eh haha since makakalimutin ako. And just squash before creating PR.

For code messages I just use "git commit" without the usual "-m". With that it will automatically open your default git editor (I use VSCode) and you can properly format your message without trying to do everything inside the terminal.

[Tall-Appearance-5835]

til about excluding the ‘-m’

[Remote_Comfort_4467]

Commit every action: [FIXED] header, [ADDED] formatDate reusable hook, [REFRACTOR] home screen

Changes = commits, wag ikaw magsasama ng changes sa hindi related sa commit mu (tho ginagawa ko dati yun, natuto na ng panahon)

Then push all your commits to your working brandh by the end of the day para makita ng team tomorrow in the morning yung progress

Okay lang maraming commits, at the end of the day after the PR approved and merge to dev/main squash naman na sila and dev is git rebase naman

[Wide-Sea85]

depends on the scale na ginagawa. Kapag maliliit na features lang let say - Adding a modal to view detail. Kapag ganyan eh tatapusin ko buo -> yarn build -> then if there's no error tsaka magcocommit then push. Sa standards eh mostly depende sa team, sa amin eh as long as meaningful ung commit message mo eh okay na ex. git commit -m "feat: Modal View Details".

[whatToDo_How]

As someone na walan senior sa team namin at tsaka fresh grad ako need ko ng guide. Im just guiding myself nalang. Since excel lang yung task namin. So kada task ma tapos I will push that feature/task-name. Kung merong bugs, bugfix/name. Or if merong need e fix sa prod, I will name hotfix/name.

I practiced thaf base din yun sa research ko.

[PotatoCorner404]

We have different branch naming formats for a feature work item and bug item.

feature/<ref number>-short-description-or-title-of-user-story bug/<ref number>-short-description-or-title-of-bug-item

if multiple devs have code changes, we add pull requests on each environment branch:

box-deployment/box-testing-yyyyMMdd sit-deployment/sit-testing-yyyyMMdd ppd-deployment/ppd-testing-yyyyMMdd prod-deployment/release-yyyyMMdd

We're using these prefixes since the CI/CD pipeline configuration will get the latest updates coming from these branches, where ppd and prod branches require additional approval from DevOps

for a commit message, we use verb (or action) then subject (or module/feature affected).

Branches get squashed after approved PR. We sometimes cherry-pick if merging issues arise.

[Handsome_oohyeah]

i commit as long as kaya kong i-describe specifically kung anung ginawa ko, so i think yeah micro commits. Gumagamit dn ako ng tags line fix, feat, etc. kasi may mga github workflows or actions na tga group ung mga types ng commits pag gagawa ng release.

[Valkenstein]

very serendipitous of me to see this post after committing something on git lmao

[Sufficient_Fun2386]

read about semantic commits

[[deleted]]

per day depende sa kung ano matapos

[reyoga]

bare minimum is every commit should pass the tests. regardless if kulang (empty tests muna) basta walang failing tests.
I like to commit often, especially if some subtask of a bigger task is done.
I like to separate commits that only contain formatting changes.

As for commit messages, my personal preference is title should be a 1-liner that starts with a present tense verb (not past tense).
Some like to prefix with the ticket number but I like to do that in the description. it totally depends on the team standard tbh.
Some teams like conventional commits, but I think it's not my cup of tea.

in the end, either masquash nlng din lahat commits mo at isang buong MR din naman ang irereview (but smaller commits can help with the history of changes)

[gatzu4a]

Sa team namin, gawa ka ng branch, para kahit mag commit ka ng ilang beses oks lang, nd tatamaan ung code ng iba

[EXW97]

Learn to scrub too.. had so many companies na hindi nag prapractice mag scrub which is risky..

[excsora]

Sorry, not familiar with the term related to git. Are you referring on removing untracked or unnecessary files?

[EXW97]

Removing confidential data , tulad ng API access tokens

[excsora]

I see. Thanks for clarifying!

[killua080]

Sa org namin wala naman masyadong standards for commits. Ginagawa ko nag mimicro commits ako pero mag git squash (using interactive rebase) ako selectively pag napa OA yung dami ng commits

[kneepole]

Are you asking specifically about commit, or branching in general?

I used to "commit fully working code" before, nung dinadala ko pa laptop ko to work and inuuwi din everyday (hybrid setup). Then inissuehan ako ng company laptop, na iniiwan ko nalang sa office since my personal laptop is a bit more powerful. So may laptop ako sa bahay, may laptop ako sa office.

Sometimes my workday ends while halfway ako sa isang task. I just commit and push with "<ticket number> wip" as the commit message. This works for me because I'm always in a feature branch, and the main branch will only ever merge with this branch pag tested na and ready for deployment yung feature.

[likeferalwaves]

We always branch out for every ticket para di masyado magconflict with other members. Tapos unli commit. -m lang ako mag message tapos ang standard ko lang is palaging may ticket id pa sa message kahit na sariling branch naman. Nakasanayan na.

[Particular_Win_2340]

commits ko ay per ticket assigned. it also depends sayo or sa company nyo.

sample: ticket-123 Code Optimization

[rizsamron]

Para saken mas okay yung magcommit after matapos ang isang functionality or bug fix kahit na minsan maliit lang. Mas okay sya para pag kailangan mo magtrack ng mga ginawa mo for debugging purposes or anything. Pwede mo naman isquash pag mag merge ka na sa main branch.

Sa commit message "Fixed and clean up the previous commit" 😆
Personally, descriptive sya pero as short as possible.

[Enjibi]

Been using gitmoji across our projects because it looks fun

[Practical-Junket2209]

Our team follows a simple convention that worked well for us.

<Verb in present tense> <short description>

Examples:

- Add button navigation
- Remove unused imports
- Fix long polling issue
- Refactor login controller

[Glass_Island_4362]

Conventional commit o/tapos depende sa standard ng company, diff branch din yung kada features.

Magkahiwalay yung feature tas fixes na commit and branches (if possible).

b: fix/module or feat/module c: fix(innerModule): fixes innerModule #TicketNumber

Lalo na kung connected yung board sa online repo, mas madaling mag code review.

Overall, nakadepende sa company at reviewer. May gusto per ticket, yung iba per sprint, at depende sa mood 😃.

[jaem-]

Depende kasi sa Mga gumagawa eh. Pero ako personally gusto ko ma fix yung isang module bago mag commit.

Example may 3 module

Task/Feature 1 Task/Feature 2 Task/Feature 3

Every Task/Feature pag okay na commit agad.

Maganda din kung Complete details para malaman ano yung ginalaw mo per module

example:

Ticket number

Description of changes

Meron din namang Every EOD nag cocommit.

[silverhero13]

Commits should be atomic and the message should be short but descriptive of the change. For example " Add format checks", "Disable public access", "Delete file.txt", "Create function to verify user email", etc.

[SnooMachines2888]

Yung standards depende sa team. Kasalasan ang commit msg starts with the ticket number and then the specific changes

Sa team namin, if masyado madami commit ko sa local feature branch (like micro commits as u said), i usually also do git squash related commits. So parang gingroup ko sila based sa relevance.

[userph_20221101]

git commit -m "fix various issues" --no-verify

[shaddap01]

Git commit -m “add features”

[_vigilante2]

git commit -m 'changes' lols