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.
Related
Been using production/integration branches to manage code promo to production. Our integration branch is a stable integration environment that all feature branches are made from, and merges are reviewed by PR, and deployed via CI when approved and squashed+merged. Once integration is stable and we've tested it, we do another PR from integration to production. When this is approved and squashed+merged, CI takes over and deploys to the production env.
git checkout integration
git checkout -b feature
# do work
git add/commit etc
# create PR, squash+merge on github UI when reviewed
# CI sees new commit to integration, deploys to int env
My issue is with what these integration -> production PRs looks like when they are reviewed - even though (at times) I've done the following to get any commits already in production into integration:
git checkout integration
git pull
git pull origin production
git push
# create PR for integration merge into production
When I go look at the PR page on Github, the list of commits shows history going back to commits that are already represented in production. The "Files changed" list is very small, while the commit history goes back many PRs ago. I thought git pull origin production would remove this history and then only show the new commits coming from integration to production?
Am I missing some obvious way to maintain merge commits but also clean up the history when integration is merged into production? Could inconsistent merging/rebasing strategies cause this?
Some screenshots to show what is confusing - a PR that has a single file changed from a single commit, but the commit history goes back much further:
The single file change was the last commit in the list—why does the PR show commits that have already been merged previously? I thought Squashing and Merging (both into integration from feature branches and into master from integration would remove this commit history and make merges into master clean?
The green arrow represents the 1 file changed in this PR, and I thought the commit history (after a merge of production back into integration to clean the history, if any) would only have that one commit.
Is this a github display bug or am I missing some principle of how git maintains commit history across a long-running branch that gets merged into another long running branch? It's always a one-way merge, from integration into production branch, for CI to deploy the update.
Is it possible to close a pull request without merging it into the upstream branch?
I am using gitflow and so I want the developer who started the feature branch to finish the feature branch rather than reviewer to merge the feature branch.
Looks like this facility is available in github.
You can abandon the Pull Request, it will close it without merging:
Ok, So if you want to merge but not delete the feature branch, there is an option. Just uncheck the delete check box.
Now using gitflow, you can now finish the branch. Then git flow will delete the branch locally as well as remotely. And before deleting locally, it will merge changes from the feature branch to the develop locally.
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.
I am quite new with Gitlab and I'm having an issue for merging in Eclipse.
We're working as a team, and we all have development branches that we are trying to merge into a single one. Unfortunately, when I did my merge, I have done a stupid mistake. Instead of merging my development branch to the main one, I have merged the main one into my development branch.
I have reversed the commit/merge on gitlab, but now as I try to merge back my development branch into the main one on Eclipse, it seems like I am 9 commits ahead of this branch (described as the arrows on Eclipse here: ), so the potential merge would basically replace everything by my code, when I should actually have merge conflicts to solve.
I am not quite sure how to merge properly so that I get back these merge conflicts.
Here is a screenshot of my network:
The ['1'] commit in the network on the left branch (my branch) corresponds to the merge from Week6AllIssues to my dev branch (the wrong merge). The last commit on this left branch is me reversing the commit.
Thanks a lot for your help !
If you're not using the remote branch with anyone else, the following series of steps might help.
First, remove the superfluous commits from the local branch. It can be achieved with git reset --hard <the commit before you merged master into your branch> command (see this link on how to do this with Eclipse).
Now make the remote branch match your local branch. You can do this with git push --force command. In Eclipse, this command corresponds to configure push - enable "force update" option.
Now the superfluous commits are gone.
I am working on a project with some mates.
Yesterday I cloned the project with the intention to add a functionality.
I have 2 local branches that are develop (the main branch) and pageContent (my feature branch).
The problem I am currently encountering is when I edit something on my feature branch, it automatically edits it on my developp branch too (I did not commit anything).
I checked out on my developp branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
The branches seem to be auto-synchronised.
I checked out on my develop branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
This is how git works.
In the following diagram you can see the 3 states.
Git has three main states that your files can reside in.
They are all shared between your branches. but when you checkout branch you change the HEAD so you end up with the staging area && working directory shared between your repository even when you checkout branches.
Since you did not commit (i assume that what happened) when you switch branches you see the changes following you to your new branch.
If you don't want the changes to follow you you need to commit (or stash) your work before switching to the branch.
How to checkout different branch with clean working directory and stage area?
If you wish to checkout clean branch without any "leftovers" in your working directory and staging are you can create a new worktree which will result in shared view of your repository (all the content is shared) but with a different working directory and staging area.
From git v2.5
git worktree add <new_path>
Now do whatever you want in any of your branches. It will create 2 separate working folders separated from each other while pointing to the same repository.
Using wortree you don't have to do any clear or reset in order to remove all your staged and untracked content.
Here is demo of how to do it: