I'm in the process of convincing my team to move to using git for version control (from svn). The major hurdle seems to be convincing them that it's not going to be too complicated for others. To alleviate that, I'm attempting to create clear documentation. I need some help though with Eclipse/EGit, since I'm not as familiar with them. Coming from a Linux background, I always use git from the command line, but this is a Windows shop and asking IT to install git on everyone's machine will be seen as another layer of complexity.
So far the process for starting a new project is logging into the (linux) development server and creating a bare repository in the appropriate directory. The bare repository is (obviously) empty at this point -- so no master branch yet. This is where the question diverges from the others I've seen on SO, and most of the documentation I can find.
My question is what is the best way to clone that bare, empty repository into Eclipse and set it so that it knows to push to origin/master? I can clone it in the Git Repositories view though it seems unhappy that there's no branch. Then I can switch to the appropriate perspective I'm using for development, create the project, then import the git repo, add files, and finally commit and push and it will finally create the master branch. However this seems convoluted. Is there a more straightforward way to do this?
Thanks for the help!
Related
I am new to git. I know few basic things about git and I have quite successful in using it.
So I have a master, develop branch. From develop I have branched out to a feature branch and a release branch. For branching out from develop I used the following commands.
jgitflow feature-start from develop
jgitflow:release-start from develop
Now I am done with the feature and I want to merge into develop. I am doing this for the first time. Now I am confused as to how to do it. Ideally I should be using the below command:
jgitflow:feature-finish
The other option I believe is doing a pull request.
Please let me know which is the correct options and what happens if there are conflicts while using jgitflow:feature-finish
Pull Request is essential as it would get the changes reviewed. However, if you merge from the PR, you would still be able to run jgitflow:feature-finish, albeit it will result in keeping the remote branch (if pushed before).
Ideal way would be to
Raise PR for the feature, get it approved.
Run the feature-finish command to merge the changes to develop and clean up the local
and remote feature branch.
To resolve conflicts, it is always better to pull from develop locally instead of merging through feature-finish as it can get messy.
The details are available at https://bitbucket.org/atlassian/jgit-flow/wiki/goals/feature-finish
Use the necessary flags like keepBranch, squash based on your requirements.
You should also use featureRebase as true. This will rebase the feature branch before merging from the origin which is develop in your case. This will allow you to handle conflicts in a better way.
The easiest way to avoid conflict when trying to finish a feature is to adhere to the following workflow before executing finish-feature:
git fetch: make sure your local repo copy is up-to-date
git checkout develop: go to develop
git merge origin/develop: make sure your local develop is up-to-date (origin being the remote's name here)
git checkout <feature-branch>: go to you feature branch again
git merge develop: Merge and solve conflicts, if any (on you feature branch)
mvn jgitflow:feature-finish you already solved the conflicts, so this will work
I would not recommend the featureRebase option which was mentioned in another answer since you said you only know a few basic things about Git. Rebase can complicate things if you have pushed your local feature branch and other people are working on it.
Rebase is only safe to use on local branches since it changes the history.
Regarding pull requests, see Gitflow Workflow With Pull Requests on https://www.atlassian.com/git/tutorials/making-a-pull-request/how-it-works
I've also asked this on reddit, but I'm hedging my bets by asking here as well.
We have an employee who needs to be able to treat a remote non-bare repository as if it's a local one. This employee needs to be able to branch, commit, and merge. There are are a few complications.
Employee is on Windows.
Employee has only surface familiarity with git, and needs to be able to do everything via a friendly GUI.
Employee works from home over a spectacularly flakey internet connection.
I believe that a good solution would involve using sshfs to "localize" the remote repo, allowing any git GUI to treat it as if it's local. But we don't know if this will be compatible with an internet connection that comes and goes periodically, and according to the phase of the moon.
Additionally, the senior engineers would prefer finding a GUI client that has built-in support for administrating remote non-bare repos, rather than doing it with an sshfs "hack". Unfortunately, that would rule out SourceTree, with is the preferred choice of the employee in question.
Really, this is two questions in one:
Is there any reason that sshfs would be unsuitable for a use case with infrequent changes, but a shaky connection?
Are there any git GUI clients for Windows that support this functionality built in?
It looks like we have an alternative solution, that sidesteps the problem entirely with git hooks. I'll just paste in the reddit comment:
It's looking like we're going to end up solving this with git hooks, as follows:
Have bare repos at /srv/git, and non-bare repos in the employee's ~ dir
Employee works in local repo, pushes to remote bare repo
Git hook in remote bare repo does the following:
cd ~name/$repo
git fetch --all
git checkout origin/$branch
Thus, the working dir is always the latest commit of the most recently pushed branch.
For the employee, it's as easy as hitting the "Push" button in SourceTree. All the magic happens on the server.
I'm currently starting to develop an ios app with some friends. We'd like to use a private github repository for version control so we can collaboratively work and push changes to the code. Xcode 5 creates a local git repository, but there seems to be some differences between using git for an iphone app versus the class projects (java projects like connect 4) that I've been used to.
I've created a repository on github, and pushed an initial commit from my local xcode project to the github repository. However, I'm not sure if others will be able to download the code and import it into an xcode project and have it work as intended.
For one, the files on github are organized differently than it displays from my workspace in xcode 5. From the project navigator, most of the yellow folders (folder references, which I don't fully understand) aren't actually folders, and don't appear on the github page. Also, many things (infoPlist.strings, frameworks) are represented in a humongous "project.pbxproj" file, along with confusing build information.
I know that this is a vague question, but I really had no idea what to look up or read. Let me know if there's any way I can improve asking questions on stack overflow. Also, if you know any guides that would help me out with this kind of stuff, I'm all ears.
Introduction
Git and Xcode work wonderfully together to create applications that foster teamwork and minimize versioning complications. However, it's important to understand the basics of Git before proceeding. This answer will walk you through the steps of integrating Git with Xcode, which really isn't too complicated once you understand what's going on.
The difference between Git and GitHub
(The OP might know this distinction, but this is really for anyone else who visits this page and is confused)
The first thing to understand is that Git and GitHub are two completely different things. Git is a version control system, like Subversion (SVN), or PerForce. It can be used independently of GitHub. GitHub is a cloud repository storage system that is integrated with Git. That's why it's called GitHUB; it's a HUB for your code and all it's versions/commits. Git can work with many repository storages, one of them being BitBucket. (This is unlike Subversion, which doesn't have a local repository and a remote repository; you have to push changes from your local repository to your remote repository in Git).
The question asked how to integrated GitHub with Xcode - the evil answer to that is you do not; you integrate Git with Xcode (which Apple has already pretty much done for you). When you commit something in Git locally, you push to GitHub, where your code is stored, and where others (e.g. team members or the public, depending on your privacy settings) can clone or fork your repository and build on it.
Create a remote repository
Let's assume you're starting from scratch. If you're not starting from scratch and already have code in a remote repository, skip this step.
In this step, you want to create your repository on GitHub or BitBucket. Follow the instructions that these sites give you to create the repository.
Getting the URL to Clone the repository
Whether you're using GitHub or BitBucket, you have to be able to tell Xcode where you are storing your code. Find the URI that allows you to clone the repository; GitHub and Bitbucket should have easy steps for finding these. Usually look for the word "clone" on the main screen of your repository, and you'll find it.
Clone locally
Fire up Xcode, with a new project. Hit the "Source Control" menu bar item, and select "Checkout". In the popup where it says "Or enter a repository or location", copy the clone URI that you acquired in your previous step. Then hit next. When asked to clone, Xcode will prompt for a branch; pick which one you want for now. If you have no idea what branching is, then choose "master".
Conclusion
Now you're all set. From now on, most things you need will be under the "Source Control" menu bar items as well; this includes committing, pushing and pulling. Enjoy, and good luck!
Setup the Xcode project as shown here.
Once, done you can see which file’s have been added,modified etc in project navigator.
https://www.dropbox.com/s/r5gsfh2raxwkam6/Screenshot%202014-07-30%2015.03.03.png
For commit,push, or to discard changes, use
Here’s detailed tutorial : http://www.raywenderlich.com/51351/how-to-use-git-source-control-with-xcode-in-ios-7
This might be verbose, but I'm just starting out with git, so I'm still learning here.
Before now, I've had a team of developers all working off of the same hard drive with a local copy of all of our dev files. So we have 1 hard disk and 4 developers. All of us use sublime text and work on the projects together. We all work in the same room, so it's never been an issue to work on the same project at the same time. We just don't work on the same file at the same time. Not the greatest system, but it worked at the time.
Now we want to introduce git to the team for all of the reasons a VCS is important. The problem we're running into is files being locked by one user and no one else can use git on that repository.
Here's an example. I log into my mac in the morning and make some changes to files in Project X located at /Volumes/dev/projectx/. I open terminal and commit those changes to the local repository (stored also at /Volumes/dev/projectx/). My coworker gets in and logs into his mac. He opens up his terminal to check the status on the repo he's working on. So he moves into /Volumes/dev/projectx/ and runs git status. He gets an error message that says the index is locked. In order to allow him to run any git commands on the repo, I have to completely log out (maybe just kill some processes, but I don't know which ones). After I log out, he can work as though there's no problem.
Is there any way that we can both work on the same local repository at the same time?
I've also discovered that, if I'm working in a project that has a git repository in it and anyone else even opens the project folder in a finder window, it completely locks me out from using that git repo (same index lock error).
We're willing to change the way we work on files, but since there are literally thousands of projects on the drive, it isn't really practical for each of us to have our own local copies of all of the files. Also, since many of the changes are a very simple text change of some kind, it seems tedious to host all of these repositories remotely and have to pull down all the files anytime we only want to update a single file.
I'm really looking for workflow suggestions here, but the question I asked is kind of the starting point here.
The whole point of using git is that you don't have to do this kind of crazy stuff.
I know what you've said about why you don't think you should all have complete copies. Here's the hard truth. You're wrong. Mostly. But that's ok, you said your willing to rethink how you work and that's good. Ill try to explain why its not that big a deal to have everyone use their own clones.
A assume all code is already in a remote repository - if its not, sign up on http://github.com or http://bitbucket.com and get a free repository, add it as a remote to your git repo, and push it up. Its really very simple.
Each of your developers should then make their own directory locally on their machines where they can clone the whole repository.
git clone http://github.com/yuoraccount/yourrepo ~/clones/localproject
The first time they clone, it will take a little time to download everything, but from then on, only each minor diff will need to be downloaded uploaded. Git is made to be efficient that way.
When you make a change, commit it, and push it up.
git commit -am "i made a small change"
git push origin master
Then everyone can pull it down.
git pull origin master
You can even all work on different branches, so your not just pushing to the same branch. This should all be really simple, and very easy to do.
You can also split your project into multiple repositories, but you don't really need to. Thousands of files is not a big deal, git can handle it without a problem. That's not to say that you won't have some challenges. Git is easy to use, but you'll eventually run into merge conflicts. They will be a little bit frustrating at first, but stack overflow has a thousand answers explaining how to deal with them - you should be fine.
This is what git is for.
Git is a decentralized version control system. The way you want to use git could be described as the opposite of decentralized.
There are a number of perfectly reasonable workflows possible with git, but all of them are going to involve each developer working in a local clone of some repo.
i guess that your "single harddisk" is really a single "network storage" that can be accessed concurrently. otherwise i don't see the problem (the harddisk can only be attached to a single computer at any time; whenever you unplug the disk, any locks should be released!)
anyhow, though you currently consider it impractical, you still might consider using per-user clones of the repositories.
the normal workflow of a multi-user repository would consist of a local clone of each repository on each developer machine (that is: a clone on your personal mac).
then the trouble with concurrently accessing the locked central repository doesn't exist!
it's exactly the use-case for which git was designed.
this would allow your users to work on the repository even without having access to your central network storage.
if you are concerned about disk-space, you might be happy to hear that git does a pretty decent job of compressing the data (just run git gc every once in a while in your repository).
if (for whatever reasons) you cannot have local copies (on the dev-machine) of the repositories, you might consider having per-user clones on the central storage.
git can use hardlinks for local clones, so disk-space should not be an issue here.
Section 4 of the Pro Git book (version 2) is about "Git on the Server" and gives some information about what the OP is trying to achieve.
The OP's situation calls for the "Local Protocol".
Here is how this works:
1. Create a local remote from your project
cd into your project and create the remote in your preferred location (in your example /Volumes/dev/projectx):
git remote add origin /Volumes/dev/projectx.git
2. Set the permissions for the remote
git init --bare --shared /Volumes/dev/projectx.git
This will set the permissions properly so that different users can push and pull to/from the remote. This command does not affect your Git history and is safe to run.
The --bare flag is used because all that is needed for a remote is a bare repository, that is, a repository without a working directory (a repository with only the .git directory and nothing else).
Note: this step is not described in the Git Book for the Local Remote protocol and is only suggested when setting up a Git server, but in the experience of a colleague, without using this step, the permissions were not set properly.
3. Push the data to your new remote
Assuming you have a branch called main (do this for any branch you want your collaborators to have access to):
git push --set-upstream origin main
4. Have your collaborators clone the remote
This works as with any remote:
git clone /Volumes/dev/projectx.git
From here on, everybody can push and pull to/from the local remote.
I have just joined a team of two, and am in danger of having to being asked to use SourceSafe if I can't establish a git repo very quickly. I would like to avoid any web server etc. setup and just use a shared folder, but suggestions along this line haven't been very clear and have not worked.
First, I tried 'git init --bare' in the shared folder, and this seemed to work, but I cannot clone this repo to a local repo as I get told no repo exists there.
I would appreciate if somebody could give me clear instruction how to achieve this, please.
It shouldn't cause any problem to share a repo this way, that's the exact setup we have here.
Be sure to specify slashes when giving repo location, and that the share has been accessed in the Explorer in case it requires authentication.
git clone //server/share/path/to/repo.git