Anyone else out there feel like Git is like Charlie Brown’s “stupid kite-eating tree” that just lies in wait at code deploy time to ruin you? I can never get it right. Either I’m doing some edits and realize I’m on the wrong branch or the master is inexplicably ahead of local (or vice versa) and even though I can see in the git log where things went wrong, it’s like crossing a freeway blindfolded and hoping my git fetch or reset or merge doesn’t blow everything to hell. WHYYYY IS THIS SO DAMN HARD?!

git gud

I used to have similar problems. I installed a macro on my shell to show me the branch I'm in for the current working directory I'm on.

So it would look something like this:

$sariel (~/workspace/project) [master] >

Might help you if you're using a bash term.

Git requires some level of control and discipline from your end to work.

It's a tool that like many others tools, where it is easy to get wrong, easy to destroy you code base with, but if you do things in a controlled manner and double check things it's generally easy to use.

If you have an issue with branching, or knowing which branch you are on, write a script that can fetch the current branch name from ./.git and display it for you somewhere.

If it's main/master then don't display it as your on a production branch.
That's how I deal with floating around several branches.

http://git-scm.com/book/en/v2

https://atlassian.com/git/...

@sariel i hate that that was a good idea from you.

the other idea is if you're on windows just use tortoisegit

nice informative graphical interface.

@AvatarOfKaine even the worst of us can have the best ideas.

It is generally the easiest to pull right before starting to work. I personally tend to forget this a lot though. Doing certain good practices in projects also makes using git easier. For example:
- SRP: Try to prevent huge files and split responsibilities into certain files. That way you can reduce the chance of merge/rebase conflicts.
- Turning one big projects with several programs into several separate git repos. Reduces your chance to be behind in general and you know all commits are for a certain project/program.

Some other pieces of advice I learned:
- Look at "rebase vs merge". Rebasing is cool in that it basicially puts your commits behind what you pulled/rebased against. It also doesn't create an extra merge commit.
- Only push once you're done/satisfied with you changes and tested the software. That way you can use "git rebase -i" to "fixup" fixes into the appropriate commit which reduces bugfix commits. This has no consequences as long as you only change local commits.

Also git tools do all changes to your git files. If a pull for example fails, use your IDE's gui to resolve the conflicts.

Tools like gitkraken or git tortoise also help a lot. Git also includes a graphical tool btw: kgit. It's great for a graphical more detailed view of git diff and log.

The merge issue can also be left to your git server and project maintainers if you make changes on new branches and turn those changes into merge/pull requests. But that's up to how your project is structured at work I guess.

Thanks for all the suggestions. I use VSCode and it helps visualize things better than mere command line does. Sometimes it feels like a hall of mirrors, especially when there is a main repo for our single source of truth but then the deployment environment is a separate remote with its own master and branches to keep in sync with the main repo.

@C0D4 actually, git is hard only with command line. With a gui front end most of the things become clear

Because the industry as a whole couldn't be bothered to organize and MAMAGE, projects properly, it decided that the answer was even MORE power in the hands of the very people who couldn't do it right when it was simpler, because THAT never goes badly.

So, now, as a de facto standard, we're stuck with this abomination called Git because the all-exalted Linus created it so, ipso facto, it MUST be good for everyone.

And, worst of all: most of the industry pats themselves on the back for their "cleverness" and high-IQ for being able to handle Git, all evidence to the contrary.

Git sucks. It just does. It's very cool from a technical standpoint, but it sucks in all the ways that actually matter day-to-day.

One day, I think everyone will realize this and wonder what the fuck they were smoking all that time. Unfortunately, that day is a long ways off, so whether it sucks or not, right now, is irrelevant, we've got to deal with it now.

Bow down before Git, the great and powerful!

May I suggest Sublime Merge?

@iiii only if you let it be, but then I learnt with the CLI and work with it on remote servers, a GUI isn't an option in my environment.

I may try to use a GUI in the future but some of our workflows simply don’t support that. And also people on my team see it as a crutch, weakness, or inefficiency to use anything other than the command line.

@stackodev I tend to agree with the sentiment in some regard.

By using the CLI you actually have to commit to your commits. Having a point and click UI can lead to mistakes.

Think of it like using a hand plane vs a power plane. The hand plane may take longer to master, but you will always get your thickness "good enough" with a power plane.

In woodworking it's the difference between a professional and a craftsman.

Just to be clear, you don't need to be a craftsman to be a great dev but boy does it look great on a resume.

If you’re on Windows, use Sourcetree. It’ll save your life

@C0D4 fair enough. But it's still generally true that cli git is an overcomplicated mess

@iiii I struggle even to remember the most basic commands in git. I keep a notes file to remind myself of how I did something before. “Before” meaning about an hour ago. But this is true of all CLIs for me. I have a memory _worse_ than a goldfish.

@stackodev and those commands aren't exactly intuitive at all. Functional - yes. Intuitive - no.

@iiii I remember having started with SVN, rolling it out to a team I used to manage. And before that something I think was named “trac”. Things were a lot simpler then.

@stackodev mercurial was decent as well, but not very popular

@iiii wasnt mercurial basically git ?

@stackodev yes you still had merge problems though

@AvatarOfKaine a simpler variant of git

@AvatarOfKaine Honestly it was so long ago, I’ve forgotten almost everything about them.

@stackodev yeah well i had it engrained in my skull i guess. i still don't know how git can be such a large difficulty or what people would use its advanced functionality for
branch yes
push/pull/commit
rebase yes
blame yes

but what is all these things i'm not seeing about it being difficult otherwise ?

most annoying thing i did was have to figure out how to direct changes from an existing local repo in order to a new one linked to a remote.

@stackodev svn was nice though
you just had to have a server running all the time
and your choice of comparison tools for fixing conflicts better be decent (beyond compare i thank you :) )

@stackodev do you want the world to move on ? I know I do. all my reasons for hating people aside. why can't we just know comfort and interest and gain ?
and i am really leaving out my normal desire to tear peoples heads off from this comment, for many reasons.

@stackodev I'm sick of the circus around me. i like tits and ass and legs more than apparently most men in my environment ha, but they're not doing me much good if I have no interest in the weird ass system involved in getting them which challenges my comfort and my conscience, and makes nothing worthwhile.

whole world has been trained to be cross eyed retards seems like.