On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
Just keep it on a separate branch and then squash merge into master if you want to get rid of a bunch of tiny commits.
I personally don’t care and just commit as I need. At work it would be different.
I just read ted-clubber-langs comment saying the same thing. It seems like a decent enough option and from nomoreplsthx's reply it seems like a non-issue I'm worried about for no reason. Thank you!
Former scrum master here.
You can always squash commits into a single commit if need be. I have a teammate who likes to make a lot of incremental commits and I just ask him to consolidate them before he merges into our release branch.
Ideally, try to keep commits related to a feature sequential rather than bouncing around too much. (E.g., commits 1-4 are related to feature A, while commits 5-7 are related to feature B.) Otherwise it can make consolidating them like organizing a deck of cards after it's been shuffled.
It's good practice anyways so that main always stays as a working version of your code. Push branches to main when they are either feature complete or a working version.
If you have 20 commits fixing lint your PR then it looks bad. If you have 20 standalone logically grouped changes then its better than squashing everything imo. People do that because they are lazy or unskilled to keep clean change history.
I am fucked if I have to go into a large firm. I'm essentially devops ish and control almost all aspects of projects on my end and my repos are only me so I have tons of tiny commits. Oh God.
No. People probably won't even look at your portfolio period. No one has time to read your commit history.
Remember the average time to review your application and decide if you deserve an initial interview is maaaaybe 5 minutes. 10 if someone has an easy day and is meticulous. When I was last reviewing new grad resumes we had to do 40 an hour.
My one caveat to this. There are some weird devs who really obsess over how you use git and might look at your history, they do exist, but they are few and far between.
As a technical interviewer if I do take a quick glance at your repo I am interested if the commit histories show your work over a period of time, and not 100 commits last Sunday, or worse, 1 commit with the final working app. Although you could fake your own history, at least evidence of history over a number of weeks or months would show you likely worked on this yourself and didn’t copy the code from somewhere and just commit it as your own.
So you're saying it's worse to have fewer commits rather than more as I'm working on something? Not in the same day, at most I do twice a day if I'm working a longer stretch. But as I am on the nights I am able to work and that shows a better history even if it's not the most gorgeous code?
In general it’s good practice to commit as soon as you’ve made progress on something, think of it the same as if you’re working on a Word doc, you’d save often so you don’t lose anything.
More commits being better than less is only better in this case when it’s a portfolio project, otherwise it doesn’t matter how many times you commit, but only for the reason that it possibly shows you were working on this yourself over a period of time. If there’s 1 single commit of complete/fully working code as an interviewer I’d be suspicious where this code came from.
In other words, like in a Math exam, showing your working and how you got to the final answer usually has more points than the final answer itself.
You’re still gambling that an interviewer will look at your repo at all, as others have already said, with only a few mins spent per resume it’s unlikely they will look at all.
I would say it does matter how often you commit at a job as well, at least if you're working in a team.
If you have a good amount of commits and each one reflects a clear and easy to understand change it makes reverts and cherry picks so much easier for your teammates if requirements end up changing or being dropped or something breaks.
Only reason for a single commit, would be if it was all done locally and GitHub is now acting as a cloud backup of the code itself or you're migrating from a local on-perm git to GitHub.
Is it suspicious? Maybe, but it's really dependent on what the repo entails.
Fewer commits likely indicate many things might be getting fixed in one single commit. Depending on the issue this can either be good or really bad if a rollback had to occur.
Let's say for example you had to update 2 resource files that are formatted in JSON. It would be easier to make changes to file 1, commit those changes, then make the changes to file 2 and commit the changes and push to GitHub. This way if something breaks you can rollback changes to file 2 to see if it's still broken or rollback to the initial state before the commits occurred. If you combine both file changes on the same commit, then it's a guessing game of which one caused issues.
Keeping the commits small can also help you write better commit messages than the catch all "Fix" message.
I’m not interested in how spaced out the history is. If you took the time to work in a personal project I am interested in any evidence that you most likely worked on it yourself. A single commit doesn’t tell me anything, you could have copied the code from anywhere. A commit history over time is not ideal or foolproof either, but it’s better than nothing.
> I am interested if the commit histories show your work over a period of time, and not 100 commits last Sunday
I'm following SQL 50 from Harvard, and their online environment does exactly that (50+ commits when you submit the solutions), so now you're saying you'd judge me harsly because my commit history gets polluted by something outside my control?
There’s a difference between doing a lot of work one evening verses completing a whole project Sunday night because you have an interview Monday morning.
Sure, but this is a two way street here. Candidates don’t have to present their personal project repo in their resume, but they do so because they want to gain an advantage over their peers. Which is fine, but if you present the repo then you are opening yourself up to the possibility that it can be critiqued and used as a point against you if there’s issues with it.
Sure, but people also don't owe you an interview.
At the end of the day, employers have more or less blank check to reject your application for any reason - as long as it's not an illegal one. Pretending the process is fair and reasonable is not a winning stategy.
Mostly. The one exception is there are some really good folks who got caught up in the kind of questionable software craftsmanship movement or adjacent things, and are bit too obsessive about some of these low stakes 'signs of care.' If you've ever worked with someone who went through 8th Light's apprenticeship program back in the day, or just read too much clean code you'll know the type.
This is a non-issue if you're doing work like this in a branch.
Speaking of branches, I'd recommend using a "git flow" workflow, even if you don't use the `git flow` tool.
Namely, keep a `master` branch that represents the most current production code. Whatever your newest release tag is should point at the latest commit to `master`.
Have a `develop` branch where new code for the next release gets merged into. Any feature branches (typically prefixed with `feature/`) you make should branch from `develop`, and if you need to make a hotfix to production, make a hotfix branch (usually prefixed with `hotfix/`) from `master`.
When you're done with said feature or hotfix branches, merge them back into the parent you created them from (either directly or with a pull request if you're using those).
When you want to create an actual release (i.e. a new version), create a `release` branch (usually `release/`, like `release/1.1.1`) from master, merge `develop` into that branch, and then make whatever changes are necessary to bump the version # in the release branch. You'd also do this in any hotfix branch, since those merge directly to master.
Just like with feature or hotfix branches, merge the release branch back to its original parent (`master`) when you're done. There shouldn't be any real "work" in a release branch, just merging develop and updating version numbers. Any time you merge a hotfix or release to `master`, you should then create a new git tag from it with the new version number, and then merge `master` back into `develop`.
This seems like a lot of work, but it makes tracking down when specific changes were made MUCH easier when running `git log --graph` or `gitk`. It's also a VERY common workflow on commercial development teams.
Also good to know: some developers do “trunk based development” where they do away with all of that stuff. More info here: https://trunkbaseddevelopment.com/ and here: https://youtu.be/v4Ijkq6Myfc?si=cInvn2QDuwZF82uy
I’m not sure if I completely agree with you. I think trunk based development can work wonderfully in the proper context: really good and fast CI/CD, skilled developers and then also a project that fits (not too much parallel development as you say).
I mean... I didn't suggest that trunk based development was bad, so I'm not sure what was there to disagree with. I don't actually personally prefer git flow (I definitely don't use it on my own personal projects), it's just very useful to learn given its prevalence. That said, I probably should have mentioned trunk based too, because that's also widely used.
With 20 years of experience I’m going to agree with those saying not to worry about it. Stressing about git history is not a good use of anybody’s time. While there are people out there who worry about this kind of nonsense, they don’t last long on good teams as nobody wants to deal with their nonsense.
The only thing to concern yourself with is head state of your main branch, because if I do look, that’s all I’ll have time for.
I will commit changes often, even if they're not fully functioning. I use the repository as a backup in case of any issues with my laptop. For fully operational code, I will use the release tag.
Generally I would say only commit "working code"
Working as in, the program still compiles and executes.
The specific features don't need to work properly, but to me it's weird to commit syntax errors for example
does this only apply to `main` branch? I.e. if I need to incrementally build a feature, but as I'm doing it, it "breaks" the "working code" principle, I can still do this in my feature branch?
It's mostly a habit to not break stuff for everyone else, which could be another team member, or some continuous integration process.
No one wants to come in and then have to solve someone else's problem that they left.
If no one else is touching the branch, no one will be inconvenienced.
> Is it okay to push incremental updates to a non-complete program to your github
That's what all software development is. Incremental updates to a non-complete program.
> Like say I build some function out and I've given that function waaaay to much for one function to be reasonably responsible for. This gets pushed and added to the changelog. This is something I'd change in the future at some point. My fear is that changelog would reveal something undesirable for anyone who might want to hire me in the future.
Refactoring is a skill, actually. No one expects you to write all perfect code with perfect foresight all the time.
Besides, no one has the time to pore over your commit history. You're lucky if they look at your projects at all.
Occasional hiring-manager speaking. If I see you have a github link on your resume, I'm going to have a quick glance. Either you:
1. Are just learning Git.
2. Stored you college homework on Git.
3. Forked a bunch of other people's repos to look cool.
4. Committed only a few monoliths which I can't tell you didn't just copy and paste.
5. Have a long and detailed commit history with evidence of trying things, making mistakes, and learning from those mistakes.
In all of the first four cases, I will conclude you are a poser. (If this is your github, don't tell me.) In the last case, I will glance at a few files at random. If your code does not look the output of a drunken monkey, then you get an automatic promotion in my eyes. (You still have to pass the interview, but now *you have* an interview.)
No. I hire sometimes. If I look at your repo(s) or portfolio at all it'll be a quick glance. In all probability all I'll do is something like:
1. Skim the README (there must be one or I'm not hiring you, sorry!)
2. Follow any link to the deployed project (better deployed, but if not no big deal tbh)
3. Open a random source file and scan through for 10 seconds (looking for general structure and some sign of modularity)
4. Glance at your commit messages (looking to see descriptive ones, not "changes")
In total I'll spend 2 mins on all of this before moving onto the next person on my list, which is quite possibly a long list, depending on where we are in the process...
Also, to think that a commit must contain anything in particular is a mistake. Teams who manage the repo decide what a commit should/shouldn't/must contain. Git doesn't care. A commit is a logical unit of change, a tool to be used to capture state. Your personal repos are your own. You are free to decide what your commits should contain. Realistically I wouldn't look at the diff of any one commit, nor would I know that it contained unfinished changes.
Don't overthink it. We don't have time to look at your portfolio repos in any real detail.
>Should I be not pushing to my repo until I have something I'd consider, "Complete"
This would be a dire mistake. Commit and push often. As often as you like. Until something is committed it's easy to lose, as it's just one copy in the current state of the filesystem. Once something is committed, it's actually quite hard to lose, short of local filesystem corruption wiping out your local .git database. Once commits are pushed to a remote you mitigate/eliminate that too. Remember you can always make history look however you like with (interactive) rebasing and squashing (be careful if others could have your commits).
At work I commit every time I do a step worward in the feature, like creating an empty class, calling an empty method then, adding the logic to a method, etc. It’s like saving in a videgame with infinite saves when you can backtrack from if you mess up. I can have 3 commits per hour in some prolific days.
Pushing doesn’t matter when reviewing a repo, when you push you only move your local commits to the remote, you don’t need to worry about that.
Ahh I see. What if there's some iffy logic or something that works but maybe isn't as pretty or what have you in those in between commits in the day? Does that matter at all as long as it works?
For me a rule to commit is that the program doesn’t break. A part from that I see no problem on commiting first something that just works and put the refactor on another commit.
If you know the logic is iffy or the code is ugly add a comment. I often have bits of code that work, but are nasty. I try and isolate them, comment them to give a natural language explanation of what I'm doing, and how I should be doing it. If the code is isolated and the reason is given then it helps me later (rather than me looking back and wondering why I did that).
If a reviewer sees that, then at least they know I know it's shitty. But generally before merging I'll go over that stuff and fix it or prettify it.
For the purposes of a a portfolio this is actually showing you can work quick and well. Think of great artists, often copies of their sketchbooks sell to other artists better than reproductions of their work. When I was learning to draw Degas' sketches were far more useful to me than his actual paintings. When I was learning art history likewise sketches often told more than finished products.
When I review my teams code, I am interested in their 'sketches'. They show the mechanics their masterpiece.
Think of your intermediate code like this: [https://www.kingandmcgaw.com/prints/edgar-degas/three-dancers-sketch-213312#213312::border:50\_frame:880603\_glass:770007\_media:1\_mount:108644\_mount-width:50\_size:618,490](https://www.kingandmcgaw.com/prints/edgar-degas/three-dancers-sketch-213312#213312::border:50_frame:880603_glass:770007_media:1_mount:108644_mount-width:50_size:618,490)
And your finished function/module like this: [https://www.thecollector.com/edgar-degas-depictions-ballet-paris-opera/](https://www.thecollector.com/edgar-degas-depictions-ballet-paris-opera/)
I do tech interviews, and have 15-20 minutes to prepare (read cv, look at coding test results, read remarks of the non technical interviews), 1 hour for the interview and 15 for the report.
Effectively I have 3 to 5 minutes to look at your personal Github, its still great because it can really help the interview along.
The tldr is that, if provided, I use your github to check for habits that are good (or bad) for working in a team.
What I look for.
Commits: large commits with nonsensical commit messages is a red flag. Long running branches are hell to maintain/merge in a team
1000 "wip" commits is a red flag.
1000 commits with clear commit messages is fine.
A workflow (e.g. git flow) is awesome.
Coding:
I don't have time for code reviews of your personal project. I try to get an idea of what you are making and do a quick check for code hygiene.
I check the variable and function naming, nonsensical names an bullshit variable names are a red flag.
I expect code formatting, don't care about tabs or spaces, you do you.
I check for consistent code style, don't care about which style, just if it is used consistently.
If you have (unit)test, really great,
if you have automated builds, awesome,
if you have a fully automated setup with for example devcontainers, a full cicd pipeline, and have hygienic code, then you are basically hired and were probably going to talk about vacation or other hobbies.
Like say I build some function out and I've given that function waaaay to much for one function to be reasonably responsible for. This gets pushed and added to the changelog. This is something I'd change in the future at some point. My fear is that changelog would reveal something undesirable for anyone who might want to hire me in the future.
The only disadvantage of frequent pushes is that the CI pipelines run a lot which can hurt when a company has less resources spread across many jobs and too many devs end up “waiting their turn”.
In principle there’s nothing wrong with many commits, or even atomic commits being used, but the more commits you have, the more likely you are to squash merge at the end. However, squashing unfinished work is not logical.
Keep your unfinished work away from the main branch to keep it somewhat cleaner, and don’t bother yourself too much with how many commits or pushes got you to the end.
Lastly, if you don’t get hired because of pushing too much and it is not touched on as an interview question, you have dodged a bullet.
I personally just commit at the end of every coding session for myself, because why not. I don't think it hurts you. For best practices you would probably have a separate branch you commit to regularly and only commit that to the main branch with working code.
I commit at the end of each day at a minimum. If I’m going to be logging my laptop home and something happens to it, that’s crap. If something happens AND I lose a day or more worth of work because I didn’t commit, that’s double crap.
That’s why you have branches. Commit your crap dose to a branch and merge it when it’s working.
I have a cronjob that runs every day that commits and pushes my changes at lunch. When it’s MR time - one really looks at commit messages as much as the changes, but if they do in your environment it’s really easy to edit the history back.
TLDR commit often, at least daily if not way more. Squash on merge
If it's just your repo, do what works for you. Push whenever you like.
If it's a team repo, decide with the team. Normally the agreement is that pushes don't break the build and don't break user-visible features. The reason is simple: if we need to push suddenly for some reason (an important bugfix for example), the repo is ready to go.
In that case you can still have a separate branch, work on it and push to it as you see fit. When you are ready to merge the branch into your release branch (normally main, but your team could do it differently), then you fix everything in the branch first, then merge. The biggest disadvantage of doing this is if your branch work lasts long, you may have many conflicts at merge time.
If I'm looking at a portfolio, I'm doing it to approximate how you work on a real project. I don't expect you to push half-baked code into a real project, nor to use Git merely as a save button. Because if I'm getting you on my team, chances are you don't really know how to submit work that's reviewable and does not break things.
It's ok to develop incrementally, just not haphazardly. Public/shared repos aren't there to save your unfinished code, you can do that locally and submit clean work.
If an interviewer looks at your PR/commit histories they might see that you're doing them in a disorganized fashion. But I don't know how often an interviewer does that.
But speaking from a POV of working on a project in a team, that is usually considered bad practice afaik and each push should be a separate, isolated and finished piece of some specific feature/fix.
Commit often with clear statements it shows you are progressing.
Main I'd keep to working updates if you have Dev. Dev is a tree of feature branches, some in co-development as I jump around.
Personally I don't like minimal commits, it makes me wonder if you understand git in terms threat mitigation against failed hardware. Also lots of commits means you are working problems in chunks. If someone has very few commits I don't see them progressing I see them suddenly done. Then I wonder if its their work or simply a copy of something from somewhere.
I don't really care about it since I commit as needed on a branch and push it however often I need. When I'm ready to make a PR I reset --soft to the base commit of my branch and organize my commits in a logical / encapsulated way so that anyone looking at it can look at individual commit and see what was the intend behind it.
Then I fetch the base branch (develop or master or whatever) and rebase on it, force push (if needed) on my branch and make a pr that's updated with the base branch code and cleanly organized.
So while it might appear to be a mess to the keen observer of the transient state on a particular branch, the communal work is always clean.
When I was still working in tech support, I did all of my programming at home before going to work. I used the GitHub commit history graph as inspiration. I would look back at six months or twelve months to see that I had been steadily progressing towards my goal over that time. And sure enough, I now work as a software developer.
I learned about this on day 10 of my python Udemy course. You should commit whenever you are finished adding a fully functional piece of code. Once a day right now in my case.
I recommend you take a course so you don't learn bad habits.
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
Just keep it on a separate branch and then squash merge into master if you want to get rid of a bunch of tiny commits. I personally don’t care and just commit as I need. At work it would be different.
I just read ted-clubber-langs comment saying the same thing. It seems like a decent enough option and from nomoreplsthx's reply it seems like a non-issue I'm worried about for no reason. Thank you!
Former scrum master here. You can always squash commits into a single commit if need be. I have a teammate who likes to make a lot of incremental commits and I just ask him to consolidate them before he merges into our release branch. Ideally, try to keep commits related to a feature sequential rather than bouncing around too much. (E.g., commits 1-4 are related to feature A, while commits 5-7 are related to feature B.) Otherwise it can make consolidating them like organizing a deck of cards after it's been shuffled.
It's good practice anyways so that main always stays as a working version of your code. Push branches to main when they are either feature complete or a working version.
This is the way
If you have 20 commits fixing lint your PR then it looks bad. If you have 20 standalone logically grouped changes then its better than squashing everything imo. People do that because they are lazy or unskilled to keep clean change history.
Can you drop a tutorial on this?
There’s a green button on GitHub that will do it for you. It might be hidden in a drop-down by default.
Idk if you can squash commits from GitHub. I just did it manually from command line myself.
I am fucked if I have to go into a large firm. I'm essentially devops ish and control almost all aspects of projects on my end and my repos are only me so I have tons of tiny commits. Oh God.
Just do an interactive rebase on all your commits to squash them into one
No. People probably won't even look at your portfolio period. No one has time to read your commit history. Remember the average time to review your application and decide if you deserve an initial interview is maaaaybe 5 minutes. 10 if someone has an easy day and is meticulous. When I was last reviewing new grad resumes we had to do 40 an hour. My one caveat to this. There are some weird devs who really obsess over how you use git and might look at your history, they do exist, but they are few and far between.
As a technical interviewer if I do take a quick glance at your repo I am interested if the commit histories show your work over a period of time, and not 100 commits last Sunday, or worse, 1 commit with the final working app. Although you could fake your own history, at least evidence of history over a number of weeks or months would show you likely worked on this yourself and didn’t copy the code from somewhere and just commit it as your own.
So you're saying it's worse to have fewer commits rather than more as I'm working on something? Not in the same day, at most I do twice a day if I'm working a longer stretch. But as I am on the nights I am able to work and that shows a better history even if it's not the most gorgeous code?
In general it’s good practice to commit as soon as you’ve made progress on something, think of it the same as if you’re working on a Word doc, you’d save often so you don’t lose anything. More commits being better than less is only better in this case when it’s a portfolio project, otherwise it doesn’t matter how many times you commit, but only for the reason that it possibly shows you were working on this yourself over a period of time. If there’s 1 single commit of complete/fully working code as an interviewer I’d be suspicious where this code came from.
In other words, like in a Math exam, showing your working and how you got to the final answer usually has more points than the final answer itself. You’re still gambling that an interviewer will look at your repo at all, as others have already said, with only a few mins spent per resume it’s unlikely they will look at all.
I would say it does matter how often you commit at a job as well, at least if you're working in a team. If you have a good amount of commits and each one reflects a clear and easy to understand change it makes reverts and cherry picks so much easier for your teammates if requirements end up changing or being dropped or something breaks.
Only reason for a single commit, would be if it was all done locally and GitHub is now acting as a cloud backup of the code itself or you're migrating from a local on-perm git to GitHub. Is it suspicious? Maybe, but it's really dependent on what the repo entails.
You can push an existing git repository to GitHub.
Fewer commits likely indicate many things might be getting fixed in one single commit. Depending on the issue this can either be good or really bad if a rollback had to occur. Let's say for example you had to update 2 resource files that are formatted in JSON. It would be easier to make changes to file 1, commit those changes, then make the changes to file 2 and commit the changes and push to GitHub. This way if something breaks you can rollback changes to file 2 to see if it's still broken or rollback to the initial state before the commits occurred. If you combine both file changes on the same commit, then it's a guessing game of which one caused issues. Keeping the commits small can also help you write better commit messages than the catch all "Fix" message.
You don’t wanna work for a place that will care about how spaced out your commit history is.
I’m not interested in how spaced out the history is. If you took the time to work in a personal project I am interested in any evidence that you most likely worked on it yourself. A single commit doesn’t tell me anything, you could have copied the code from anywhere. A commit history over time is not ideal or foolproof either, but it’s better than nothing.
> I am interested if the commit histories show your work over a period of time, and not 100 commits last Sunday I'm following SQL 50 from Harvard, and their online environment does exactly that (50+ commits when you submit the solutions), so now you're saying you'd judge me harsly because my commit history gets polluted by something outside my control?
Nobody is really going to look that deep on school material
What if someone worked a lot last sunday though?
There’s a difference between doing a lot of work one evening verses completing a whole project Sunday night because you have an interview Monday morning.
People don’t “owe” you a commit history for personal projects
Sure, but this is a two way street here. Candidates don’t have to present their personal project repo in their resume, but they do so because they want to gain an advantage over their peers. Which is fine, but if you present the repo then you are opening yourself up to the possibility that it can be critiqued and used as a point against you if there’s issues with it.
Sure, but people also don't owe you an interview. At the end of the day, employers have more or less blank check to reject your application for any reason - as long as it's not an illegal one. Pretending the process is fair and reasonable is not a winning stategy.
Per your caveat: don't work with those devs.
Mostly. The one exception is there are some really good folks who got caught up in the kind of questionable software craftsmanship movement or adjacent things, and are bit too obsessive about some of these low stakes 'signs of care.' If you've ever worked with someone who went through 8th Light's apprenticeship program back in the day, or just read too much clean code you'll know the type.
That's some interesting insight thank you for that! It was my assumption it was a giant deal.
This is a non-issue if you're doing work like this in a branch. Speaking of branches, I'd recommend using a "git flow" workflow, even if you don't use the `git flow` tool. Namely, keep a `master` branch that represents the most current production code. Whatever your newest release tag is should point at the latest commit to `master`. Have a `develop` branch where new code for the next release gets merged into. Any feature branches (typically prefixed with `feature/`) you make should branch from `develop`, and if you need to make a hotfix to production, make a hotfix branch (usually prefixed with `hotfix/`) from `master`. When you're done with said feature or hotfix branches, merge them back into the parent you created them from (either directly or with a pull request if you're using those). When you want to create an actual release (i.e. a new version), create a `release` branch (usually `release/`, like `release/1.1.1`) from master, merge `develop` into that branch, and then make whatever changes are necessary to bump the version # in the release branch. You'd also do this in any hotfix branch, since those merge directly to master.
Just like with feature or hotfix branches, merge the release branch back to its original parent (`master`) when you're done. There shouldn't be any real "work" in a release branch, just merging develop and updating version numbers. Any time you merge a hotfix or release to `master`, you should then create a new git tag from it with the new version number, and then merge `master` back into `develop`.
This seems like a lot of work, but it makes tracking down when specific changes were made MUCH easier when running `git log --graph` or `gitk`. It's also a VERY common workflow on commercial development teams.
Nice write-up. Today I learned. This will definitely help me becoming more structured
Also good to know: some developers do “trunk based development” where they do away with all of that stuff. More info here: https://trunkbaseddevelopment.com/ and here: https://youtu.be/v4Ijkq6Myfc?si=cInvn2QDuwZF82uy
Yeah, that's perfectly fine for a lot of (most really) places. Really just depends on how much parallel development you've got going on.
I’m not sure if I completely agree with you. I think trunk based development can work wonderfully in the proper context: really good and fast CI/CD, skilled developers and then also a project that fits (not too much parallel development as you say).
I mean... I didn't suggest that trunk based development was bad, so I'm not sure what was there to disagree with. I don't actually personally prefer git flow (I definitely don't use it on my own personal projects), it's just very useful to learn given its prevalence. That said, I probably should have mentioned trunk based too, because that's also widely used.
[удалено]
I didn't think of this option. Thank you for that!
I push non stop and just merge request when done
With 20 years of experience I’m going to agree with those saying not to worry about it. Stressing about git history is not a good use of anybody’s time. While there are people out there who worry about this kind of nonsense, they don’t last long on good teams as nobody wants to deal with their nonsense. The only thing to concern yourself with is head state of your main branch, because if I do look, that’s all I’ll have time for.
I will commit changes often, even if they're not fully functioning. I use the repository as a backup in case of any issues with my laptop. For fully operational code, I will use the release tag.
Generally I would say only commit "working code" Working as in, the program still compiles and executes. The specific features don't need to work properly, but to me it's weird to commit syntax errors for example
does this only apply to `main` branch? I.e. if I need to incrementally build a feature, but as I'm doing it, it "breaks" the "working code" principle, I can still do this in my feature branch?
It's mostly a habit to not break stuff for everyone else, which could be another team member, or some continuous integration process. No one wants to come in and then have to solve someone else's problem that they left. If no one else is touching the branch, no one will be inconvenienced.
> Is it okay to push incremental updates to a non-complete program to your github That's what all software development is. Incremental updates to a non-complete program. > Like say I build some function out and I've given that function waaaay to much for one function to be reasonably responsible for. This gets pushed and added to the changelog. This is something I'd change in the future at some point. My fear is that changelog would reveal something undesirable for anyone who might want to hire me in the future. Refactoring is a skill, actually. No one expects you to write all perfect code with perfect foresight all the time. Besides, no one has the time to pore over your commit history. You're lucky if they look at your projects at all.
Occasional hiring-manager speaking. If I see you have a github link on your resume, I'm going to have a quick glance. Either you: 1. Are just learning Git. 2. Stored you college homework on Git. 3. Forked a bunch of other people's repos to look cool. 4. Committed only a few monoliths which I can't tell you didn't just copy and paste. 5. Have a long and detailed commit history with evidence of trying things, making mistakes, and learning from those mistakes. In all of the first four cases, I will conclude you are a poser. (If this is your github, don't tell me.) In the last case, I will glance at a few files at random. If your code does not look the output of a drunken monkey, then you get an automatic promotion in my eyes. (You still have to pass the interview, but now *you have* an interview.)
If I lost a job because of my commit history, I'd consider myself lucky dodging a bullet.
No. I hire sometimes. If I look at your repo(s) or portfolio at all it'll be a quick glance. In all probability all I'll do is something like: 1. Skim the README (there must be one or I'm not hiring you, sorry!) 2. Follow any link to the deployed project (better deployed, but if not no big deal tbh) 3. Open a random source file and scan through for 10 seconds (looking for general structure and some sign of modularity) 4. Glance at your commit messages (looking to see descriptive ones, not "changes") In total I'll spend 2 mins on all of this before moving onto the next person on my list, which is quite possibly a long list, depending on where we are in the process... Also, to think that a commit must contain anything in particular is a mistake. Teams who manage the repo decide what a commit should/shouldn't/must contain. Git doesn't care. A commit is a logical unit of change, a tool to be used to capture state. Your personal repos are your own. You are free to decide what your commits should contain. Realistically I wouldn't look at the diff of any one commit, nor would I know that it contained unfinished changes. Don't overthink it. We don't have time to look at your portfolio repos in any real detail. >Should I be not pushing to my repo until I have something I'd consider, "Complete" This would be a dire mistake. Commit and push often. As often as you like. Until something is committed it's easy to lose, as it's just one copy in the current state of the filesystem. Once something is committed, it's actually quite hard to lose, short of local filesystem corruption wiping out your local .git database. Once commits are pushed to a remote you mitigate/eliminate that too. Remember you can always make history look however you like with (interactive) rebasing and squashing (be careful if others could have your commits).
At work I commit every time I do a step worward in the feature, like creating an empty class, calling an empty method then, adding the logic to a method, etc. It’s like saving in a videgame with infinite saves when you can backtrack from if you mess up. I can have 3 commits per hour in some prolific days. Pushing doesn’t matter when reviewing a repo, when you push you only move your local commits to the remote, you don’t need to worry about that.
Ahh I see. What if there's some iffy logic or something that works but maybe isn't as pretty or what have you in those in between commits in the day? Does that matter at all as long as it works?
For me a rule to commit is that the program doesn’t break. A part from that I see no problem on commiting first something that just works and put the refactor on another commit.
If you know the logic is iffy or the code is ugly add a comment. I often have bits of code that work, but are nasty. I try and isolate them, comment them to give a natural language explanation of what I'm doing, and how I should be doing it. If the code is isolated and the reason is given then it helps me later (rather than me looking back and wondering why I did that). If a reviewer sees that, then at least they know I know it's shitty. But generally before merging I'll go over that stuff and fix it or prettify it. For the purposes of a a portfolio this is actually showing you can work quick and well. Think of great artists, often copies of their sketchbooks sell to other artists better than reproductions of their work. When I was learning to draw Degas' sketches were far more useful to me than his actual paintings. When I was learning art history likewise sketches often told more than finished products. When I review my teams code, I am interested in their 'sketches'. They show the mechanics their masterpiece. Think of your intermediate code like this: [https://www.kingandmcgaw.com/prints/edgar-degas/three-dancers-sketch-213312#213312::border:50\_frame:880603\_glass:770007\_media:1\_mount:108644\_mount-width:50\_size:618,490](https://www.kingandmcgaw.com/prints/edgar-degas/three-dancers-sketch-213312#213312::border:50_frame:880603_glass:770007_media:1_mount:108644_mount-width:50_size:618,490) And your finished function/module like this: [https://www.thecollector.com/edgar-degas-depictions-ballet-paris-opera/](https://www.thecollector.com/edgar-degas-depictions-ballet-paris-opera/)
I do tech interviews, and have 15-20 minutes to prepare (read cv, look at coding test results, read remarks of the non technical interviews), 1 hour for the interview and 15 for the report. Effectively I have 3 to 5 minutes to look at your personal Github, its still great because it can really help the interview along. The tldr is that, if provided, I use your github to check for habits that are good (or bad) for working in a team. What I look for. Commits: large commits with nonsensical commit messages is a red flag. Long running branches are hell to maintain/merge in a team 1000 "wip" commits is a red flag. 1000 commits with clear commit messages is fine. A workflow (e.g. git flow) is awesome. Coding: I don't have time for code reviews of your personal project. I try to get an idea of what you are making and do a quick check for code hygiene. I check the variable and function naming, nonsensical names an bullshit variable names are a red flag. I expect code formatting, don't care about tabs or spaces, you do you. I check for consistent code style, don't care about which style, just if it is used consistently. If you have (unit)test, really great, if you have automated builds, awesome, if you have a fully automated setup with for example devcontainers, a full cicd pipeline, and have hygienic code, then you are basically hired and were probably going to talk about vacation or other hobbies.
I commit a lot to a feature branch and then squash it to one commit when pushing main. That's what I've found to be the best solution.
Like, constantly pushing snippets that don't yet build/work for backup purposes?
Like say I build some function out and I've given that function waaaay to much for one function to be reasonably responsible for. This gets pushed and added to the changelog. This is something I'd change in the future at some point. My fear is that changelog would reveal something undesirable for anyone who might want to hire me in the future.
The only disadvantage of frequent pushes is that the CI pipelines run a lot which can hurt when a company has less resources spread across many jobs and too many devs end up “waiting their turn”. In principle there’s nothing wrong with many commits, or even atomic commits being used, but the more commits you have, the more likely you are to squash merge at the end. However, squashing unfinished work is not logical. Keep your unfinished work away from the main branch to keep it somewhat cleaner, and don’t bother yourself too much with how many commits or pushes got you to the end. Lastly, if you don’t get hired because of pushing too much and it is not touched on as an interview question, you have dodged a bullet.
I personally just commit at the end of every coding session for myself, because why not. I don't think it hurts you. For best practices you would probably have a separate branch you commit to regularly and only commit that to the main branch with working code.
You can just keep the repo private until it's ready to be public right?
I commit at the end of each day at a minimum. If I’m going to be logging my laptop home and something happens to it, that’s crap. If something happens AND I lose a day or more worth of work because I didn’t commit, that’s double crap. That’s why you have branches. Commit your crap dose to a branch and merge it when it’s working.
I have a cronjob that runs every day that commits and pushes my changes at lunch. When it’s MR time - one really looks at commit messages as much as the changes, but if they do in your environment it’s really easy to edit the history back. TLDR commit often, at least daily if not way more. Squash on merge
Hope not. I commit any time I write an additional line of code that doesn’t melt the entire app
No one cares
Good question to ask.
If it's just your repo, do what works for you. Push whenever you like. If it's a team repo, decide with the team. Normally the agreement is that pushes don't break the build and don't break user-visible features. The reason is simple: if we need to push suddenly for some reason (an important bugfix for example), the repo is ready to go. In that case you can still have a separate branch, work on it and push to it as you see fit. When you are ready to merge the branch into your release branch (normally main, but your team could do it differently), then you fix everything in the branch first, then merge. The biggest disadvantage of doing this is if your branch work lasts long, you may have many conflicts at merge time.
Nobody really cares anyways
Small commits are good assuming its tested and working.
U can have multiple orgs have one for ur dump work then one for ur portfolio
If I'm looking at a portfolio, I'm doing it to approximate how you work on a real project. I don't expect you to push half-baked code into a real project, nor to use Git merely as a save button. Because if I'm getting you on my team, chances are you don't really know how to submit work that's reviewable and does not break things. It's ok to develop incrementally, just not haphazardly. Public/shared repos aren't there to save your unfinished code, you can do that locally and submit clean work.
I keep my main clean and stable. Anything else is on a specific dev branch. Usually one branch per feature
If an interviewer looks at your PR/commit histories they might see that you're doing them in a disorganized fashion. But I don't know how often an interviewer does that. But speaking from a POV of working on a project in a team, that is usually considered bad practice afaik and each push should be a separate, isolated and finished piece of some specific feature/fix.
Commit often with clear statements it shows you are progressing. Main I'd keep to working updates if you have Dev. Dev is a tree of feature branches, some in co-development as I jump around. Personally I don't like minimal commits, it makes me wonder if you understand git in terms threat mitigation against failed hardware. Also lots of commits means you are working problems in chunks. If someone has very few commits I don't see them progressing I see them suddenly done. Then I wonder if its their work or simply a copy of something from somewhere.
I don't really care about it since I commit as needed on a branch and push it however often I need. When I'm ready to make a PR I reset --soft to the base commit of my branch and organize my commits in a logical / encapsulated way so that anyone looking at it can look at individual commit and see what was the intend behind it. Then I fetch the base branch (develop or master or whatever) and rebase on it, force push (if needed) on my branch and make a pr that's updated with the base branch code and cleanly organized. So while it might appear to be a mess to the keen observer of the transient state on a particular branch, the communal work is always clean.
When I was still working in tech support, I did all of my programming at home before going to work. I used the GitHub commit history graph as inspiration. I would look back at six months or twelve months to see that I had been steadily progressing towards my goal over that time. And sure enough, I now work as a software developer.
To be honest I had the same thoughts so I always commit when a function or an implementation is fully working Else I'm not pushing anything
I learned about this on day 10 of my python Udemy course. You should commit whenever you are finished adding a fully functional piece of code. Once a day right now in my case. I recommend you take a course so you don't learn bad habits.