4 ms·
There is a very simple workflow that uses a small subset of git commands -- I try to never stray from that. When I do, there is stackoverflow, ohshitgit.com, an
by waynecochran 3y ago
There is a very simple workflow that uses a small subset of git commands -- I try to never stray from that. When I do, there is stackoverflow, ohshitgit.com, and I also know an expert who can help me untangle things if I am really unsure.
- dboreham 3y agoAlso I've always found that cp working-tree broken-tree, then git clone <new-tree> then <manually fix up files I was working on> almost always beats trying to detailed the 10 suggested SO solutions.
- Galanwe 3y agoThat's basically what I did the first year working with git. Then I met a coworker that told me to stop doing this and come with him on a whiteboard to understand and solve the problem. That was painful the first month, but after some months of that treatment I had a strong mental model of exactly what happened, and how to fix it. I think overall the mental model is to 1) get knowledgeable enough to be able to actually draw the current graph of commits, branches and inheritance 2) clearly lay down the desired structure of the target graph 3) perform the steps necessary to transform the graph from 1) to 2).
- mbork_pl 3y agoAlso, Git has this weird feature called "workdirs" which may help with that, too.
- coryrc 3y agohttp://learngitbranching.js.org http://learngitbranching.js.org A couple hours and you'll never need to do that again. I promise!
- samus 3y agoI've always found that a good Git user interface goes a long way to understand what is really going on. The commit graph and the conflict resolution UIs are most important. The right choice is very personal - I've found understanding the contents of a repo purely on the terminal to be torture, even though I issue most commands from there.