TL;DR – With all changes committed and ready to start a new task: branch, commit as you desire, back to public branch, fetch + merge from origin, merge work branch, push your merge, repeat.
Great resource: mrchlblng::A practical git introduction (then search for “What’s a good commit?”)
I’ve seen more than my share of folks completely failing at using Git for a variety of reasons. In my opinion is that the biggest issue is that people use Git like it’s just another type of SVN and then insist that it’s just not worth it.
A friend gets around town on his dirt bike and one day you see them on a new 6-speed but they look totally upset. They tell you that the switch has been a disaster as the thing is fast but only after you pick up some speed which is a miracle to get to anyway; they regret ever switching. You ask if they’ve tried to start at a lower gear and they say no as they don’t feel comfortable messing with the gears because they don’t know how to use them. You tell them that you’re sure they will benefit from learning to use the gears if only they tried to take some time aside to learn. Instead they just grumble about how much they miss their dirt bike.
This is how I’ve seen Git treated in every company I’ve ever worked for I kid you not.
Here’s what I recommend:
- Create a new branch and switch to it (IE git checkout -b json_save_files)
- Work on the task making sure to commit to your hearts desire. Ideally, atomic commits that reflect the steps to get the job done. ADVANCED: You can make the commit logs look nicer for public display using the sub-steps below…
- Once you feel like you’re ready to merge back into the public branch, create a branch called whatever you like (as you’ll likely kill it later). Don’t switch to it, this is a safety branch to return to should all else fail. (IE git branch json_save_files_derp)
- Do a soft reset on your task branch to the commit where you branched off. If you didn’t update it you may still be able to specify it by name. (IE git reset –soft dev)
- Your work branch is now back where it started and all the changes necessary to complete the task are uncommitted.
- Incrementally commit back all the changes providing intelligent explanations as to why this is being committed and why the change was created.
- This method helps to eliminate situations where you may have doubled back or undid changes that were ineffective and/or later discarded. It also provides a neater commit log for the rest of your team to admire you for.
- Once done switch back over to the primary development branch (the one everyone shares) and fetch + merge (IE git fetch origin then git merge origin/dev). Pulling is safe enough but I prefer to be deliberate with my merging.
- Merge in your task’s branch (IE git merge json_save_files)
- Push to your repo.