I'm using git flow.
We have develop branched from master, and I have feature/INF-824 branched from develop.
One of my coworkers has added a change to develop that's relevant to INF-824.
How can I merge his changes into my copy of develop, and see them in feature/INF-824?
Thanks!
You can cherry pick the change from the develop branch.
git cherry-pick <commit-ish>
Commit-ish would be the SHA1-ID of the commit you want in your feature branch.
The other option would be to use rebase on your feature branch
git rebase feature branch
This might be better solution as you'll be merging your feature back in develop anyway on finishing the feature branch.
Related
I am currently developing a branch flow based on GitFlow, I am in the stage of defining how the interaction between the hotfix branch and the develop branch will be done after a correction in production, although GitFlow recommends that a direct merge be done, I particularly want consider an intermediate branch through which to create a Pull Request and in this way peer review can be done, in addition to avoiding committing directly to the "release" and "develop" branch. The simplest way to do this is to use a feature branch, however it is not appropriate to use it.
Please does anyone have any suggestions for the definition of the name of this branch that I need? I'm considering using a "develop-integration" branch.
First, let's reiterate what Git Flow recommends for hotfix branches:
Create a branch for the hotfix, perhaps hotfix-number or hotfix/number, based on master (or main if you call it that instead).
Merge the hotfix branch into master when you deploy to Production.
Also merge hotfix into release if it exists, or develop if release doesn't exist, and now delete the hotfix branch.
For #1, the branch name of the hotfix doesn't actually matter. In Git branch names are simply to help us know what they are for, but you could call your hotfix branch fix-some-bug if you want to. This also translates to your last question:
...does anyone have any suggestions for the definition of the name of this branch that I need?
In the context of an in-between branch, perhaps even moreso than a hotfix branch, it really doesn't matter. In one of my repos where I use Git Flow, we named this in-between branch temp/merge-hotfix-into-develop since it only exists for a few minutes.
Note for #3 above about merging, after using Git Flow for a while, my preference, for both release and hotfix branches, after merging into master, is to then merge master into develop rather than the release or hotfix branch itself. This is slightly cleaner in the long run, but the end result state is identical. Therefore, since I do it this way, my actual branch name in this case would be temp/merge-master-into-develop.
That being said, I'd like to challenge your reasoning for this in the first place:
... although GitFlow recommends that a direct merge be done, I particularly want consider an intermediate branch through which to create a Pull Request and in this way peer review can be done, in addition to avoiding committing directly to the "release" and "develop" branch.
In Git Flow, anytime you are merging one shared branch into another, we can divide the merge into 2 categories:
The merge does not have conflicts.
The merge does have conflicts.
In scenario #1 (which hopefully is the most common scenario), there is nothing to be reviewed, so the PR should be basically automatic. In this case simply create a PR from hotfix (or master) to develop and complete it. You can do a sanity check first if you want to, but it should be extremely rare that it would fail at this point. If the sanity check fails, then you could resort to treating this like #2.
In scenario #2, this is when you need to create the in between branch as you mentioned. I always test the merge first, and if there are conflicts I'll create a branch, as mentioned above, like: temp/merge-release-into-develop or temp/merge-master-into-develop, resolve the conflicts myself (except in rare cases when I can't in which case I'll pull in other devs), and push out the branch and create the PR into, in this case, develop.
I've already deleted a local branch without deleting its upstream branch on a GitHub.
Is there a way to delete the remote branch in a GitAhead?
In Sourcetree you just right click on the remote branch and choose delete.
Unfortunately no, GitAhead doesn't have an easy way to push a delete except for the little convenience checkmark when you delete the local branch. You would have to resort to the command line or doing it on your remote host.
This is a major design flaw in Git (in my opinion). The branching concept in mercurial is much more sane (no detached heads, named branches, no ability to delete branches - at least not if it was published once).
think about it: it is a versioning control system. What you want is to preserve and document development history. Someone has created and published a branch for purpose. So even if git allows manipulation of the repository much more than mercurial (and here most abilities are disabled by default!), just do not use it. leave the branch! Its OK. Its the way it should be. Anyway, as git is lean here, its just a pointer (not a real named branch like in hg), it does not take much space.
I am looking to make a few customizations to the Memberful Wordpress plugin that will meld the plugin with my existing website just a bit better than it currently does in staging.
Ideally, the plugin would be maintained with Git, and I could make a branch with my customizations, and with each update that the Memberful team launches, I would rebase my branch onto the new master, test, and re-deploy.
Unfortunately, the Memberful Wordpress plugin is (and all other Wordpress plugins are?) maintained with Subversion.
Is there a way I can achieve my desired ends using Git? Or is it more advisable that I use Subversion for this part of development and learn to rebase in Subversion?
Edit: This guide is extremely helpful in figuring out how to do all of this.
This answer to a similar question shows the process for rebasing in Subversion. It goes as follows:
svn cp trunk feature
commits to feature & trunk
svn cp trunk feature-rebase
svn co feature-rebase
cd feature-rebase
svn merge feature
svn commit
svn rm feature
svn mv feature-rebase feature
(back on feature-rebase WC) svn switch feature
So, what I would do in this case is use Subversion for development (not desirable in my case) and keep my local, development trunk up-to-date with the remote trunk using svn update.
Preferred alternative
A preferred alternative that I found, which allows me to continue working in Git is by exploiting a robust set of commands that is included as a part of git-svn that allows bidirectional operations between a Subversion repository and Git.
I believe all I need to do (although I have not yet tested this) is git svn init a local development environment based on the remote trunk location (in my specific case, that is Memberful's Subversion repository and, whenever I need to "pull" changes from the remote repository, use git svn rebase.
I have a wordpress site that I am finally getting into git. Previously I was editing changes locally and uploading via ftp. I want to come up with a strategy to be able to do the following:
Update my git repository with any changes made on the ftp server (plugin updates etc). That I will then sync that down into my local copy
Push locally tested changes into git and then deploy via ftp (I know how to do this part)
I don't know the best way to approach 1 and I'm very new to using git (usually use svn).
Thanks
Using a conventional development workflow on Wordpress is challenging.
Because WP puts too much in the database, including site config, it makes syncing changes from one environment to the other a real pain.
We have a number of WP installs (against my better judgement) and organise our workflow like this.
You might lighten this process if you're not part of a dev team and are going alone.
Local Dev
codebase changes only. Including shortcode development and templating. This lives under a GIT workflow (branches, tags, etc). Plugin/framework updates are installed here, and tested before adding to the gitball.
Beta Live
All content is built here, with any code based changes being requested as needed. Testing is carried out here, responsive, UAT etc.
Code changes are pushed up via deployment scripts which trigger either a GIT pull, or by syncing files via ssh:rsync. heres a good resource on how to use git hooks for this.
Live
For live deployment, we use a WP database migration plugin to get content across, and the git repository to push tagged releases up to the live server. We also use the sync tool to pull down up to date copies of the database to our local dev machines.
I'm sure there are lots of other opinions on what's best, and how to implement them.
My opinion
The fact is is that WP is a bad choice for websites that require a lot of under the hood attention. It was never designed for this, and consequently is a real pain to force into a proper development cycle. If I must use a CMS, I generally use Drupal for sites that need more functionality, its a steeper learning curve, but more than worth it.
You could follow a git flow pattern. This consist of three main branches:
master
release
develop
Preform all of your development in the develop branch which you would build and test locally. Then when you are ready to test on a server merge your changes into the release branch for testing. When everything checks out you can then merge into your master branch. From here you can either manually ftp the files from the master branch like you have been or set up a deployment hook to automate deployment to your server when changes are detected.
As your project grows you can implement a couple of other branches to further maintain your build. You can base a new branch feature off of develop when you need to add a new feature then merge it back into develop following the flow back up again. As well as a hotfix branch to take care of any bugs "on the fly" straight off the master branch.
Here is a good example of the git flow pattern:
[http://nvie.com/posts/a-successful-git-branching-model/][1]
This article goes into a lot more detail about the git flow pattern and is an awesome resource!
Be sure that whenever you start a new development phase you merge from master to develop so you know you are starting with the most recent version of your project.
Does git flow avoid fast forward merges for better reporting?
While testing git flow I see not only the commits from my release branch on master & develop but also merge commits. I thought I'd only see release branch commits and then a fast-forward as git adjusted master & develop to point to the new commits.
As a very simple case, I expected no merge commit requirement since no other changes appeared between the time of release branch start and finish.
What drives the merge commit requirement or did I miss something?
Thanks
Peter
Scenario: Release Stabilization
Create release branch (git flow release start 100.0.0 develop)
Push for collaboration (git flow release publish 100.0.0) (it's just me, so I'm collaborating with myself)
make and commit 1 change on release/100.0.0
Finish release (git flow release finish)
RESULT
local develop +3 commits to remote
HEAD merge tag to develop e191707
HEAD -1 e0040cb merge from release branch
HEAD -2 e7cdc02 release branch change
local develop +3 commits to remote
HEAD merge tag to develop e191707
HEAD -1 e0040cb merge from release branch
HEAD -2 e7cdc02 release branch change
local master + 2 commit to remote
HEAD e0040cb merge commit
HEAD -1 e7cdc02 stabilization change
It seems that git flow uses git merge --no-ff as its default (see git flow considered harmful). I don't think that choice help improve understanding and creates unnecessary noise. I expect us to use git flow provided we can sort out when to use ff