Doesn't look right if an article starts by introducing git reset and git reset --hard.
What makes you say that? I use that command nearly every day.
More Productive Git
11–20 of 147 posts
Re: More Productive Git
#12There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
1 time out of 100 you get those cases where the four or five commands you have memorized are not enough. Those cases are hard.
Re: More Productive Git
#13Earlier quoted context omitted.
> Git isn't that hard. It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it. The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. The term `checkout` is multiplexed to do more things than I would've guessed.
I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).
Also helpful for committing changes in smaller atomic units
Re: More Productive Git
#14One of the most common issue I faced when I started learning git was diverging local and remote branches, franatically searching how to fix it and giving up 2 hours later.
Yes, that has been my experience as well. Starting a new repo that has a remote tracking branch has been a source of constant frustration for me. I routinely mess up some incantation and then have no idea how to fix it. The mental overload is high enough with local branches, but I still don't quite follow what it means to have a tracking branch, it seems to complicate the nice and simple mental picture I have of the local repo as a DAG.
Re: More Productive Git
#15One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you revert the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the other one, all your changes done in the other branch will be reverted. The takeaway: don't revert something if you don't actually want to revert that code. I am pretty bad with git, by I assume the correct way to reverse the initial merging would be to remove that merge commit entirely, using git reset.
Re: More Productive Git
#16Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell.
Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell.
The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list for what is essentially a graph.
Re: More Productive Git
#17One of the most common issue I faced when I started learning git was diverging local and remote branches, franatically searching how to fix it and giving up 2 hours later.
But that's the goal of git -rebasing, merging- conflicts are pointed out to you so that you have to fix them. Fixing conflicts isn't a passive task, it can actually involve writing/modifying code, and by pointing out conflicts git makes it easier.
Re: More Productive Git
#18More productive Git is faster & easier with good git aliases. These help novices and experts alike.
I maintain a large free list of Git aliases, and community feedback is always welcome.
Re: More Productive Git
#19One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you revert the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the o…
I think both answers are correct, and the best thing is to understand where each approach will bite you.
I prefer to remove the commit because I am proponent of rebasing over merging. Though the issue is that removing merged can be tricky, because you have the merge commit as well as all the commits associated with the merge. It’s easier for me to manage by avoiding merges entirely, and just restructuring git history via rebases often.
Re: More Productive Git
#20There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
Because a lot of people have a terrible workflow. Then they spend 1 hour on StackOverflow searching a magic solution to fix their mess.
And there are also those people who inflict themselves unnecessary strict rules for whatever reason. Like those who refuse to rebase and push -f on their own branches. Or those who refuse to use a GUI but keep messing up when diffing, resolving conflicts and staging specific files/lines.