While doing a push, if i put the wrong but valid arbitrary location that is not my remote master repo. Apart from upsetting a lot of people what other damage to the repo will it do? Is there a way to safeguard against this?
If you succeeded in pushing your branch, then I would assume that the branch did not yet exist there, and you simply created an unwanted/unneeded remote branch there. I suppose there is a slight chance that you somehow managed to fast-forward a branch by the same name in another repo, but this would be a real edge case, and not something I would expect to happen.
Of course, if a branch by the same name already existed then most likely your push would have been rejected. If the branch already existed on the other repo, then this is the case I would be more concerned with. Fortunately Git would likely block a mistaken push in this case.
Related
I am pretty new to Git and I am using sourcetree as a client.
I know that in Git two developers work on the same branch at a time since they have local copies of the remote branch.
So here is a scenario :
A and B are working on a branch feature/release1.0
A commits code to local branch.
Now B commits the code and pushes it to the remote branch as well.
Now A will have to push his changes as well as Pull changes made by B.
So what will A do in this case ?
In this case, A should pull B's changes down first, make sure everything works, commit, and push.
Generally we (my team) don't work quite like that.
When we have two developers working closely on a feature, we work on separate branches and merge into a shared feature branch.
Among the advantages of this is that you can commit and push on your own schedule, which means that you can make your code work without worrying about the other developer's changes and your code makes it to the server quicker. That is, it's somewhere other than your own machine, somewhere that's probably backed up.
A must git pull first (some merge may be needed) and than push the code.
If A try to push his code in the first place, git will tell that the remote and local branches have diverged and instruct the developer to pull the code first.
If you pay attention to git commit error messages (and git status messages) you will always know what to do.
As you said, A has to get the changes from B (git pull) before pushing her changes. It is likely she has to deal with some conflicts, which should be resolved locally before pushing the code.
Apart from that, you should probably reconsider your branch scheme to avoid this kind of conflicts. Would it be possible to work in different branches? For instance, by redefining the tasks, to be more fine-grained.
Moreover, it is weird, at least for me, the name or the branch feature/release-1.0. Looks like there are releases by features basis, os something like that. Take a look at http://nvie.com/posts/a-successful-git-branching-model/. See how the release branches are fed from the developing branch, and this one receives the commits from the features branches.
Hope it helps!
I made a pull request which was merged to a project. It so happens that the code needs a minor modification. How can I possibly change this with no access to the master project whatsoever? Am I out of luck and I have to do a new PR?
Thanks.
Yes, you should submit another pull request.
When using any of Git's "rewriting" commands like commit --amend or rebase it is important that you avoid changing shared commits.
In its Rebasing chapter, the Git Book says:
The Perils of Rebasing
Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:
Do not rebase commits that exist outside your repository.
If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
So, I'm new to Mercurial, and on my first try I screwed up.
Before pushing my data, I tried to merge with one branch (which I think was an old branch)
Instead of pushing it properly to change from "draft" to "public" I manually changed it from Tortoise by using the change phase from "draft" to "public"
I thought it meant that it would be placed in the repository, but when I went to the actual repository (on Bit Bucket) I couldn't find it.
So what happened, is I think I never made a push.
This is causing me an issue to make new changes, because when I tried committing other files, merging it with other branches and pushing it to the repository, i get the error:
searching for changes
remote has heads on branch 'branch one' that are not known locally: 62bf86f93d4f
abort: push creates new remote head 7edef5d2e2e5 on branch 'branch one'!
hint: pull and merge or see "hg help push" for details about pushing new heads
[command returned code 255 Thu May 27 14:43:44 2015]
So I think the solution would be to merge with the original draft (which is now public)
Thus my question: Is it possible to still merge and push a revision that was already deemed "public", even if I can't find it in the repository on bitbucket?
The phase of your commit (public vs. draft vs. secret) has no relevance for whether the commit can be merged. The difference between draft and public only affects whether the history involving the commit can be altered (e.g. via hg commit --amend or hg rebase). Public revisions are considered immutable, draft revisions can still be altered.
You can still merge and push. In theory, if you are positive that you didn't push the commit, you can also safely change the phase back to draft. However, that would be pointless [1], because pushing the merge will immediately make it public again [2].
[1] It can be useful if you use hg pull --rebase, but if you don't know what that does, you probably shouldn't use it.
[2] Unless you push to a non-publishing repository, but that's unlikely unless your group is using the evolve extension. If you don't know what a non-publishing repository or the evolve extension is, you don't need to know.
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I'm trying to identify the proper way of working with multiple branches on Gerrit that would match our workflow.
The way we work with branches right now is: we have master & feature branch. Master is the branch we want to polish and make it ready for release, while feature is obviously a field of intensive work. Now, in our particular case whenever somebody works on a bug fix, they:
create a change targeted for master branch
cherry pick it to the feature branch targeted change
once gerrit code review completes, submit both changes.
now the way i understand cherry-pick, it selects individual commit and merges it to the current change. if that is the case, i would expect to have no merge conflicts in the end, and indeed this workflow works perfectly with just GIT. Gerrit, however, most likely due to its nature (branches are not merged remotely the way these are locally and get a different sha tag) lists a tremendous number of conflicting files in the end.
Now, I resolved all these issues by applying merge strategy (ours on feature, theirs on master), but it does not feel right: if anything was not propagated, it just got discarded.
My question is: is there a safe workflow, similar to the above one, that would in the end produce a clean merge with gerrit?
I would say that it's better, in this case, to merge than to cherry pick.
A cherry pick adds the same changes but not the same commit. So while the source is the same on a cherry pick and merge the git tree is different. When the tree is different and you later do a merge git will think that the commit you previously cherry picked is missing and try to merge that change as well, even if the actual code is already there. That's probably why you get a lot of conflicts.
I would propose another way of working.
When you do normal work you develop on feature and push to Gerrit as normal.
When you do a patch (ie bug fix) on the stable production environment you do that directly on master (or local branches if you like but not on feature)
When the patch as been approved in Gerrit it get's merged into the real master and you can make a pull request to get that change to your local copy. Your version of master is now the same as Gerrits master
Now you would merge all new changes on master into feature. Make sure you do a rebase so that the patch ends up before anything you've already done on feature
Once it's time to deploy all new features you can merge feature into master, push to Gerrit (if you have permissions you can by pass gerrit by pushing directly to master instead of refs/for/master as these changes are already reviewed)
Once all changes are on Gerrits master you do a pull on your master and a merge into feature with rebase making feature a clean branch to work on. It's of course totally valid to have a new feature each release. Both work fine.
I'm a little confused, as this flow should work just fine. If other users submit changes before your bug fix is reviewed/verified/submitted, that could result in merge conflicts, but that should be rare.
If you:
Fix a bug on master
Push to review (creating change A in gerrit)
cherry-pick change A on top of the feature branch (resolving any conflicts from master to feature)
Push the cherry-picked change to review (creating change B)
Review/verify/submit changes A & B
Everything will work fine. The only way for merge conflicts to occur is if other users upload and submit changes between steps 1 and 5. Are you seeing different behavior? Can you provide more details?