git gui for mac?
 

Anyone able to recommend a stand-alone git client for the Mac users out there? I'm happy using it via my IDE on my Linux box, and we don't have any windows machines to worry about atm. Mac users are doign HTML stuff, so I don't think they need/want a full blown IDE like NetBeans or Eclipse, they use Sublime as their editor...

Of of 'em actually asked me about using the command line to do it.... and while I love me some blinkin cursor action, I don't wanna traumatize them too much...

Thanks!

What?! You aren't demanding that they us Vi? I guess vi is just an editor and git is version control, so not really exactly the same thing. I'm relatively new at this whole scripting thing myself.

https://git-scm.com/download/gui/mac

https://www.slant.co/topics/4985/~visual-git-guis

I use https://desktop.github.com

Some of my guys use Tower . https://www.git-tower.com/mac

For a terminal emulator check out iTerm, https://www.iterm2.com

My most frequently used editor is Brackets. Brackets - A modern, open source code editor that understands web design. .

Oh fer forks sake....

git pull
git commit
git paid

git from the command line is not as as intimidating as it seems, and I think devs worth their salt should really know how to cherry pick commits, resolve conflicts, rebase from the command line.

^ :)

Seems like you are creating a problem looking for a gui

Command line ain’t so bad in this case.

OK, like I said before, I'm new. I know commit, status, diff and add. What you've got listed barely intersects with my list. How about a slightly longer version?

My git is just local if it matters.

I'd rather not retype the git docs here, but for some background I work on a team, and git branching rules how we work together.

There are different strategies for git branching. Our team has a single main branch we call 'Release'. Putting your stuff in the Release branch means that its ready for testing, and you intend it to go live in the next product release.

So lets suppose you want to work on a new feature, and its a big one. Your are on the Release branch, and checkout a new branch to get started:

git checkout -b my-new-feature-branch

Great. Now you and your other team members want to start working cards for the new feature, checking out tiny branches to work individual cards, and then merging them back into my-new-feature-branch. All good, except that the Release branch is still out there, and people are adding new commits to it all the time. You want to make sure you keep your feature branch up to date with Release by doing a frequent rebase. Basically you are taking all of the new commits in Release, and replaying them over the top of your branch, to ensure you are up to date.

Ah, but what if someone has merged something into release, and it conflicts with a change in your branch? This is called a merge conflict. Git will tell you were the conflicts are. You open up the code, resolve the differences, then commit the fixes.

Last one, cherry picking. Lets suppose you have a branch, and it gets really screwed up. Perhaps someone accidentally merged in a bunch of stuff, and no one notices for a long time. Now you want to merge your stuff in, and realize that the branch is wrecked. Doing a cherry pick, you can open up a fresh branch, then retrieve only the commits from your feature branch that contain the stuff you want. The new branch with only the good stuff can them be merged in. And the person who messed things can be made fun of an buy the first round after work. :D

Hope that helps.

I am OH SO not a git guru, but a bit of advice is to commit frequently. Not every new method you created, but don't type all day them commit. Having frequent commits means that if something goes wrong, you can get yourself back to a very specific point in time before things went off the rails. You can't do that if you type for 8 hours and commit it as one big blob at the end of the day.

Good stuff, thanks for the info.