I have a git repository and two branches master and st (branched from master). I want to rebase st onto master. However, master has been massively rewritten by somebody else, to be frank I'm not sure why, but we were prompted to fetch the new master and reset --hard our private branches to it.
If I try git-rebase the listing of non-trivially conflicted files that need manual merges span over two screen pages.
I know that the actual changes are not that much. For one, the st branch only touched a handful of files (not more than ten, I'd guess).
Besides rebasing I tried to create a patch and apply it, but there are some conflicts as well, which I have no clue how to resolve.
The solution appears to be mind-bogglingly easy, as suggested by this answer, you can simply do
git am -3 changes.patch
if changes.patch is the full patch file.
Related
I'm working on feature branches that can have over a hundred commits over the course of a week or two. I've expected to get daily marks on my contribution graph for these daily commits once my pull request is accepted, but when that pull request gets "Squashed and merged", it looks like it just shows up as a single commit on the contribution graph.
Is this the intended behavior, or are my commits missing for a different reason?
Yes, this is the intended behavior. You only got one commit merged. That's the point of squash and merge.
I do not recommend squash merges. It takes all the carefully considered commit history about how the branch was developed and mashes it into a convenient but homogeneous paste.
I'm working on feature branches that can have over a hundred commits over the course of a week or two.
I would say this is the real problem. Feature branches should not regularly have over a hundred commits. Your features are too
big, or you're making a lot of commits to fix previous commits, or you have a lot of incidental merge commits from updating your branch, or all of the above.
Update your branch using rebase instead of merge. git rebase main rewrites your branch as if it were written on top of the latest version of main all along. This removes merge commits which say nothing but "I updated my branch" and makes it easier to see what work has been done on the branch. You can change git pull to do a rebase instead of a merge with git pull --rebase and by default by setting pull.rebase. See git-config and Git Branching - Rebasing.
Break up large features into a series of smaller features. This is a skill beyond the scope of this answer, but often a big change can be broken down into a series of smaller refactorings.
Eliminate incidental fixup commits. If you need to fix something in the previous commit, instead of making a new commit "amend" your changes to the previous one with git commit --amend.
For a general cleanup, do an interactive rebase and squash your incidental commits individually. Use fixup.
$ git rebase -i master
pick abcd1234 feature: do that thing
fixup 1234dcba whoops, had a typo in that thing
fixup b33fdead docs: document that thing
fixup afdcefff test: test that thing
fixup deadb33f fix that thing
pick efga1389 feature: did another thing
You had six commits, but you only really did two things. Now you will have just two commits for doing two things.
Using these techniques you can bring your PRs down to a handful of well thought out commits, each conveying important information to the reviewer and future developers wondering why the code was written that way.
See Rewriting History for more.
Yes, they show up as a single commit. That's because GitHub only counts commits that end up on the default branch, and when you squash a PR, you end up with one commit on the default branch.
I personally don't worry about my contribution graph, so this doesn't matter to me. However, I also don't use squash and merge, since I write nice, bisectable commits with good commit messages, and squash and merge destroys that. If it's important to you not to reduce the work that a contributor has made down to a single commit, then you would need a merge strategy whose goal isn't explicitly to destroy history.
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!
There is a library with a branch named dev which I created a fork of here. I then made a commit to my fork so that it would better suit my needs, and I intend to make further commits in the future. However, as the library is still in development I would also like my fork to stay up to date with the changed made in the original dev branch so that it has all of the latest bugfixes and such. Is it possible to sync the two branches while keeping my personal changes?
Edit:
I've looked at the possible duplicate and it seems like an appropriate answer but I just want to clear up one thing before I accept it - I need to sync to just the dev branch and not the whole repo, so would I do git rebase upstream/dev? What does git rebase upstream/master even do?
You'll want to periodically rebase your fork. Alternatively, you could merge the changes in if you'd like to preserve the history.
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.
I'm trying to figure out how to fix a merge problem me and my team are facing. I'm working on this project at school, and my team has made a lot of progress, but one of the team members who didn't know what he was doing force merges his code into the master branch. His branch is like 2 days old and we've already implemented a lot of new functionality since time, his branch is probably 20 or so commits away from head. I've tried rolling back to a stable master branch but his branch is intermingled with the stable so I can't seem to retrieve the stable back. Any suggestions? we are fairly new to git, but that person had no idea what was going on and just force merged his code without resolving the commits.
Go and sit on his computer.
Type git reflog, it will show you the full commit history (as well as other things). Find out the last good commit id , check it out git checkout SHA-1. create branch at this point and commit it back again. Once you are on the right commit your repository will "get back" to the last good place.
Another option is to perform a git bisect and to find out what is the bad commit.
Click here for blog about reflog
Click here for blog about bisect
Good luck.