![]() I have not found one better than sourcetree, and I find sourcetree to not be better than the CL.Weak SSH keys have been revoked by vendors to protect their users Like you, I have also tried to find a better GUI for git. We're sincerely trying to encourage you to try the command line UI as many of us have had to work with both the CL UI as well as GUI clients for git hub and many of us seem to agree that the CL UI makes way more sense.for both programmer and 'not a programmer' people. Now, how do we get you to understand that using a command line isn't programming? □ How do I get people to understand I'm not a programmer! □ You can then do that by just telling git which ones to add: I often have to modify a bunch of local files to make things work but don't want to push any of those changes.I only want to push the changes to particular files. You can then choose which of those you'd actually want to commit. That will give you a list of the files that were changed (or added, or deleted, etc.). To see which files have changes you'd type: I assume with command line I cant see all the files I have changes to potentially commit with icons representing file type and status? There might be something better than sourcetree.but I wouldn't be surprised if there isn't.īut, anyways, I'm not here to convince you one way or the other. ![]() It only makes sense in the context of itself. I won't call it broken, per se, but it's absolutely clunky. The problem is git, itself, is a clunky mess. I'm basically looking for something like sourcetree that isn't a clunky, broken mess. But that's an issue outside of any particular UI/command line tool. Now, to be fair, merging is a bit of a pain.not so much because of the command line, but merging, in general, can be a pain when conflicts happen. So if you grabbed the latest, edited one file, but it shows 100 files were changed, that's OK, as you'd only be adding your one file: It won't accidentally add any files you don't tell it to add. It will only add the files that you explicitly tell it to add. Well, that's another argument for the command line. I have to be very careful to revert and remove anything I haven't personally changed every time I check in People who aren't programmers aren't programmers.īut the command line isn't programming. I'd argue that's way easier than trying to learn sourcetree. If that's all you do most of the time, that's 4 commands you need to know. ![]() pushing the branch with your committed changes Understanding how a visual UI is translating your button clicks into a command line is, IMHO, way more complicated to understand than just learning the handful of command line commands most people will need to know.įor the work you're doing, I imagine, 90% of the time, you'll be: The command line isn't very technical at all as it's you interacting with git directly. not sure how sound software program will manage this aspect.Īs someone that has used both command line and sourcetree, and as someone that really hates git-even after using it for several years now, I can say that the command line is WAY easier to get the hang of than Sourcetree is.Īnd sourcetree is often see as one of the more usable visual clients.Īt our company, when a branch goes awry, 9 times out of 10 it was due to a developer (yes, a technical person) screwing it up by clicking the wrong things in sourcetree. doesn't work as well with sound waves files. Lastly, git works best when using text files. sublime also has a nice merge tool with a generous trial tier. i haven't used visual studio's graph extension. Then: gitk and git kraken are what i would recommend. Otherwise, what's the point of using git?īut ok you don't want to use the command line, nor github's desktop client (which is super sleek btw). When you do, you will need to be somewhat comfortable with digging into the reflogs to undo these issues. secondly, chances are you will eventually have a mishap. i would even venture to say, that if one has a good conceptual understanding of git, it is highly unlikely that a UI client would be preferred for 95% of the use cases out there. The only times I would argue that a git UI client is better, is when you are trying to handle complex merge conflicts or if you want to visualize complex branching, or to visualize other changes over time. I would extrapolate further: for most cases, it's infinitely easier to use the command line, rather than a UI. you don't need to get super technical: just bare-basics. I don't think git can be used without a good conceptual understanding/model of how it works - simply using a nice UI client will not really solve the problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |