"Miscellaneous changes"

Or, "Catching up after a really long time."

I'm not usually lazy that way, but it's happened a time or two.

ABC. Always be committing. If you don't remember why you did it then it's already too late. Take frequent notes on what you do and why. Leave code comments whenever applicable. Remember, taking notes and commenting code isn't just helping other people. It's also helping yourself.

That situation should ideally never arise in the first place. I strongly follow Atwood's recommenation of Commit Early, Commit Often.

if the code isn't checked into source control, it doesn't exist.

Most work stuff I do is on a branch named with a JIRA issue key (and all commits prefixed with the key as well), so I can go read the JIRA if the commit messages aren't enough context.

If the changes are uncommitted there's a good chance they'll at least be on branch abc-123 If there are commits the the log is likely to say something like ABC-123 Progress commit with rough implemention of the new turboencabulator.

But realistically if the team had made lots of progress and even I couldn't remember what the changes were, I'd probably hard reset and move on. Not all code is worth keeping, particularly not code written just before going on a break ;)

If you're concerned it may actually be important and you'll remember in time, stick the changes in a branch like 20180609-mystery-changes and store them in a fork. Git branches are cheap after all.

If you really really have to work out what it was; you're going to have to check the log to see if a previous commit message jogs your memory; and look at the diff and just straight-up figure it out from first principles.

I use IDE changelists which are named as [issue number] short description. This makes it easy to remember what the changes were for.

If I cannot remember what I did, I usually

1. $ git branch -l to see what I was working on
2. use a diff against the last commit in my local repo and work on / commit with a useful message
3. if I still dunno what I did $ git reset --hard && git pull
4. work on

If you cannot remember what you did, your changes are probably not important anyway. If your team has even made "huge progress" after "you have been away for a while" while not needing your commit, your contribution was probably not necessary either or already implemented by someone else.

Never commit stuff you do not understand. Never commit untested changes. Ideally, implement review and CI processes for pushes and pull-requests. Also try out a sane git branching strategy, using feature branches, so you at least know what you were working on. I really like gitflow , but depending on your situation, there are other good strategies as well.

When writing a commit message, I usually use a verb as the first word followed by the content, for example

$ git commit -am "implement .abc file format for asset loader"
$ git commit -am "fix #123"
$ git commit -am "add package.json"
$ git commit -am "remove foo as a dependency"

If your company uses only sort of project management or ticketing system, you could leverage that. I use the GitFlow branching strategy. So when I start working on a new feature, I'll make a feature branch which I name with a ticket number. Example: features/BRB-247. When the branch is named in this way, you can refer back to the associated ticket to remind yourself what you were working on.

2 things ...

1. you should never commit what you don't understand.
2. you write in the commit message what the changes are.

there are different philosophies ... I write in present tense

#ticketNr <summary headline>
 - does blabla
 - change blub
 - add moo

as an example

#1337 implements new menu endpoints
 - adds role model and references
 - adds new backend for menu customization
 - changes parts of the user model