Repository files navigation

I have my personal commit workflow using GitHub Desktop.The catch is that I'm not installing Git.

You don't need Git to use GitHub Desktop.But you need a technique for you to have your commits asverified.

I'm actually into branches because I feelI can group my commits into related featuresor bug fixes.

My pattern of naming is thedate andthecount commit which I callsprint,

this is an example of my branches in a day

december12-sprint1,december12-sprint2,december12-sprint3

I can easily remember the things that happenedthere.

I call itsprint because one, it's the term being usedin Agile and two, it is a continuous effort sittingin front of the computer coding without long breaks,much like a real sprint, because that's thenature of coding in itself, or else you will bedistracted by lot of things and your train of thoughtwould be gone from time to time.

I'm using this not only in my personal projectsbut also in my company's projects.

1. I always fetch and pull it.

2. Then start coding.

3. When it's time to commit it, I don'tcommit it on the default branch.I'll make a branch instead and bring thechanges to it, so there will be nonew commits left on the default branch.

4. My way of naming new branches isthe date and the count of the commitlikedecember12-sprint1.I already explained this above.

5. I usually will get thecommit summary byusing thetab key but if I need to makea very important summary I will manually do so.

6. Once it is committed, I will publish the branch.This is an unverified commit on GitHub.Then the branch will pop up on GitHub. I'll reviewit and make a PR then merge. This is a verifiedcommit now. This is clean actually. When it's notworking at the production setup, I can alwaysrevert it on GitHub.

7. I will switch to master leaving the changes on thatbranch. Then I will fetch again and pull those recentchanges. Done. I now have the synced local project.I start the next task.

fetch -> pull -> make changes -> create branch -> switch branch-> commit changes to that branch -> publish branch on GitHub-> make PR -> merge ( canrevert when needed) -> switch branchto default -> leave changes on the branch -> fetch -> pull