Menu
Two programmers, A & B, are working on a project with a github hosted repo:
Branch master exists.
Programmer A creates devBranchA based on the latest master
master$ git checkout -b devBranchA
Programmer B creates devBranchB based on the latest master
master$ git checkout -b devBranchB
They decide to merge stable changes into master whenever possible.
The agreed workflow is:
[on devBranch]
git commit -m 'Stuff to make branch stable enough to merge'
git checkout master
git pull origin master
git merge devBranch [fix merge conflicts if any]
git checkout devBranch
git commit -m 'New cool stuff'
However, if there have been no commits to master since the last merge, it is then not possible to merge the devbranch back into master (unless a new dev branch was created, rather than the old one reused)
In this case, when Programmer B comes to merge his work into the master branch, it will not be the current intended master, but the state of master before the merge.
Is there a way to automatically force the master branch to update itself to the head of the dev branch on merge if there have been no interim commits?
What is the intended multi-user workflow when working with git and a centralised github repo? I feel as though I am not using git as it is intended to be used.
902
You can simply merge/rebase to reuse the branch which is the easiest possible scenario. Why would you even merge task 1 before moving onto task 2?
When you're done with a branch and it has been merged into master, delete it. A new branch can be made off of the most recent commit on the master branch. Also, while it is ok to hang onto branches after you've merged them into the master they will begin to pile up.
No, ideally you would rewind time, do the merge as it was back then (but correctly, this time), then reapply the F* changes and end up with a correct master . You can do it like this: git checkout missing-commits git checkout -b correct-merge git merge D # do it right, this time around!
You can undo a Git merge using the git reset –merge command. This command changes all files that are different between your current repository and a particular commit. There is no “git undo merge” command but the git reset command works well to undo a merge.
Check out git fetch;git rebase origin/master or git pull --rebase, both honor the order of the commits in the master repository because it rebases, sticking local commits on top. You don't care about the order of the local commits as much on local branches anyway because only you have them. Try it out, but use with care, e.g. duplicate a branch before rebasing until you're used to it.
In general, you're talking about git workflow, and I've found that there are two general workflows that you should get familiar with. Be aware that I'm talking from personal experience on how to minimize conflicts:
git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that.
git branch temp_branch // copy of the master
git checkout temp_branch
git add changedFiles;git commit changedFiles; // A change from november 2nd.
git log // Now your dev branch has a new commit on top of an otherwise old branch.
git log origin/master // You get a listing of the commits from the origin repository, the master branch.
Generally I use origin/master for development staging, with git tags standing for the commits that are made live releases.
Now here's where the problem occurs, and where the choice of workflow comes into play: let's say there's a commit that came from another dev repository up in master, e.g. a commit from october 15th. Maybe it was commited by another developer, maybe by yourself.
Your choices: Merge or rebase.
Introduces an extra commit, honors your local (unpushed) branched dev history over the canonical (origin/master) history, causes a little more potential for conflicts for others and other branches. Essentially you're saying "my commit order will be mixed with the master branch commit order" as opposed to reordering commit history.
git merge origin/master // merge commit introduced
... // Resolve any conflicts, and finalize the merge commit.
git checkout master;git rebase temp_branch // Move the changes to master.
git push origin/master // Pushing changes, including merge commit, to origin/master
At the end, commit history will look something like: August-October-November-MergeCommit
No extra commits, honors commits already in the canonical repository (origin/master) over local commits, conflicts that occur will generally occur on commits that the developer has not yet commited (and thus no-one else can account for).
git rebase origin/master //
... // Resolve any conflicts...
git rebase --continue or git rebase --abort
... // Resolve any conflicts...
git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master.
git push // Push all changes to the canonical repository.
Note: If you end up having to do more than two conflict resolutions, -then- it is a good time to git rebase --abort and fall back to doing a merge.
Try out the process, see if it makes sense for you! It takes some experimentation before you can really get tactics that work well for your development in git, I guess because there are so many more approaches once you get decentralized.
54
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
