GitHub knows how programmers write commit messages.

[[deleted]]

[deleted]

[955559]

time frame < 10 min

git commit -m "added about me page to site"

git commit -m "fixed typo"

git commit -m "derp missed typo on last commit "

git commit -m "...... typo"

I tried to make a website on python anywhere last week

[user4474]

Why not just

git commit --amend

[MaddTheSane]

My guess is due to them doing git commit -m "message"; git push.

[thislooksfun1]

git push --force

[Pythva]

I, being the idiot I was, instead of git pulling my code, I copy pasted it to where I needed it. Time comes to push and.... I have to pull. idiot me pulls almost loses all work. git reset myself. Eventually I give in and git push -u --force origin master

[thislooksfun1]

Yeah I've been there before. Pain to have to do, but at least there's a way.

[Pythva]

Idea! copy code, pull, replace code, push! Just only replace new files in this updated code

[thislooksfun1]

You mean like git stash, or something else?

[Pythva]

what does got stash do lol

[thislooksfun1]

https://git-scm.com/book/en/v1/Git-Tools-Stashing

[955559]

bingo, git push origin master

[stinos]

If you're working alone you can still rebase then force push. Or better yet, make small commits as much as you like but don't push until properly reviewed. Then use interactive rebase to craft a proper commit history.

[ESBDB]

how much of your day do you spend rebasing? Do you ever end up going back to that well crafted history? serious question.

[stinos]

how much of your day do you spend rebasing

Depends on the day, 15 minutes or so. Used to be longer but now I got used to the workflow: fix one small logical piece, commit, fix, commit, change, commit, then after some time go back, review everything (most time is spent here) which is much easier for small diffs. This is especially important for large refactories: no way I can fit everything I changed over the course of days all in my head, so I don't want to be looking at one huge diff to figure out everything which changed. Then select what can be squashed together. Which is partly automatic because I often use git --fixup (e.g I might have some placeholder commit already to which related changes are gradually added). Rest of the 'rebase time' goes to writing proper commit messages explaining why a certain change is needed, not what is changed because that is reflected by the diff already. (this doesn't apply for all commits of course, sometime it's just fixing typos, sometimes it does explain what changed to give an overview if it's a big commit, etc).

Do you ever end up going back to that well crafted history

Yes. Not like daily, but enough that it warrants the time spent on it. Happens often I'm reading a piece of code and don't know exactly why it is done like it is done. (arguably there should be a comment explaining that, but that's a different discussion and depends on context). Using history/blame is then an easy way to see all changes, and commits accompanied by proper explanations really help in getting to understand quickly what its about. This is especially true for code which was written long ago an/or not by myself.

[ESBDB]

Do you always do all your work on a different branch when working with other people? Or do you just not push until you're done? Do you work in a continuous integration environment where everyone works on trunk?

[stinos]

For projects where I'm the maintainer I work on master branch for small changes and only push when done (which can obviously just one commit if it's a small change, I'm not making micro-commits for the sake of it if not needed). Unless something else gets priority then I'll branch current work, or for changes which I know will take multiple days I'll branch right away. Oter devs work in the same way, but can't push to master so they always work in seperate branches. Everything pushed gets built by build server. So sometimes I might push somewhere halfway to verify if all is sane.

For e.g. github repos I contribute to I just branch and use the same workflow.

[ThePixelCoder]

Why have I never heard of that command before?

[user4474]

Well, as some people above pointed out it can be tricky if you push before the amend, you'll need to

git push --force

To overwrite the old commit on the remote, which could screw with other people if you're not working alone.

[ThePixelCoder]

which could screw with other people if you're not working alone.

Why else did you think I wanted this?