We started using GitHub as Source control in our project recently and we are using Feature branches to work on the features. Once we are done with our development, we merge it to the develop branch using pull request.
During the merge if there are conflicts, we resolve using the web editor. But during this process all the commits done on the file with conflicts get included as a part of the feature branch.
Does anyone know how can i avoid this and make sure the feature branch stays clean?
You should only merge the feature branch into the develop branch (not the other way around). Then resolve the conflicts right there in the develop branch itself.
git checkout develop
git merge feature-branch
resolve conflicts in develop
git push
Note: If you are not too comfortable with the conflict resolution process, then best to create a 'develop-merge' branch, then merge the feature branch into it before creating a cleaner pull request for merging the new 'develop-merge' into 'develop' branch.
This way the develop branch will include all the features at the same time the feature branch won't be convoluted.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
I am trying to create a new feature branch using Eclipse Egit Git flow and then merge this with develop branch after things are done.
Issue: The feature branch does not get deleted after finish work flow is done.
Using GIT Bash - when I create a new feature and finish and commit it. Everything works as expected. Codes are merged with develop branch and then the feature branch is deleted.
Using Eclipse - I create a new feature, finish it and commit. The feature branch is getting committed to the git lab server.(No issues here) I also tried to merge the feature branch to develop and commit. The changes are committed to the server - No issues there. But the feature branch still exists on my local. According to normal git flow (bash flow), the feature branch is deleted when it is finished.
Is this a abnormal behavior with Eclipse git flow? I tried to uncheck this box, that should delete my feature branch. but it didn't happen.
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.
Our current stash repository has a Master and Develop branch.
Anytime if a developer is working on a story a developer creates a branch and once the coding is done a pull request is raised to merge to develop.
So far it has been good but when two developers are working on different feature branches on a same Repository if a developer merges his changes to develop and other one is still working on, there are issues like merge conflicts and we don't want the two different feature branches to be released together.
I know this is not an issue but we want to avoid release multiple feature branches at a time.
Any thoughts on this on what are the best practices.
I would suggest to create tags after you have merge to "develop" branch. There is no harm if you wish to release code from "master" branch using tags as well.
Honestly speaking there aren't any hard lines drawn on how you wish to release your code from Git hosted repos?
You may like to follow this sequence
rebase the feature brnach of second dev from develop branch to get changes of dev1 and avoid merge conflicts
git checkout feature_branch2
git rebase develop
merge feature-branch2 to develop branch
git checkout develop
git merge feature_branch2
tag the version you wish to release
git checkout provide_version_you_wish_to_release
git tag tag_name
The best practice is that the 2nd developer should first rebase his feature branch from "develop" branch and then merge his changes back to "develop" branch by creating a pull request.
If you don't wish to release changes from two feature branches simultaneously, you can create tags on the "develop" branch after a merge is successful and release code using these tags.
Hope this helps!
We have a dev branch in the team. I want to remove HEAD~9 commit from the dev branch as it was an accidental merge from a feature branch. I don't want to rewrite history as it might lead to problems with working copies of other developers. What other alternatives do I have?
One alternative that I thought is to branch off from dev, remove the commit from that branch, and then merge the new branch to dev. Can this lead to any problem later?