I'm forced to work with LabVIEW source code on a Windows 7 machine and am curious what might be the best setup to handle the source code in a remote Git repository.
Currently I'm handling everythin like I would with my C projects, means Git Bash and a simple .gitignore file that excludes .aliases and .lvlps files, but think that there might be some possible improvement.
Thanks for every suggestion.
You could look for tips and ideas in the NI Community Group set up just for Git users.
https://decibel.ni.com/content/groups/git-user-group?view=blog
If you have LV professional you can get diff and merge to work using
https://github.com/joerg/LabViewGitEnv
I use this together with git bash.
Well, what answers do you expect?
If you are searching for another git client, i can recommend you TortoiseGit. Im working with Egit, but thats only for eclipse. Im sure there are a bunch of clients out there, just google it.
Other than that, Git Bash is fine. It works, why change it? Using another client won't give you any benefits other than better UI's.
Related
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).
Not sure if I should be asking here or Server Fault.
Anyhow, I recently started a project at a new job that has SVN installed. I didn't use it even though I was given SSH access with some keygen thing. But now I've done some reading online for beginner's and I'm having a tough time getting past "which svn" after I input a command through SSH. I guess that tells me the path to the repository (which is /usr/bin/svn) but I don't even know how to get to that directory (I'm using Terminal on Mac OS X).
All this makes me feel pretty stupid, since I've never really had to use the terminal to do web projects before and this is my first experience with SVN via SSH (Hell, first time using SSH even).
I have been googling and reading for a weekend now, but I figured someone on here probably has a good idea of where to find the files or to check which are under SVN etc. I think my main problem is finding out how to use the terminal to "get" to the folder I want to be working on.
I did read up on the commands to check if a file is under SVN, check out, update, commit, etc. I would just like to know how to get to these files to do that. Sorry for the noob question and thanks in advance
Bonus points if someone explains the benefits of SSH (I totally understand the benefits of SVN and would love to learn it properly)
You're likely better off using a subversion client. Two of the most popular ones for OS X are http://versionsapp.com and http://zennaware.com/cornerstone/index.php (lately my dev friends seem to like cornerstone more.)
These should let you do all (or nearly all) SVN functions, but by using a GUI. You'll still want to learn the terminology. Take a look at http://svnbook.red-bean.com/en/1.6/svn.basic.html
You want SVN+SSH as it's more secure, but that shouldn't mean you have to use the command line.
Well there is no need to go to the /usr/bin even though svn resides there. /usr/bin is a standard location which is automatically included when the system tries to resolve the location of a file. You should be able to just start using SVN commands like:
svn checkout ...
The benefits of using SVN and SSH are separate questions all together.
svn list --verbose http://host_name/svn_dir will give you a list of the current versioned projects (including revision number and modified date)
svn checkout http://host_name/svn_dir/repository_name projectx will checkout the repo (creating a working copy on your local machine)
I'd recommend the manual here, even if you don't read it to start with and just use it as your first reference point when needed.
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've been using Vim (MacVim) exclusively for months now, and I love it. Before using Vim though, I used Coda (I'm on OSX), and the one thing I miss about Coda is the way it marks my files for publishing via FTP whenever I edit them. I can then choose to upload the modified files single files individually, or to publish all of them in one go.
Is there anything that will do this or similar in Vim?
I'm aware netrw can edit directly over FTP, but I have all my sites running locally as mirrors of the online sites, so I need to edit locally and publish files remotely as and when I need. I've Googled for solutions but can't find anything.
I'm far more productive in Vim while in the editor, but having to open up an FTP program and hunt and peck to copy across files as I edit them seperately is a real pain, and makes me less productive overall when working on websites when compared to working in Coda.
Any suggestions welcome :)
Transmit, Cyberduck and YummyFTP (the ones I know) all have their own version of "automated folder syncing" where you work locally and any modified files are uploaded on change: you setup an "observer" and never have to hit a special button or shortcut again.
If you want to only use MacVim you could write a little command that uploads the current file on save: a script that would use the current file's path to construct an scp command. But this doesn't seem very portable/practical to me. It appears some people have already written something like that: here and there.
The right way is (not only in my opinion) to:
have everything under some kind of VCS like Git, Subversion or Mercurial or whatever floats your boat
write your code in a local clone/checkout and test the hell out of it on a local server
commit only working code
push milestones to a staging server used by you and your clients to test everything, this part can be automated via a post-commit hook or something like that
deploy only validated changes on your production server.
All the aforementioned Version Control Systems can be used directly from Vim's command line with :!git commit or :!svn update… If you need more abstraction, Fugitive (Git-only) or VCSCommand (multi-VCS, my choice) are here to help.
On your loss of productivity due to uploading files: I think it's very normal because you essentially perform very different tasks with very different neurological needs. This speed bump can also be experienced when previewing a layout change in your browser, looking up a color in Photoshop or any other similar task. I don't know of a way to pilot Photoshop, Chrome's dev tools or Outlook from within Vim and I don't think such a gizmo could reallistically exist so you will probably have to bear with it.
You can try git-ftp - a git based command line ftp client. Then you can manage your project as a Git repository, and git-ftp will only upload the files marked with Git - and only if they have changed.
The downside is that you are going to have to learn Git - and that's a bit overkill for what you need.
The upside is that you are going to learn and use Git.
I have since stumbled upon a Vim plugin which works with Transmit (which I happen to use as my main FTP client) and allows me to upload the current file to the server with a simple keymap (Ctrl+U) as I edit.
This strikes a nice balance between being a very simple solution, and one that does enough of what I need to improve my productivity significantly.
Any more suggestions are still welcome!
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Git GUI.. stage everything
My employer is finally looking into setting up some source control after much pleading by all of the developers. Unfortunately, none of our developers, inclusive of myself, have ever done much with source control. I've looked into SVN and thought that would be fine but another of the developers didn't like it. I've moved on to looking at GIT as an option. I've downloaded the GIT GUI from http://git-scm.com and started tinkering with it which brings me to my question/problem.
The web application we're trying to add to source control (GIT) is 7,386 files and 712 folders. When doing the initial commit, from what I understand, I've got to click on each file I want to commit to move it from the Unstaged Changes to Staged Changes pane. Well obviously I am hesitant to sit and click 7,386 times (once for each file to commit). Is there another faster way to do this?
I'm currently using this page as my reference to learn to use the GIT GUI http://nathanj.github.com/gitguide/tour.html. If anyone has a better tutorial/reference for using the GIT GUI I'd much appreciate linking me to it.
Thanks
To add every file (that is not ignored), use
cd /path/to/workspaceRoot
git add .
I don't use any gui, but I think this should be possible by adding a directory (the root directory in this case).
Remember to create a appropriate .gitignore file before, so no unwanted files get added. You can check, what is (un)staged with
git status
Also, there should be a context option (or something like that) in your gui, that provides status.
Extra: Additional git resource (quite good imo) http://progit.org/
From Git-GUI select all files in the "Unstaged changes" list and select "Commit->Stage to commit" in the menu.
If you're not afraid of the command line, try this tutorial instead. It's a detailed walkthrough of beginning git in 10 parts and ends with a Git reference card to help you go further. The free Pro Git book is also much applauded.