re: "commit cadence" per Jared Knipp -- commits should always make sense when prefixed by (something like) "with this commit (I)". Old dev trick, makes things easy to understand. Consider...
[with this commit I] Patched feature XYZ to disallow access to unregistered users
[with this commit] Feature ABC is complete and ready for testing and staging
Planned commits as discussed, to me, speaks of a narrow view of Git and the underlying technology. Look into rebase+squash patterns as others mentioned. Also know how to stash as well as branch to increase workflow. And most important is local branch squashing for commit and review.
Professionally no team or job in my past would accept a "I'll commit again after I've finished this function" type commit in the stream.
A commit should be a "logical unit of work" (in master) such as a complete feature, fixed bug, RFC commit, etc. However you want to handle that privately and locally feel free, but that type of commit is not welcome in a large project.
Here is why, if you commit at the wrong checkpoints, don't squash and merge in, all that noise to a Sr Dev/CTO (like me) will provide a fragmented diff to perform a code review. Among other long term problems and bad habits for the team
I follow similar patterns as listed but on what I call a "local scratch" branch. I commit often and never (ever) push without reason. Instead I squash down to a new branch (learn rebase) and commit. The single larger commit, in the scope of a large project, is much easier to work with inside a team even if big.
So your thinking is valid, but how and where it applies is important.
The same flow can be accomplished using stashes. Additionally I suggest a GUI for GIT, there are various studies that empirically show that GUI based GIT and visual doff tools improve quality and cut review time. Or put another way, the command line is critical to know, but you will never, ever, read your diff as well in terminal unless you are deranged.
If you don't know what/when to commit presents 2 serious flags professionally. First for the team in not having a git protocol or understanding communicated, aka pending massive fail. Second flag on the person for not grasping fundamental tools. Sorry to be a hard ass, but I am the guy who un-fucks GIT in every company and I would not hesitate to review company GIT protocol. Commit as if there are 1000 people working on the project. The thinking presented here can be dangerous if not used correctly. The range of comments in this thread spans the entire scope of GIT, from "look what I know" to "I have a job, team, and deadlines and don't have time for rookie shit in my master".
If anyone wants to talk serious GIT strategy hit me up, love to talk GIT, so much to learn and share!
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
I think I was talking about my strategy on what you're calling the "local scratch branch" in this article. I hadn't really considered the larger scale beyond personal projects, but mucking up somebody's Git Repo is one of my huge fears. You've provided a ton of great methodology and mindset tips that really help. I'm definitely getting a GUI and rebasing/squashing my commits before pull request from now on.
Cool, it was hard to not come off as angry programmer. I tried to sell these skills to General Assembly (NYC) re:GIT course and they wanted no part of anything helpful for actual career. I use Tower for GIT, been on it for 8 years, still have command line chops (saved to when shit goes really bad). Ping me on TwitterZ to talk more. I had the same fears on GIT way back and developing a local strategy to look like I know wtf I am doing was key.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
re: "commit cadence" per Jared Knipp -- commits should always make sense when prefixed by (something like) "with this commit (I)". Old dev trick, makes things easy to understand. Consider...
[with this commit I] Patched feature XYZ to disallow access to unregistered users
[with this commit] Feature ABC is complete and ready for testing and staging
Planned commits as discussed, to me, speaks of a narrow view of Git and the underlying technology. Look into rebase+squash patterns as others mentioned. Also know how to stash as well as branch to increase workflow. And most important is local branch squashing for commit and review.
Professionally no team or job in my past would accept a "I'll commit again after I've finished this function" type commit in the stream.
A commit should be a "logical unit of work" (in master) such as a complete feature, fixed bug, RFC commit, etc. However you want to handle that privately and locally feel free, but that type of commit is not welcome in a large project.
Here is why, if you commit at the wrong checkpoints, don't squash and merge in, all that noise to a Sr Dev/CTO (like me) will provide a fragmented diff to perform a code review. Among other long term problems and bad habits for the team
I follow similar patterns as listed but on what I call a "local scratch" branch. I commit often and never (ever) push without reason. Instead I squash down to a new branch (learn rebase) and commit. The single larger commit, in the scope of a large project, is much easier to work with inside a team even if big.
So your thinking is valid, but how and where it applies is important.
The same flow can be accomplished using stashes. Additionally I suggest a GUI for GIT, there are various studies that empirically show that GUI based GIT and visual doff tools improve quality and cut review time. Or put another way, the command line is critical to know, but you will never, ever, read your diff as well in terminal unless you are deranged.
If you don't know what/when to commit presents 2 serious flags professionally. First for the team in not having a git protocol or understanding communicated, aka pending massive fail. Second flag on the person for not grasping fundamental tools. Sorry to be a hard ass, but I am the guy who un-fucks GIT in every company and I would not hesitate to review company GIT protocol. Commit as if there are 1000 people working on the project. The thinking presented here can be dangerous if not used correctly. The range of comments in this thread spans the entire scope of GIT, from "look what I know" to "I have a job, team, and deadlines and don't have time for rookie shit in my master".
If anyone wants to talk serious GIT strategy hit me up, love to talk GIT, so much to learn and share!
I think I was talking about my strategy on what you're calling the "local scratch branch" in this article. I hadn't really considered the larger scale beyond personal projects, but mucking up somebody's Git Repo is one of my huge fears. You've provided a ton of great methodology and mindset tips that really help. I'm definitely getting a GUI and rebasing/squashing my commits before pull request from now on.
Thanks!
Cool, it was hard to not come off as angry programmer. I tried to sell these skills to General Assembly (NYC) re:GIT course and they wanted no part of anything helpful for actual career. I use Tower for GIT, been on it for 8 years, still have command line chops (saved to when shit goes really bad). Ping me on TwitterZ to talk more. I had the same fears on GIT way back and developing a local strategy to look like I know wtf I am doing was key.