Every time I was thinking of switching all of our little team's projects to git / github, what pained me was that there didn't seem to be a tool to visualize all this social coding goodness.
When we all start wildly branching, forking and merging, I feel we're going to need a tool that would let us graphically see the full picture of our repository and its multitude of branches, in order to come up with a plan to merge it all back at some point into one and only truth (the proverbial origin/master).
I've tried googling for such a visualization tool on several occasions, but came up empty handed. Was hoping that GitHub for Windows would solve this once and for all, but all it shows is linear history for a particular checked out branch.
What I'm looking for is something akin to what TortoiseHg has - a graph showing all branches and commits. Are you aware of any such tools? (We're on Windows.)
SourceTree seems friendlier than TortoiseGit for the graphs and you can interact with the graph as well.
Stick with msysgit
gitk --all
is what you want. From there you can even checkout branches, reset them, view diffs, etc.
For something quicker, I would suggest
git log --all --decorate --oneline --graph
This gets piped through less by default which gives you good navigation including search.
Another option is just to install linux in a VM (virual box is free) and use tig. You can ssh to the VM so you don't have to deal with the VM itself while using linux.
GitExtensions is your best bet.
TortoiseGit is ok, though in it's attempt to "protect us from ourselves", they hide some of the native power of Git. Fail.
SeeGit is an interesting project from Phil Haack that helps visualize things.
The best tool is the command-line and a quick command like this is probably easiest and most powerful:
git log --oneline --graph --decorate --all
That pretty much would have to be TortoiseGit since you are already familiar with TortoiseHg. (Check All Branches)
Now days VScode has extension called git-graph, which worked best for my needs.
You could use Le Git Graph (read as legit graph), a browser extension that does exactly this, within browser.
Install the extension from here : https://chrome.google.com/webstore/detail/le-git-graph-commits-grap/joggkdfebigddmaagckekihhfncdobff
It will add a new "commits" section to every GitHub repo you open. Open the commits graph and there, all commits across branches will be listed along with the git graph.
Hope it helps!
An upvote would be highly appreciated!
Depending on your push \fetch \ pull habits then you can either use the gitk viewer to see what you know locally (including the remotes you have fetched), or you can use the Network capability on Github to see what it has.
Just select a multi-forked project (with not too many forks;-) and click on the network tab to see how all the other forks relate to it.
Some times you do need to switch fork to get the view point you want, but it's not too much hassle, and for a small team it looks ok.
I have made recent suggestions to Github about selectivity for forks (to down select when there are a lot of forks to display).
Related
I work mainly on a desktop Mac but also have a laptop Mac that I use when away from the office.
I want to access and work on my latest html, css, php and python files from either computer.
I thought Github was the way to do this but am having a problem understanding the "flow" and I've RTFM! I don't understand whether I should create a Repository on Github first, why when I try to "clone" something it doesn't magically end up on my local computer... where the nice big red button that says "sync" is...
... or whether I should just use the commandline ONLY...
So, if I start on my desktop and create new files, what are the correct steps using git or Github (?) to put those files where they can then be accessed from my laptop and then have the files on my laptop merged back into the ?Github repository so I can then access those files from my desktop.
Thank you all for your replies and answers! The git workflow, for my needs, is now clear.
The workflow presented by wadesworld is concise and was the overview I needed.
However, Michael Durrant's commandline steps filled in that workflow specifically with commandline directives - and I needed that also.
steelclaw and uDaY's answers and responses were important because I did not understand that it did not matter which repo I created first and, adding and committing locally were essential first steps in my workflow.
Specifically, steelclaw's response to one of my response questions provided the closure I needed, so I could learn more:
After initializing the repository, be sure to use 'add' and 'commit.' These will make the files an official version of the repository. After that, you need to use 'push' to upload it to the remote repository."
ilollar's resource, "Git for Ages 4 and Up" is also worthy of the click, especially for folks like me who are visual!
Thank you all so very much!!
Do you want to version control your files or just have access to the same files in both places?
It is a good idea to use version control as a developer, whether you're writing code or designing websites. But, to do so, you have to have a commitment to learning how version control systems work, since they all have some learning curve.
But, if you're not interested in that complexity and simply want to be sure you have access to the latest version of your files, then you're looking at a file syncing operation which can be much more simple.
So, which one do you want?
Edit: Based on the response, here's the model:
1) Create repository on work computer.
2) Create repository with same name on github.
3) Push to repository on github
4) At home, do a git clone to pull down the changes you pushed.
5) Now that the repository exists in both locations, you can simply do a git push before you leave work, and git pull when you get home, and vice-versa when going the other direction.
To answer the detail of your question: I'd go with Dropbox.
UbuntuOne is also good even for non Ubuntu users and of course Google drive is the (big) new player on the block.
They compare as follows:
Service Free*1 NextLevel*1 NextLevel($)*2 Features
Dropbox 2 50 $2.5O One Folder, best gui sync tools.
UbuntuOne 5 20 $4.00 Multiple directories anywhere
GDrive 5 25 $2.50 It's Google.
*1 GB
*2 Cost per month
To answer the title of your question:
If you wanted something that's more suited to programmers, I'd use git:
First, install gitx (linux readers, that's gitg) as that is by far the most popular gui for git:
For the "flow" I can also refer you to my write-up of various features at:
What are the core concepts of git, github, fork & branch. How does git compare to SVN?
Using gitx or gitg the specific flow is as follow:
1) Make some changes to files.
2) Use the tools "commit" tab to see what's changed ("unstaged"):
3) Add a file by dragging it from "unstaged" to "staged":
4) Give a commit message
5) Commit the file.
6) I then push it to the remote at the command line with $ git push remote or I use the gui by right clicking and select ing the 2nd master - see here:
.
If I'm sharing with others I'll often need to do git pull to get ands merge in others chnages) before being able to do a git push
The github part is doing init and push and clone but I'd say just read up on those tutorials more rather than an SO question. Basically though, I do:
Set up repository locally in git:
git init
git add .
git commit "Initial commit"
Set up github:
Create a github repository using github (https://help.github.com/articles/create-a-repo)and then push your local repository to it as in:
git push origin master.
If the repository already exists on github but not on your local pc, that's wheh you click the remote link and then in a terminal type git clone [paste here, e.g. ctrl-v]
If you're "starting" with github:
Make code changes
git pull - get latest version into your repository and merge in any changes
git add . Add all modified files
git commit -m "message"
git push # origin master is the default.
If, at the end of the day you decide to go with something simple like Dropbox you can use my referral link -http://db.tt/pZrz4t3k- to get a little more than the standard 2GB, Using this we both get an extra 0.5 GB, however which of all these routes to go is up to you and your needs. I use all these services (git, github, UbuntuOne, Dropbox and googleDrive, so I am not recommending one over the others -it depends on the needs).
I would recommend using DropBox or Google Drive. They will let you do EXACTLY what you are trying to achieve, they are very user friendly (and free [5 Gb I think]).
They automatically update (as long as you have an internet connection obviously)
Just make a folder, put some files in it, and you are away.
Since explaining how to use an entire VCS in one answer is an overwhelming task, I can instead point you in the direction of some very helpful resources to get you to understanding and using Git:
Pro Git - a free online book (written with Git!) with easy language on all things Git.
GitHub Help - GitHub's own help section walks you through setting up and using Git, and not just with their own apps. Very useful.
Get Started with Git - A good tutorial getting you up and running with Git.
Git For Ages 4 and Up - Fantastic video explaining the inner-workings of Git with Tinker Toys. Not best for an introduction into Git, but a great video to watch once you feel a bit more comfortable.
Git may feel complicated or strange at first, but if what you are looking for is a good version control system, it is excellent.
However, if all you're looking for is a cloud-like service to sync some files across multiple computers, like the others have mentioned, Dropbox would be the way to go.
I use Github as a "hub" of git, to share finished codes. (And Git for version control)
And Dropbox to sync files between different computers and mobile/tablet, to manage files.
http://db.tt/EuXOgGQ
They serve different purposes for me. Both are good!
Git is an advanced and rather difficult tool to use for version control. If you're feeling brave, you can try to install the command line tool, however I recommend using a graphical client, specifically SourceTree.
http://www.atlassian.com/software/sourcetree/overview
You'll need to clone your repository, or else initialize a new one. To connect to your repository, you'll need to know the URL, and possibly a username and password for your repository. You also need to provide a valid name for the repository.
To update files there are several steps: First, you need to add the changes to the directory. Source tree might do this automatically. Then you need to commit the changes. This is basically confirming changes and signing them with a comment. To upload them, you need to use push and select the correct remote repository. When you want to update your local repository, you'll need to use pull and again select the correct remote repository.
For your purposes, however, it seems like dropbox might be better, because it automatically updates and is very simple. If you don't need the advanced version control that git provides (e.g. branching, merging from many users), then it seems like it would be a better option for you.
https://www.dropbox.com/
I started using Mercurial and chose MacHg as my GUI of choice, simply because it was the first thing I found when I googled Mercurial Mac GUI. However, I just recently discovered Murky, and TortoiseHg was recently updated for the Mac. Are there any significant reasons I should choose one over the other, or is the decision simply which application's interface I like the best?
I am the author of MacHg so of course am biased. Re Murky, it hasn't been kept up to date and it will fall over with large scale repositories when viewing history. It has to parse the whole history graph to lay it out (it uses the top level 'hg log'). Through a neat trick MacHg does this incrementally so if you have 200,000 commits MacHg doesn't need to read them all to figure out how to display them it can jump right to the place you are viewing. TortiseHg also suffers from having to read and parse the whole history although it can do this much faster than Murky (since TortiseHg uses faster lower level calls to get the data) (as reported to me by others.)
SourceTree seems like an ok solution. It is supported now commercially by Atlassian who do Bitbucket and they are a nice bunch of guys. However, as of my last test of SourceTree(1.4.3.1) it appears to be limited by the same problems. For instance one test case I use is the OpenOffice mercurial repository which is some 3Gigs with 260,000 revisions. Trying to view the graph for say revision 150,000 is really really slow in these other programs. I quit SourceTree after 5 minutes of waiting.
Also MacHg has some nicer history and rebasing tools if I do say so myself. SourceTree right now has better integration with some of the external services like Bitbucket and GitHub although it is not difficult at all to add repositories in MacHg (simple drag and drop or open, or paste in a string, etc...) Neither MacHg or SourceTree (AFAIK) have support for phases yet but I plan to add these very shortly as I am sure SourceTree will as well. TortiseHg has support for phases I think right now.
And well, I like "look and feel" of MacHg of course :)
You can't go too wrong with MacHg, or TortiseHg, or SourceTree unless you have large repositories in which case I would opt for MacHg for now.
Cheers,
Jason
This question is sort of subjective, but I've found SourceTree to be a good solution for visualizing your working copy. However, for the most part, I just use the terminal to commit/push/pull/update.
MacHg has at least straight forward instalation and Mercurial is integrated inside, what i missing is info, and there is also commandline interface, only documentation is not good enough.
I was in mac-mercurial / python / keyring configuring hell circle, i just new to setup repository for pulls without password asking (where pass is encrypted) from sh script for my build server. MacHg could be the way out, because everything is already integrated in instalation package, except mhg and chg aliases for normal (no MacHG) terminal.
I also missing some info about repository cloning progress, because i cloning 500 MB repository from bitbucket through https take me usually 2 hours. I need to debug if is problem on mercurial, ISP (it should be done in 2 minutes in regard of my connection speed) or bitbucket side.
I have a question, the answer isn't really hard technically, but I am more looking for the experience of most advanced programmers here.
So like many noobs, I am doing my version control in the crappiest way, which is to copy paste my project directory and rename it with the current date/time.
You will agree that it's a quite limited solution :P
I decided to learn version control system(s), but I am facing many choice, and I would like to know what are the best for your points of view ?
Using Xcode integrated version control (git or anything else), with organizer, cloning, commits from xcode etc. I mean totally or almost controlled by Xcode ?
Ignoring Xcode letting him think there no version control and doing it myself in command line ?
A merge of the two above ? How ?
And then :
Using git ? Github is very popular and powerful, but you must learn git, and learn it hard.
Mercurial ? It seems more friendly.
Something else ?
It would be priceless to have some feedbacks about more experienced people, so that me and many others I hope can choose their paths when facing the VCS wall :-)
Thanks a lot !!!
First: Use a VCS at all.
The rest:
Mercurial is nice, but Apple went with Git for Xcode. So if you want source control integration within the IDE, Git is the best option.
The things I miss most when working with Xcode & Mercurial are the "Modified" indicators in the source list and the integrated diff-viewer. (Which is pretty good in Xcode IMO)
The actions you perform in the Organizer are a bit limited at the moment, but you can always fall back to Terminal.app for that.
I can only recommend git. Merging is easy, I remember the days when a merge conflicts occured with SVN, it was pain, horrible pain to resolve those. You can easily start a local repository with git, especially if you are the only one developer.
Have a look at Which SCM system to use with Xcode 4 for a lone developer?.
I suggest some reading on git for the beginning:
Git in five minutes
Git Community Book
The Thing About Git
Take some time to invest in learning the basics of git, it's absolutely no rocket science to get you started on basic usage and you will benefit from it right away. Once you know the basics of git, you aren't locked into another tool wrapping git, you can use git if there are some problems with XCode. Also, git is available for several OS so the knowledge you gain about git will not go away if you move between different computers that have different OS.
Here are my best of bookmarks for git:
http://www.delicious.com/Ralphtheninja/bestof+git
I've had good success with SubVersion.
Using Git on the mac feels like a huge pain, and the Git documentation is just huuuuuuuuge. Maybe someone has a top secret blog article or even screencast to share, that explains the basics fairly simple and quickly?
Creating a repository. Big pain.
Opening that repository with GitX: Pain.
Working in Xcode and then committing changes: No idea, probably big pain too.
Cloning the repository to a few other developers with their own macs so they can start collaborate on the project: Oh man, my head explodes... need a doctor!
Merging those cloned repositories back somehow, so everyone gets an updated repository with the changes of anyone else: Red alert!
Right now I feel I'll need a month to grok it. Would be SO glad if someone can point out really helpful resources that don't force me to read for some days... or is there a great and thin book that explains this madness?
Git is absolutely enormous, and you could certainly spend that month learning its processes, but you can stick to some basic concepts and end up with a really great workflow. I use the command line, as it allows you stick to these basics, and expand out if you need to. These basic commands are "pull", "push", "init", "commit -am "message"". Later, you can read about branches and rebasing at gitref.org.
As a mac Xcode + git user; I definitely recommend DTerm to make life easy. One key command brings up a floating terminal window, CDed to the directory of the file that's currently active. In XCode, this means that you'll be in a git-controlled directory immediately.
So, my workflow --
Use "git init" in the terminal to create a repository
Create github repository
follow github instructions to associate the two
When working in my project, press Shift-Command-Enter to bring up a floating terminal window
type "git commit -am "commit message" to commit all current changes
Same key combo plus "git pull" or "git push" for pulling in changes from code repository or pushing changes to code repository, respectively
I find that the command line allows a much easier working relationship with git than GitX, especially if you're using something like DTerm.
For a great reference, check out gitref.org. Good luck!
Launch a terminal window.
Creating a repository:
cd project-dir
git init
Opening the repository in GitX:
cd project-dir
gitx
Committing changes:
git status
git add . # or individual files
git commit
(it's a good idea to set up a .gitignore file from the beginning.)
Read the Pro Git book or look at some of the video tutorials at git-scm.com to get started quickly. The one by Linus is mostly a description of the implementation plus rant against other VCSs; the second video is really useful.
I used git under OSX for about 6 months (albeit not with Xcode). It's works a treat! But yes, it was a painful experience and a steep learning curve at times, especially when everybody else on the project are Windows developers (with more choice of git clients) and anti OSX (unwilling or unable to help). But it's well worth the effort in the long run. It's doable! Once you've got the basics, you'll find it's 10x better than say Subversion. Merges just work. Conflicts become more or less a thing of the past.
But my advice, forget GitX, it's crap. I started off with it, soon realised it doesn't do (or at least 18 months it didn't do) anything you can't easily do from the command line. It also does a whole lot less. So you end up in the terminal eventually anyway... and that's coming from someone who normally hates using the Terminal due to own incompetence! If you want a decent front end client, try Syntevo's SmartGit. Once I'd found that I quickly grew to love Git.
Also recommend reading the Pro Git ebook, mentioned by larsmans.
Understanding the simplicity of Git is hard. If you have some experiences with other (centralized) version control systems, try to forget them and understand Git's basic concepts (objects, commits, branches,..). There are lot of books out there. I would recommend the short (30 pages long) Git from bottom up, it is free and very useful. Another free learning materials are at gitcasts. Pragprog and peepcode have also great books and screencasts. They are not free, but useful.
I use git with XCode for several months, and they work together. Although XCode hasn't git listed as a supported version control system, you can use git from the command line. I tried to use GitX, but never found it more useful then git from command line. Try it out, maybe it fits your habbits more.
For XCode I found this gitignore and gitattributes file useful for my projects:
.gitignore:
# xcode noise
build/*
*.pbxuser
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
# osx noise
.DS_Store
profile
# other
.svn
*.swp
.gitattributes: *.pbxproj -crlf -diff -merge
I found the Git Book to be a really helpful resource. It explains the basics in simple terms and doesn't try to over-complicate things by going into the technical reasoning behind all the features. At least that's what I got from it.
I'm coming from a TortoiseSVN background and decided to give TortoiseHg a try. One thing I got really used to with TortoiseSVN was the SVN Repo-Explorer, which worked quite similarly to Windows Explorer. However, when I tried to use TortoiseHg's Repository Explorer, what I got was something else, it was more like TortoiseSVN's Show Log. It showed me what the recent commits were and what files were changed and even had nifty graphs. However, I'm still left wanting for TortoiseSVN's Repo-Explorer.
Does TortoiseHg have anything like this? How am I supposed to poke around the Repository if I can only view changed stuff?
I might be wrong as I have little experience with Hg myself, but I believe the reason TortoiseHg doesn't have a repository like its SVN counterpart is because Hg is a distributed VCS instead of a centralized VCS like SVN. So, the actual repository is your "checked out" copy. When you commit, you commit to your local repository, then you can push changes to other people or locations (such as google code, or your team mates). There are actually multiple different repositories for a project located in many places, instead of a single one, so there isn't really any meaning to "exploring the repository". The best you can do is check for incoming change-sets and view your local repository (using windows explorer).
This is mostly my reasoning based off a little experience with both. I might be wrong, but I hope this sounds reasonable.
This article might help clear it up: Distributed revision control. It took me some time to wrap my head around the idea of a distributed VCS too. In a nutshell, it's kinda like emailing your changes to your team mates. Everyone has their own individual repository, and each updates their own repository by getting change-sets from others.