开发者

git workflow incorporating many, but not all commits from many forks

开发者 https://www.devze.com 2022-12-19 17:51 出处:网络
I have a git repo. It has been forked several times and many independent commits are made on top of it. Everything normal, like what happens in many github hosted projects.

I have a git repo. It has been forked several times and many independent commits are made on top of it. Everything normal, like what happens in many github hosted projects.

Now, what exact workflow should I follow, if I want to see all that commits individually and apply the ones I like.

The workflow I followed, which is not the optimal is to create a branch of the name github-username and merge the changes into my master and un开发者_开发百科do any changes in the commit I dont need manually (there are not many, so it worked).

What I want is the ability to see all commits from different forks individually and cherry pick and apply them on top of my master.

What is the workflow to follow for that? And what gui (gitk?) enables me to see all different individual commits.

I realize that merge should be a primary part of the workflow and not cherry-pick as it creates a different commit (from git's point of view). Even rebasing other's changes on top of mine might not preserve the history on the graph to indicate that it is his commits I have rebased. So then, How do I ignore just a few commits from a lot of them?

I think github should have a "apply this commit on top of my master" thing in their graph after each commit node; so I can just pull it, after doing all that.


This is usually what you'd use remotes for. For each fork, you can add a new remote: git remote add <name> <url>. Then you can fetch all their remote commits: git fetch <name>. Then you can use any visualization tool you want on the remote branches. Just like you have origin/master, you'll have /master. From there a cherry-pick from a different remote is just as easy as a cherry-pick from a branch on origin.

The origin remote isn't a special case of a remote repo in any way. It just happens to be the default name of the remote repo that you cloned from originally. It's possible to rename it if you don't like the name origin.

In case you don't know, all the gui tools let you see more than just your current branch's history. When you start up something like tig, qgit, or gitk you just need to pass --all to make it show you every branch it knows about, local and remote.

0

精彩评论

暂无评论...
验证码 换一张
取 消