This may be a stupid question, but after several times trying to get this right I'm getting frustrated. I want to use github to host my project, we are 2 people working on the project and the aim was to share the work. And help each other.
I managed to create the resepetory, and committing to master branch. If the other guy deletes the whole project he gets the latest updates, but I'm sure this is not the way its supposed to work.
Lets say I commmit a new class file. I commit this file, how could the other person download this file? We've tried pull, synchronize etc etc without any luck. The only way we have found to give him "my" latest updates is for him to delete all content and make the project from scratch.
What am I missing? How can we synchronize workspaces? So I can see and download his changes when i open Eclipse? (We are not working in the same class). So really all I want to do is download he's latest commits.
EDIT : My solution was that my partner was working in a copy of the local git workspace. So instead of modifying the local repo he was modifying a copy of it inside the Eclipse workspace. And because of this nothing updated when he did the pull. I also switched from Egit to GitHub command line tool, and I'm in love. Thanks everyone :)
Normally with GitHub, all of what you have described works perfectly, I have not had any kind of similar problems.
One thing about git, a commit is a bit different than a commit in SVN. With git, you use push and pull to interact with your remote repository.
I am not sure what you mean when you say:
If the other guy deletes the whole project he gets the latest updates,
but I'm sure this is not the way its supposed to work.
That being said, I have never used Egit, I prefer to stick to the command line for all my git needs. I have had issues with other software (Sublime Text 2) where I would have to exit the editor, then run all my commits and other git actions. I do not know how well Eclipse plays with git in general.
Try to have your partner run git remote -v just to make sure he is tracking the repo properly. Also, do you know if he set up an SSH key for GitHub, or you sending your pushes and pulls via https?
Keep in mind this is pretty hard thing to help you out with since I am not sitting at your computer. GitHub Help has some very good walkthroughs on setting up git and remote repositories.
Also, I highly recommend the time to go through CodeSchool intro to git. If this is your first time using Git, this is the best starting point.
There are much more complicated scenarios, but basically, you need to "push" your commits to the upstream, and pull your colleague's.
Clone the repo. By cloning it you will guarantee that it has an "origin", the github remote. You make changes in your local repo, committing them as you go. When you are at a milestone, use Team > Push to push all of your commits to github. Your colleague will pull them, as described below.
When you try to push, you may discover that your colleague has pushed changes and that git will not allow you to push until you merge. Try Team > Pull which will merge the remote changes into your local repo. If there are no conflicts, you can now push. If there are conflicts, fix them and then commit. Then push.
This is a substantial simplification but may get you started. The main point is that the equivalent of a SVN commit is, in git, two, maybe three, operations: add, commit, push. Git pull is vaguely analogous to SVN checkout.
Take a day to read up on git. There's great documentation at GitHub. Once you get the hang of it, you'll love it.
When using git to collaborate on a project, you are managing both a local and remote repository. When you commit, you are only saving changes to your local repository. After committing, you need to do a push in order for your changes to be saved to your remote repository. After doing that, if your collaborator does a pull he will get your changes.
Related
I am working on a branch (feature01) and it is still work in progress. Now I have to leave the WIP branch and start working on another feature/bugfix and for that, I have to create a new branch out of my development branch. I usually stash all the changes in feature01 and start working on a new branch. I don't like this solution that much as I can be working on the new branch for a day or so and I have to remember that there is something on the stash. Is there any localized version of stash for each branch or something of that sort so that I can move around between different WIP branches without having to stash a bunch of stuff and keeping track of them manually.
One solution I was thinking of was committing the local changes before checking out to a new branch and then later when the work is done on one of the WIP branch, I can squash some of the commits together with a more meaningful message rather than having a bunch of commits with not so helpful messages.
I would like to know if you guys know better solutions to this problem or if this problem is arising because my git workflow is not correct. I searched for solutions online but most people recommend stashing which I don't like much when the changes stay for a longer time in the stash.
Cheers.
Waqar
I'd suggest using a temporary commit :
# you have unfinished modifications to save before switching
git commit -am "temp - DO NOT PUSH"
git checkout other-branch
Then you can work on the other-branch, and when you're done, it's easy to undo the commit on previous-branch while keeping its contents
git checkout previous-branch
git reset HEAD^
Of course, it's easier when you have aliases
git config --global alias.ct 'commit -am "temp - DO NOT PUSH"'
git config --global alias.rs1 'reset HEAD^'
Then just
# to save uncommited changes ON the branch
git ct
# to "unravel" a temp commit
git rs1
Instead of stashing or doing a temporary commit, another solution is to use the git worktree feature to work in another folder (but still within the same repository).
A blog post on the subject: https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/
Git uses commit id's such us 521747298a3790fde1710f3aa2d03b55020575aa.
This hashcode keeps every changes in your code. if you want to change your branch without commit, its not logical according to git rules. Every changes must be marked with this hashcode. To extend you can choose which commits must be push.
I need to push a commit into two or more branches as the same time, using Git and Netbeans. Those branches are not local, but in BitBucket and shared with others developers.
The situation is this:
We have a branch which is used as a master (soon we will rebase it) and we are working on an another one. WHen I find a problem on the older branch, I'll switch to that and do the modification, then commit. I want the pushed code to be merged also with the newer branch.
How Can I do ?
There are a couple of ways to approach this, sounds to me like the simplest one in this case might be to use git cherry-pick to copy the commit from old-branch to new-branch locally on your machine, then push the revised new-branch back to Bitbucket.
The alternative way would be to create a PR on the server from old-branch to new-branch, whether or not this is viable will depend on what else is in old-branch that you don't want to copy across.
Thanks to all. I tryed a cherry-pick trough Netbeans git plugin and it worked perfectly. Now just have to guess if it add only committed lines or if it merges the entire files in the pick. I'll do some tests. I'll try also the pull request, sooner or later.
A file has been changed both locally and remotely.
I would expect to be able to solve the conflicts.
However when I execute a "git pull" with IntellilJ, I get the following message: "Git Pull Failed. Your local changes would be overwritten by merge. Commit, stash or revert them to proceed."
What I need to do to merge the local changes with the remote changes, then commit and push?
When you have changes that aren't committed to your own repo in any way, git doesn't have any way to know how you would want the pull to affect your files in the current state.
Another way to look at it is that the git client won't let you change files which are modified.
If you wish to discard your local changes, you can revert them. If you wish to commit them to the repo, then just commit. If you wish to keep the changes for later but they aren't going into the repo just now, you can stash them. You can read about these commands in the progit book or any other resource online, if you're not sure what they do. Good luck!
Do a commit on the stuff you have in your local workspace, then pull.
I am working under a Java project together with one of my collegues. Project sources are hosted in private GitHub repository. We are both using IntelliJ Idea 13 to work with it - commit changes and update project from Git repository. The whole IntelliJ Idea project is also in GIT repository.
The issue is that sometimes (approximately after a few commits/updates, can't say for sure since that happens randomly) Idea decides to remove ALL of my local changes and just take whatever comes with an update from Git. Under ALL I mean ALL - all new files, all changes, all resources - whatever was changed locally and not yet committed. Usually update goes well and even if something should be merged - Idea offers a merge dialog where issues can be resolved, so this is not about merging changes for sure.
It is also not an OS-related issue since we've been working on different platforms (at least Win XP/7/8, Ubuntu and Mac OS X) - that issue happens everywhere.
I have been looking for the solution of this issue for some time now and didn't find even a single thread about it, so I have decided to ask here - probably someone might give me some tips. Probably I don't know something about GIT since I didn't actually work with it a lot.
Since this case it pretty vague I am not sure which information I should add to the topic to clarify the situation.
Thanks a lot in advance!
P.S.
A wild guess - IntelliJ Idea has a workspace.xml file in its project files which represents user-related settings of work area plus some other stuff - it is also in GIT in our project and ocasionally gets committed with other changes, might that cause this issue?
My understanding of git add is that you're basically saying to your local git repo "Yes, I'm sure I want to make these changes."
My understanding of git commit is to actually save the changes to your local HEAD branch. At this point they are actually in version control, but are only local to your instance of git.
My understanding of git push is to propagate your saved (committed) changes to the master repo, so other developers (or perhaps a CI build) can pull them down for themselves.
If anything that I have said so far is wrong or is misleading, please begin by correcting me. Assuming I'm correct in my understandings, I originally had a package in my Java project that looked like this:
com.myapp.server.servlets
FizzServlet
BuzzServlet
But then I decided to refactor the names and of a few things, as well as both adding & deleting some new files/packages:
com.myapp.server.servlet
FizzesServlet
WidgetServlet
com.myapp.server.servlet.impl
FizzesServletImpl
WidgetServletImpl
Overall, I account for 5 changes to this directory:
Changed the name from "com.myapp.server.servlets" to "com.myapp.server.servlet"
Changed the name from "FizzServlet" to "FizzesServlet"
Deleted the BuzzServlet altogether
Added a new WidgetServlet
Added a new com.myapp.server.servlet.impl package with two child files
Do I have to do any sort of special command magic here, because I did so much refactoring, or can I just run something like git push * to push everything to GitHub? In the SVN Eclipse plugin, if I renamed a package or source file, and then tried committing that change, I would often lose the file altogether (locally) and have to restore from local history. Even then, I got burned far too many times to count and lost a lot of work. I'm hoping not to get the same experience with Git.
From the way you're very careful about pushing, your understanding of git push is not quite complete. push will literally only push your commits to your remote -- that means, it will copy the exact state that you saved in the commit(s) you have made since last pushing. In Git, every commit is a snapshot of all the files in a repository (it does in fact record all files, and not just the changes). So what you see locally after committing will be exactly what's copied onto the remote when pushing.
When you push, one of two things can happen:
The push succeeds, in which case all is well and the state of the remote mirrors the state of your local repo (to emphasize this, remember that git commits are identified by their SHA hash -- if the commit were different, so would the hash be)
The push gets rejected, because it is not fast forward. This happens when someone else has pushed commits onto your remote since your last pull/fetch, and it is the equivalent of the nasty and oft-feared conflict when trying to commit in SVN. However, your local state is not affected by this. You will have to resolve the conflict (a) dropping your commits and accepting the state of the remote (git reset is used for this) or by fetching from the remote and (b) merging your local changes, thereby creating a merge commit which will indicate the diverging and re-converging of your history, or alternatively (c) rebasing onto the remote, to produce linear history.
The conflict resolution case will take a bit more looking into, but the actions required are well-described in the Pro Git book (chapters Branching, Merging, Rebasing).
A conflict can only happen if someone else can push to your remote, or if you push to your remote from another computer. If you are working in a single-user single-computer scenario (at least for now), there will be no conflict when pushing.