#Upstream 逆行人生 | Explore Tumblr Posts and Blogs

philtravel · 1 year

Text

百胜滩可做的九件事 9 Things To Do In Pagsanjan, Philippines: Local Culture And Nature - Updated 2023

9 Things To Do In Pagsanjan, Philippines: Local Culture And Nature - Updated 2023

拉古纳省的百胜滩镇被称为该省的旅游之都。其主要景点是百胜滩瀑布，该国最著名的瀑布之一。据史书记载，早在西班牙时期，百胜滩瀑布的美丽就已为人们所欣赏。该镇本身也是一个拥有丰富历史和遗产的小镇，已有近350年的历史。百胜滩不仅有瀑布，我们的百胜滩 9 项热门景点还将向您展示这座小镇还有哪些值得探索的地方 The town of Pagsanjan in the province of Laguna is dubbed as the Tourist Capital of the province. Its main attraction is Pagsanjan Falls, one of the most well-known waterfalls in the country. According to history books, the beauty of Pagsanjan Falls was already being appreciated as far back as the Spanish period. The town itself is also a town with a rich history and heritage, being almost 350 years old. There is more to Pagsanjan than just the falls and our top 9 things to do in Pagsanjan will show you what else you can discover about the town.

将激流射向百胜滩瀑布瀑布自古就有名，分为三滴瀑布或三层瀑布。雄伟的瀑布的水源来自百胜滩河（当地称为 Bumbungan 河）。虽然瀑布本身位于附近的卡文蒂镇，但游客进入瀑布的最佳方式是通过百胜滩。当地人将前往百胜滩的乘船之旅称为“射击急流”，两名熟练且经过认证的船夫乘坐木制或玻璃纤维独木舟逆流而上，直到到达瀑布。返回城镇的乘船之旅是更惊心动魄的顺流而下，穿过十四个急流。每艘船通常最多可容纳三人，旅游费用包括救生衣的使用、保险和入场费。

地址: Pagsanjan-Cavinti, 拉古纳价格：每人 25 至 30 美元：包括往返乘船、救生衣使用、保险、入场费。营业时间：上午 8 点至下午 3 点。每天。但在雨季，这取决于天气，因为大雨会让旅行变得太危险。持续时间：大约需要 4 小时。交通：请向市旅游局寻求帮助安排旅游。当地的三轮车可以带您前往划船站。联系方式: +63 495013544

Shoot the rapids to Pagsanjan Falls

Famous since early times, the falls are classified as a three-drop waterfall or a waterfall with three tiers. The majestic falls is fed by water coming from Pagsanjan River (locally known as Bumbungan River). Although the falls itself is located in the nearby town of Cavinti, the best way for visitors to access it is through Pagsanjan. Locals call the boat trip to Pagsanjan “Shooting the Rapids” which involves two skilled and accredited boatmen paddling upstream on a wooden or fiberglass canoe until you reach the falls. The return boat trip to town is the more thrilling downstream ride, through fourteen rapids. Each boat can usually accommodate up to three people and the tour fee includes use of life vests, insurance, and entrance fees.

Address: Pagsanjan-Cavinti, Laguna Price: from 25 to 30 USD per person: inclusive of round-trip boat ride, use of life vests, insurance, entrance fees. Opening Hours: 8am - 3pm. Everyday. But during rainy season, this is dependent on the weather as the strong rains will make the trip too dangerous. Duration: around 4 hours required. Access: Ask the Municipal Tourism Office for help in arranging the tours. Local tricycles can take you to the boating station. Contact: +63 495013544

勇闯瀑布，进入魔鬼洞当到达瀑布的第三处瀑布和瀑布脚下的水池时，你需要问问自己是否有足够的勇气进入魔鬼洞。它实际上是瀑布后面的洞穴，你可以乘坐船夫拉的竹筏到达这里。当你穿过它时，你会感受到大量的水如雨点般落到你的头上和背部的压力。有人将其比作背部按摩。洞穴本身很黑暗，但您可以尝试一下洞穴如何回响它接收到的任何声音。

地址: Pagsanjan-Cavinti, 拉古纳价格：5 美元起，作为给船夫的小费；这不属于标准乘船游览费用的一部分营业时间：上午 8 点至下午 3 点。每天。持续时间：大约需要 1 小时。

Brave the falls and enter Devil's Cave Once you reach the third drop of the falls and the pool at the foot of the falls, you need to ask yourself if you are brave enough to enter Devil’s Cave. It is actually the cave behind the falls and you can reach this by riding a bamboo raft that is pulled by the boatmen. You will feel the pressure of tons of water raining down on your head and back as you go through it. Some liken it to having a back massage. The cave itself is dark but you can try out how the cavern echoes any sound it picks up.

Devil's Cave Address: Pagsanjan-Cavinti, Laguna Price: from 5 USD as a tip to your boatman; this is not part of the standard boat tour fee Opening Hours: 8am - 3pm. Everyday. Duration: around 1 hour required.

探索百胜滩的遗产：Arco Real 和市政厅从城镇的一些建筑中可以看出百胜滩丰富的历史。例如，Arco Real 是历史悠久的城门，建于 1878 年，于 1880 年竣工。这是镇上的人们对瓜达卢佩圣母的感谢之情，根据当地传说，她用她的名字标记了确切的位置剑抵挡一群强盗。直到今天，大门仍矗立在黎刹街，该镇的主要道路之一。拱门顶部有西班牙皇家徽章和两只卡斯蒂利亚狮子，与最初的设计相同。

另一个历史名胜是位于黎刹街的市政厅大楼。目前它是当地政府所在地，但这座建筑有着悠久的历史。它建于 1850 年代，最初是西班牙人建立的法庭所在地。此后，它成为第一所公立小学，也是第一所公立高中。菲律宾革命期间，这里成为革命力量的总部。该建筑带有历史标记，标志着它是一个重要的历史遗址。

地址: JP Rizal Street, Pagsanjan, Laguna 价格：无入场费开放时间: Arco Real - 全天候；市政厅 - 上午 8 点至下午 5 点。周末和公众假期休息。持续时间：大约需要 1 小时。交通：位于 Rizal 街；这两种结构都很难被忽视。

Explore Pagsanjan's heritage: Arco Real and the Municipal Hall

Pagsanjan’s rich history can be seen in some of the town’s architecture. The Arco Real for example, is the historic town gate which was built in 1878 and completed in 1880. It is an expression of thanks from the people of the town to Our Lady of Guadalupe, who according to local lore marked the exact spot with her sword to ward off a group of bandits. To this day, the gate stands on Rizal Street, one of the town’s main roads. The Royal coat of arms of Spain with two Castilian lions are found on top of the arch, as it was originally designed.

Another place of historic interest is the Municipal Hall Building also on Rizal Street. Currently it houses the seat of government in the locality, but this building has a lot of history. It was built in the 1850s and first housed the Tribunal Court established by the Spaniards. After which it housed the first public elementary school, and also the first public high school. During the Philippine revolution, it became headquarters of revolutionary forces. The building bears a historical marker marking it as an important historic site.

Address: J.P. Rizal Street, Pagsanjan, Laguna Price: no admission fee Opening Hours: Arco Real - all hours; Municipal Hall - 8am - 5pm. Closed on weekends and public holidays. Duration: around 1 hour required. Access: Find yourself on Rizal Street; both structures are hard to miss.

探索百胜滩的遗产：瓜达卢佩圣母教堂资料来源：维基共享资源用户 Carlo Joseph MM拍摄的照片..在CC BY-SA 4.0 下使用该教堂是百胜滩镇唯一的罗马天主教堂。与西班牙殖民者建立的许多教堂一样，瓜达卢佩圣母教堂已有三个多世纪的历史。2012年，它被指定为瓜达卢佩圣母教区圣地，供奉着两尊女主保圣像，其主教堂位于墨西哥城，记录了圣母像。教堂的外观为文艺复兴早期风格，有一座三层高的钟楼。旁边的小教堂还设有一个小型教堂文物博物馆。

瓜达卢佩圣母教堂地址: JP Rizal Street, Pagsanjan, Laguna 价格：无入场费开放时间：弥撒时间可能会发生变化。查看教会的 Facebook 页面。持续时间：大约需要 1 小时。交通：如果您位于百胜滩镇中心，步行不远便可抵达教堂。联系方式: +63 495014121 Facebook：瓜达卢佩圣母教堂

Explore Pagsanjan's Heritage: Our Lady of Guadalupe Church Facade of Pagsanjan Church Source: Photo by Wikimedia Commons user Carlo Joseph M. M… used under CC BY-SA 4.0 The church is the only Roman Catholic Church in the town of Pagsanjan. Like many churches established by the Spanish colonizers, Our Lady of Guadalupe is more than three centuries old. It was designated as the Diocesan Shrine of Our Lady of Guadalupe in 2012, and it holds two sacred images of the patroness, whose main basilica is found in Mexico City, where images of the Blessed Virgin were recorded. The church’s facade is of early Renaissance style and it features a three-story high bell tower. A small chapel on the side also features a mini-museum of church relics.

Our Lady of Guadalupe Church Address: J.P. Rizal Street, Pagsanjan, Laguna Price: no admission fee Opening Hours: Mass times may change. Check the Church’s Facebook page. Duration: around 1 hour required. Access: If you are in the town center of Pagsanjan, the church is just a short walk. Contact: +63 495014121 Facebook: Our Lady of Guadalupe Church

品尝当地美食：在 Calle Arco 用餐正如许多美食博客和其他评论中提到的那样，Calle Arco 是镇上推荐的美食地点之一。餐厅位于一栋古老的西班牙风格房屋内，该房屋以前属于贾丁家族。它被改建为阿科街酒店及餐厅。业主之一是贾丁家族的后裔。一楼除了餐厅外，还设有一间咖啡厅和两间供客人使用的房间。由于业主并没有对老屋的内部进行太大的改造，所以食客们仍然感觉像是在祖屋里用餐。餐厅供应家庭风格的菲律宾菜肴。他们最畅销的是 Sinigang na Baka（酸汤牛肉）、大蒜鸡和脆皮帕塔（油炸猪肘）。这是一个很受欢迎的地方，所以建议你早点去或者预约。

阿科街餐厅地址: 57 JP Rizal Street, Pagsanjan, Laguna 价格：每人 6 美元起，全餐（三道主菜、一道蔬菜和米饭）营业时间：上午 10 点至晚上 10 点。每天。交通：如果您在市中心，您可以步行至Calle Arco。它与教堂位于同一条街上。联系方式：+63 495014135 脸书：Calle Arco

Try local food: dine at Calle Arco

Calle Arco is one of the recommended food spots in town, as mentioned in many food blogs and other reviews. The restaurant is housed in an old Spanish-style house that was previously owned by the Jardin family. It was converted into the Calle Arco Hotel and Restaurant. A descendant of the Jardin family is one of the owners. Aside from the restaurant on the first floor, there is also a cafe and two rooms for guests. Because the owners did not change the interiors of the old house that much, diners still feel as if they are enjoying a meal in an ancestral house. The restaurant serves Filipino dishes family style. Their best seller is the Sinigang na Baka (Beef in Sour Broth), Garlic Chicken and Crispy Pata (Deep Fried Pork Knuckles). It’s a popular place so it is recommended you go early or make a reservation.

Calle Arco Restaurant Address: 57 J.P. Rizal Street, Pagsanjan, Laguna Price: from 6 USD per person for a full meal (three main courses, 1 vegetable dish and rice) Opening Hours: 10am - 10pm. Everyday. Access: If you are in the town center, you can walk to Calle Arco. It is located on the same street as the Church. Contact: +63 495014135 Facebook: Calle Arco

TRIP101 当地专家的提示这家餐厅不太受欢迎但一定要尝的是他们的 pako（蕨类植物）沙拉。新鲜的 pako 搭配 kesong puti（白奶酪）——这是拉古纳周围常见的奶酪。搭配蜂蜜醋酱，这款沙拉会让您想在家里重新制作这道菜——您可以！Pako 和 kesong puti 通常在城镇中出售，因此您可以将拉古纳的一块带回家。

TIP FROM TRIP101 LOCAL EXPERT A less popular but definite must-try at this restaurant is their pako (fern) salad. Fresh pako is served with kesong puti (white cheese)--which is a common cheese around Laguna. With a honey-vinegar dressing, this salad will leave you wanting to re-create the dish at home--and you can! Pako and kesong puti are typically peddled around in the towns so you can take a piece of Laguna home.

6.百胜滩周边：萨尔瓦多普韦布��自然公园如果您预算有限，并且不想乘船前往瀑布，可以通过附近拉古纳卡文蒂镇的萨尔瓦多普韦布洛自然公园来完成。该公园成立于 2007 年，位于卡文蒂 (Cavinti) 的蒂巴蒂布 (Tibatib) 村。通过这条路线，游客可以通过金属梯子徒步和绳索下降，从上方接近瀑布。您唯一需要做的乘船活动是当您到达瀑布并乘木筏前往魔鬼洞时。速降分为两个部分，中间需要徒步，通常需要 1.5 至 2 小时才能到达瀑布。请注意，您必须以与进来时相同的方式退出，因此这意味着攀爬和绳降回到公园。

萨尔瓦多普韦布洛自然公园地址: Tibatib, Cavinti, 拉古纳价格：徒步和速降套餐每人 6 美元起，含漂流筏营业时间：上午 7 点至下午 5 点。每天。持续时间：大约需要 3 小时。交通：从百胜滩 (Pagsanjan) 镇出发，驾车前往卡文蒂 (Cavinti) 镇。从那里乘坐三轮车前往公园。联系方式：[email protected]

Around Pagsanjan: Pueblo El Salvador Nature Park If you are on a budget and you want to go to the falls without the boat ride, it can be done through the Pueblo El Salvador Nature Park in the nearby town of Cavinti, Laguna. The park was established in 2007, in the village of Tibatib, Cavinti. Through this route, visitors will approach the falls from above, through trekking and rappelling via metal ladders. The only boat ride you will need to do is when you reach the falls and ride the raft to Devil’s Cave. There are two sections for rappelling, with treks in between and it usually takes between 1.5 to 2 hours to reach the falls. Take note that you will have to exit the same way as you came in, so it means climbing and rappelling back up to the park.

Pueblo El Salvador Nature Park Address: Tibatib, Cavinti, Laguna Price: from 6 USD admission fee per person for the trekking and rappelling package inclusive of raft ride Opening Hours: 7am - 5pm. Everyday. Duration: around 3 hours required. Access: From Pagsanjan town, drive to Cavinti town proper. From there, take a tricycle to the park. Contact: [email protected]

添加提示

百胜滩周边：Bumbungan 生态公园 89Tibatib Poblacion, 卡文蒂, Laguna 19 来源：维基共享资源用户 Judgefloro在CC0 下使用的照片 Bumbungan 生态公园与萨尔瓦多普韦布洛位于同一个村庄。在卡文蒂旅游局的赞助下，这个小公园在 Bumbungan 河上有一个有趣的人造瀑布。该公园位于河流筑坝并修建溢洪道的地区附近。溢洪道变成了伦班-卡里拉亚-卡文蒂路沿线的一座湿桥，但当另一座桥梁建成后，溢洪道附近的区域被改造成一个生态公园，设有野餐小屋和浴室设施。游客可以在溢流区涉水或沐浴。

文邦安生态公园地址: Tibatib, Cavinti, 拉古纳价格：白天环境费 0.25 美元起，野餐小屋 3 美元营业时间：上午 8 点至晚上 8 点。每天。持续时间：大约需要 2 小时。交通：从卡文蒂镇乘坐三轮车。联系方式: +63 9055174371

Around Pagsanjan: Bumbungan Eco Park 89Tibatib Poblacion, Cavinti, Laguna 19 Source: Photo by Wikimedia Commons user Judgefloro used under CC0 Bumbungan Eco Park is located in the same village as Pueblo El Salvador. Under the auspices of the Cavinti Tourism Office, this small park features an interesting man-made falls on Bumbungan River. The park is found near the area where the river was dammed and a spillway was created. The spillway became a wet bridge along the Lumban-Caliraya-Cavinti Road, but when another bridge was constructed, the area near the spillway was converted to an eco-park with picnic huts and bathroom facilities. Visitors can wade or bath at the overflow area.

Bumbungan Eco Park Address: Tibatib, Cavinti, Laguna Price: from 0.25 USD environmetal fee during the daytime, 3 USD for a picnic hut Opening Hours: 8am - 8pm. Everday. Duration: around 2 hours required. Access: Take a tricycle from Cavinti town proper. Contact: +63 9055174371

8.百胜滩周边：Kalakal-Pandan Sambalilo 编织中心如果您喜欢购买当地产品，那么这里就是您的最佳选择。纺织中心位于拉古纳的卡文蒂，在您到达镇中心之前的一个有顶棚的篮球场下。该工厂由当地一家合作社经营，有女织工将香兰叶制作成夏季帽子、袋子和垫子。如果您想观看编织者的活动，最好与卡文蒂旅游局安排。您将一睹班兰叶从原材料到最终产品的加工过程。您也可以在中心购买成品。

卡拉卡尔-潘丹桑巴利罗编织中心地址: 有盖篮球场，卡文蒂，拉古纳价格：纯色帽子 0.75 美元起，彩色帽子 1 美元起，多色帽子 1.5 美元起。营业时间：上午 8 点至下午 5 点。鼓励每天但提前安排。持续时间：大约需要 2 小时。交通：从市区乘坐三轮车到市中心。

Around Pagsanjan: Kalakal-Pandan Sambalilo Weaving Center If shopping for local products is your thing, this is the place for you. The weaving center can be found in Cavinti, Laguna, under a covered basketball court right before you reach the town center. Operated by a local cooperative, it has women weavers who make pandan leaves into summer hats, bags and mats. If you want to catch some of the weavers in action, it is best that you arrange it with the Cavinti Tourism Office. You will catch a glimpse of the pandan leaves as they are processed from raw materials to the final product. You may also buy finished products at the center.

Kalakal-Pandan Sambalilo Weaving Center Address: Covered Basketball Court, Cavinti, Laguna Price: from 0.75 USD for plain colored hats, 1 USD for colored hats, and 1.5 USD for multi-colored hats. Opening Hours: 8am - 5pm. Everyday but prior arrangement is encouraged. Duration: around 2 hours required. Access: Take a tricycle to the center from the town proper.

9.百胜滩周边：Caliraya湖附近的日本花园

日本花园之所以得名，是因为它是日本政府在1970年代为纪念第二次世界大战中阵亡的日本士兵而修建的纪念公园。公园内有一座纪念神社，日本人通常在此供奉和祈祷。士兵。据报道，该花园占地 11 公顷（27.2 英亩），位于卡文蒂镇 Caliraya 湖旁边。只需花费不到 1 美元，您就可以在公园里漫步一整天，在众多野餐小屋中野餐，然后爬上一段楼梯欣赏卡里拉亚湖 (Caliraya Lake) 的壮丽景色。

日本花园地址: Talaongan, Cavinti, 拉古纳价格： 0.50 美元入场费起营业时间：上午 7 点至下午 5 点。每天。交通：公共吉普车没有前往 Caliraya Lake 的固定路线，因此主要通过私家车或车辆前往。

TRIP101 的提示在前往日本花园的途中，一定要参观卡里拉亚湖 (Caliraya Lake) 周围的景点。这个大型人造湖沿岸的青翠道路实际上非常适合风景优美的驾车，尤其是在日落时分。如果您有时间，可以在湖岸稍作停留，沿着微红色的粘土漫步。休息片刻，欣赏卡里拉亚湖 (Caliraya Lake) 的自然风光。湖周围有很多度假村，如果您想在拉古纳的这个地区停留，您可以在那里享受划船、皮划艇、摩托艇和高空滑索等水上活动。

Around Pagsanjan: Japanese Garden near Caliraya Lake The Japanese Garden is so named because it is a memorial park built by the Japanese government in the 1970s in memory of the Japanese soldiers who died during World War 2. There is a memorial shrine in the park where Japanese usually make offerings and prayers for the soldiers. The garden reportedly occupies 11 hectares (27.2 acres) of land located next to Caliraya Lake in the town of Cavinti. For less than 1 USD, you can spend the day strolling around the park, having a picnic in one of the many picnic huts and go up a flight of stairs to see a magnificent view of Caliraya Lake.

Japanese Garden Address: Talaongan, Cavinti, Laguna Price: from 0.50 USD admission fee Opening Hours: 7am - 5pm. Everyday. Access: Public jeepneys do not have a regular route that goes to Caliraya Lake, so access is mainly via private car or vehicle.

TIP FROM TRIP101 LOC On your way to the Japanese Garden, be sure to take in the sights around Caliraya Lake. The verdant roads along this large man-made lake actually make for scenic drives, especially by sundown. If you've got time, make a stopover at the lakeshore and walk along the reddish clay soil. Have a breather while appreciating Caliraya Lake's natural splendor. There are loads of resorts around the lake where you can enjoy water activities such as boating, kayaking, jet ski riding, and zip lining, among others, should you fancy a stay in this part of Laguna.

#Pagsanjan

0 notes

tak4hir0 · 5 years

Link

この記事はGithubで3万スター⭐以上を集めた人気リポジトリ git-flight-rules の翻訳です。 Git はエンジニアが毎日何十回も使うコマンドであるにも関わらず、難しいツールです。コマンドを間違えて、元に戻そうとあれこれ試しているうちにもっと悲惨な状況になり、復旧できなくなった経験が誰でも一度はあるのではないでしょうか。 Git でトラブルに見舞われてもこの Git フライトルールがあれば安心です！このガイドで対処策が必ず見つかります。落ち着いてガイドの手順に従えばトラブルから脱出できます。毎日Git を使う仕事を何年もしていますが、今でも困ることがよくあります。そういう時は git flight rules をすぐに参照していました。本家に日本語版がなかったので、仕方がなくずっと母語ではない英語のバージョンを読んでいました。塵も積もれば山となるで結構な時間をロスしていたと思います。読者の皆さんには Git で困って欲しくない、母語でこの素晴らしい Git フライトルールを読んで、git の操作ミスで苦労して書いたコードを吹き飛ばして欲しくないという思いから、この長い長いガイドを翻訳しました。 Git 初心者からベテランまでぜひ手元に置いておいて下さい。 🌍原著英語版 ※ この記事は Attribution-ShareAlike 4.0 International ライセンスで配布します。目次問題が発生した場合の対処方法についての、宇宙飛行士のためのガイドです。今の場合、Git を使用しているプログラマのためのガイドです。フライトルールは苦労して手に入れた知識体系をリスト化してマニュアルにしたものです。「もし X が発生したら、なぜ、なにをやるか」の手順が書かれています。基本的に、これらは非常に詳細なシナリオ固有の標準的な操作手順です。 [...] マーキュリー計画の地上チームが1960年代初頭に「学び」を最初に集め始めて以来、NASAはエンジンの故障から潰されたハッチまで、ミス、災害、そして解決策の概要をリスト化してきました。 — Chris Hadfield, An Astronaut's Guide to Life. この文書の表記規則を分かりやすくするために、この文書のすべての例で、現在のブランチとステージングした変更があるかを示すためにカスタマイズしたbashプロンプトを使用しています。ブランチは括弧で囲まれ、ブランチ名の横の*はステージングした変更を示します。すべてのコマンドは少なくともgitのバージョン2.13.0から動くはずです。ローカルのgitのバージョンを更新するにはgitのウェブサイトを見てください。既存のディレクトリをGitリポジトリとして初期化するには： (my-folder) $ git init リモートリポジトリをクローン（コピー）するには、リポジトリのURLをコピーして、次のコマンドを実行します。 $ git clone [url] これにより、リモートリポジトリと同じ名前のフォルダに保存されます。複製元のリモートサーバーに接続していることを確認して下さい（ほとんどの場合、インターネットに接続していることを確認すれば大丈夫です）。デフォルトのリポジトリ名と異なる名前のフォルダに複製するには、次の手順を実行します。 $ git clone [url] name-of-new-folder いくつかの問題が考えられます。間違ったリポジトリを複製した場合は、 git cloneを実行した後に作成されたディレクトリを削除し、正しいリポジトリをクローンしてください。既存のローカルリポジトリの origin として間違ったリポジトリを設定した場合は、次のコマンドを実行して origin の url を変更します。 $ git remote set-url origin [url of the actual repo] 更に詳しく知りたい場合はこの StackOverflow のトピックを参照して下さい。 Git は他の誰かのリポジトリにアクセス権なしでコードを追加することを許可していません。Github でも同様です。 Github は Git と全く同じではありませんが、 Git のホストサービスのようなものです。ただし、パッチを使用してコードを提案することができ、GitHubではフォークしたりプルリクエストを出すことができます。まず、フォークについて少々説明をしましょう。フォークはリポジトリのコピーです。これは git の操作ではありませんが、GitHub、Bitbucket、GitLab を含む Git リポジトリをホストする場所では一般的なアクションです。ホストされたUIを通してリポジトリをフォークすることができます。リポジトリをフォークした後は、通常リポジトリを自分のマシンにクローンする必要があります。例えばクローンを作成せずにGitHubを少し編集することはできますが、この文書は Github フライトルールではないので、ローカルでこれを行う方法を試してみましょう。 # ssh を使っている場合 $ git clone [email protected]:k88hudson/git-flight-rules.git # https を使っている場合 $ git clone https://github.com/k88hudson/git-flight-rules.git 作成されるディレクトリに cd して、git remote と入力すると、リモートの一覧が表示されます。通常は1つのリモート、origin があり、それはk88hudson / git-flight-rulesを指します。この場合、自分のフォークを指すリモートも欲しいと思います。まず、Gitの慣例に従い、自分のリポジトリに originというリモート名を使い、フォークしたものにupstreamを使います。 originの名前をupstreamに変更しましょう。 $ git remote rename origin upstream git remote set-urlを使ってこれを行うこともできますが、時間がかかり、手順が多いです。次に、自分のプロジェクトを指す新しいリモートを設定します。 $ git remote add origin [email protected]:YourName/git-flight-rules.git これで2つのリモートができました。 originは自分のリポジトリを参照します。 upstreamは元のリポジトリを参照します。 origin に対しては read / write することができます。 upstream に対しては read だけができます。好きなように変更を加え終わったら、変更を（通常はブランチ内から） originという名前のリモートにプッシュします。ブランチにいるのなら、このブランチを使う将来のプッシュでリモートトラッキングブランチを指定するのを避けるために --set-upstreamを使うことができます。例えば $ (feature/my-feature) git push --set-upstream origin feature/my-feature Gitを使用してCLIでプルリクエストを出す方法はありません（ただし、hubのようなツールがあります）。そのため、プルリクエストを作成する準備が整ったら、GitHub（または他のGitホスト）に移動して新しいプルリクエストを作成します。 Gitホストが自動的に元のリポジトリとフォークしたリポジトリをリンクすることに注意してください。コードレビューのフィードバックには必ず返信するようにしてください。しばらくして、 upstreamリポジトリが更新されたかもしれません。これらの更新を自分の origin リポジトリに取り込む必要があります。あなたと同様に他の人々もプロジェクトに貢献していることを忘れないでください。自分のフィーチャーブランチにいて、元のリポジトリの更新を取り込む必要があるとしましょう。恐らく元のプロジェクトを指すリモートを設定したでしょう。もしそうでなければ、今して下さい。一般的にリモートの名前として upstreamを使います。 $ (master) git remote add upstream <link-to-original-repository # $ (master) git remote add upstream [email protected]:k88hudson/git-flight-rules.git これで上流 (upstream) から fetch して最新のアップデートを入手できます。 $ (master) git fetch upstream $ (master) git merge upstream/master # 又は、一つのコマンドで行うなら $ (master) git pull upstream master 何も考えずに git commit -aを使って変更をコミットしただけで、今行ったコミットの実際の内容が何であるかはよく分からないとしましょう。現在のHEADの指す最新のコミットを表示するには (master)$ git show 又は $ git log -n1 -p とします。特定のコミットでのファイルを見ることもできます（は興味のあるコミットです）。 $ git show <commitid:filename 間違ったコミットメッセージを書いたがコミットをまだプッシュしていない場合は、コミットの修正を変更せずにコミットメッセージだけを変更することができます。 $ git commit --amend --only これによりデフォルトのテキストエディタが開き、そこでメッセージを編集できます。一方、これをすべて1つのコマンドで行うこともできます。 $ git commit --amend --only -m 'xxxxxxx' 既にメッセージをプッシュしている場合は、コミットを修正して force push することができますがお勧めしません。それが単一のコミットであれば、次のようにして修正できます。 $ git commit --amend --no-edit --author "" 別の方法としては、 git config --global author。（name | email）で作者設定を正しく設定してから次のコマンドを実行します。 $ git commit --amend --reset-author --no-edit 履歴をすべて変更する必要がある場合は、 git filter-branchのmanページを参照してください。前のコミットからファイルの変更を削除するには、次の手順に従います。 $ git checkout HEAD^ myfile $ git add myfile $ git commit --amend --no-edit ファイルが新しくコミットに追加され、それを（Gitだけから）削除したい場合は、次のようにします。 $ git rm --cached myfile $ git commit --amend --no-edit まだマージされていないパッチがあり、不要なファイルをコミットしていて、リモートでパッチを更新するために force push する必要がある場合、これは特に便利です。 --no-editオプションは既存のコミットメッセージを保持するために使用されます。プッシュされたコミットを削除する必要があるなら以下を使うことができます。しかし、履歴を不可逆的に変えてしまい、既にリポジトリから pull した他の人の履歴はめちゃくちゃになります。つまり、よく分からない場合は絶対にしないでください。 $ git reset HEAD^ --hard $ git push --force-with-lease [remote] [branch] まだプッシュしていない場合は、Gitを最後のコミットを行う前の状態にリセットします（ステージングされた変更を維持したまま）。 (my-branch*)$ git reset --soft HEAD@{1} これはプッシュしていない場合にのみうまくいきます。プッシュしていた場合、本当に安全なやり方は git revert SHAofBadCommitだけです。これにより、以前のコミットの変更をすべて元に戻す新しいコミットが作成されます。あるいは、プッシュしたブランチがリベースに対して安全な場合（つまり、他の開発者がそこから pull することは想定されていない場合）は、単に git push --force-with-leaseを使用できます。詳しくは上記のセクションを見てください。上記と同じ警告が適用されます。可能であれば絶対に行わないでください。 $ git rebase --onto SHA1_OF_BAD_COMMIT^ SHA1_OF_BAD_COMMIT $ git push --force-with-lease [remote] [branch] またはインタラクティブな rebase を実行して、削除したいコミットに対応する行を削除します。 To https://github.com/yourusername/repo.git ! [rejected] mybranch - mybranch (non-fast-forward) error: failed to push some refs to 'https://github.com/tanay1337/webmaker.org.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. なお rebase（下記参照）と同様に、amend は古いコミットを新しいものに置き換えるので、amend する前のコミットをリモートに既に push しているときは force push（ --force-with-lease）する必要があります。これを行うときは必ずブランチを必ず指定してください。 (my-branch)$ git push origin mybranch --force-with-lease 一般的に、force pushは避けてください。修正したコミットを force push するのではなく、新しいコミットを作成してプッシュすることをお勧めします。問題のブランチまたは任意の子ブランチに取り組んだ他の開発者のソース履歴に矛盾が生じるためです。他の誰か同じブランチに取り組んでいる場合、 --force-with-leaseは失敗します。誰も同じブランチで作業していないこと、またはブランチの先端を無条件でアップデートしたいことを絶対に確信している場合は、 --force（-f）を使用できます。しかし一般的には避けるべきです。誤って git reset --hardを実行しても、gitは数日間すべてのログを保存しているので、通常はまだコミットを取り戻すことができます。注意：これは作業がバックアップされている、すなわちコミットされているか stash されている場合にのみ有効です。 git reset --hardはコミットされていない変更を削除しますので、注意して使ってください。（より安全なオプションは git reset --keepです。） (master)$ git reflog 過去のコミットのリストとリセットのためのコミットが表示されます。戻りたいコミットのSHAを選択して、リセットします。 (master)$ git reset --hard SHA1234 これで大丈夫なはずです。マージする準備が整う前に誤ってフィーチャーブランチをメインの開発ブランチにマージした場合でも、マージを元に戻すことができます。しかし落とし穴があります。マージコミットには複数の親（通常は2つ）があります。使うコマンドは以下です。 (feature-branch)$ git revert -m 1 <commit ここで -m 1 オプションは、元に戻す親として親の番号1（マージが行われたブランチ）を選択するように指示します。注：親番号はコミットIDではありません。むしろ、マージコミットには Merge：8e2ce2d 86ac2e7と書かれます。親番号はこの行の目的の親の1から始まるインデックス、最初の識別子は番号1、2番目の識別子は番号2というように続きます。誤って秘密情報や個人データ（パスワード、キーなど）を含むファイルをプッシュした場合は、以前のコミットを修正できます。一度コミットをプッシュしたら、それに含まれる全てのデータが危険に晒されていると考えるべきであることを覚えておいてください。これらのステップは公開リポジトリまたは自分のローカルコピーから秘密情報を削除することができますが、他人の pull したコピーから秘密情報を削除することはできません。パスワードをコミットした場合は、すぐに変更してください。キーをコミットした場合は、すぐに再生成してください。その間に誰かが秘密情報を含む元のコミットを pull した可能性があるので、プッシュされたコミットを修正するだけでは不十分です。ファイルを編集して機密データを削除した場合は、次のコマンドを実行してください。 (feature-branch)$ git add edited_file (feature-branch)$ git commit --amend --no-edit (feature-branch)$ git push --force-with-lease origin [branch] ファイル全体を削除したい（ローカルには保持する）場合は、次のコマンドを実行します。 (feature-branch)$ git rm --cached sensitive_file echo sensitive_file .gitignore (feature-branch)$ git add .gitignore (feature-branch)$ git commit --amend --no-edit (feature-branch)$ git push --force-with-lease origin [branch] あるいは、秘密情報をローカル環境変数に格納してください。ファイル全体を完全に削除したい（ローカルにも保存したくない）場合は、次のコマンドを実行してください。 (feature-branch)$ git rm sensitive_file (feature-branch)$ git commit --amend --no-edit (feature-branch)$ git push --force-with-lease origin [branch] その間に他のコミットを行った場合（つまり、秘密情報が前回のコミットより前にコミットされている場合）、rebase する必要があります。削除したいファイルが秘密または機密である場合は、代わりに秘密情報を含むファイルをコミットして push してしまったを参照してください。最近のコミットで大きなファイルや不要なファイルを削除しても git の履歴に残っており、リポジトリの .gitフォルダに残っているので、git cloneは不要なファイルをダウンロードします。この部分のフライトルールは force push を必要とし、リポジトリの履歴の大部分を書き換えるので、遠隔地にいるコラボレーターと仕事をしているのであれば、彼らがローカルの作業をプッシュしたことを確認して下さい。履歴の書き換えには二つの選択肢があります。組み込みの git-filter-branchまたはbfg-repo-cleanerです。 bfgはとても綺麗で性能が優れていますが、サードパーティ製品をダウンロードしなければならず、javaを必要とします。両方の方法について説明します。最後のステップは、変更を force push することです。これには、大量のリポジトリの履歴が恒久的に変更されるため、通常の force push 以上に特に気をつける必要があります。 bfg-repo-cleanerを使用するにはjavaが必要です。ここからbfg jarをダウンロードしてください。私たちの例では bfg.jarを使いますが、ダウンロードしたバイナリにはバージョン番号が付いているかもしれません。例えば bfg-1.13.0.jar のように。特定のファイルを削除します。 (master)$ git rm path/to/filetoremove (master)$ git commit -m "Commit removing filetoremove" (master)$ java -jar ~/Downloads/bfg.jar --delete-files filetoremove bfgでは、サブディレクトリにある場合でも、そのままのファイル名を使用する必要があります。ファイルをパターンで削除することもできます。 (master)$ git rm *.jpg (master)$ git commit -m "Commit removing *.jpg" (master)$ java -jar ~/Downloads/bfg.jar --delete-files *.jpg bfgを使用すると、最新のコミットに存在するファイルは影響を受けません。たとえば、リポジトリに大きな.tgaファイルがいくつかあり、それらの一部を削除した場合、この呼び出しは最新のコミットにあるファイルには影響しません。コミットでファイル名を変更した場合は注意してください。元々 LargeFileFirstName.mp4で、コミットがそれをLargeFileSecondName.mp4に変更した場合、 java -jar ~/Downloads/bfg.jar --delete-files LargeFileSecondName.mp4を実行しても git の履歴から削除されません。両方のファイル名で、あるいはパターンマッチで --delete-filesコマンドを実行してください。 git-filter-branchはもっと面倒で機能も少ないですが、bfgをインストールしたり実行することができない場合は使えます。以下では、 filepatternの置き換えは特定の名前やパターンになります。例えば \*.jpg のように。これは全ての履歴とブランチからパターンにマッチするファイルを削除します。 (master)$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch filepattern' --prune-empty --tag-name-filter cat -- --all 何が起こっているかの説明： --tag-name-filter cat は面倒ですが、cat コマンドを使って元のタグを新しいコミットに付けるシンプルな方法です。 --prune-empty は全ての空のコミットを取り除きます。目的のファイルを削除したら、リポジトリのものが何も壊れていないかを慎重にテストします。壊れている場合は、リポジトリを複製して最初からやり直すのが最も簡単です。終了するには、必要に応じてgit ガベージコレクションを使用してローカルの.gitフォルダサイズを最小化してから、force push します。 (master)$ git reflog expire --expire=now --all && git gc --prune=now --aggressive (master)$ git push origin --force --tags gitリポジトリの履歴全体を書き換えたので、 git pushの操作は大きすぎるかもしれず、「リモートエンドが突然ハングアップしました」というエラーを返すかもしれません。このような場合は、git post bufferを増やしてみてください。 (master)$ git config http.postBuffer 524288000 (master)$ git push --force これでうまくいかない場合は、リポジトリの履歴を手動で分割してコミットする必要があります。以下のコマンドで、push操作が成功するまでを増やしてみてください。 (master)$ git push -u origin HEAD~<number:refs/head/master --force プッシュが最初に成功したら、通常の git pushが成功するまでを徐々に減らします。いくつか（例えば3つ）のコミットを作成した後で、最初のコミットに文脈上属していることをし忘れたことに気づいたと思います。これらの変更を含む新しいコミットを作成するのであれば、クリーンなコードベースになるはずですが、コミットはアトミックではありませんでした（つまり、お互いに属する変更が同じコミットに含まれていなかったということです）。そのような状況では、これらの変更が属するコミットを変更し、それらを含め、以降のコミットはそのままにします。そのような場合、 git rebaseは役に立つかもしれません。最後に行った3番目のコミットを変更したい状況を考えてください。 (your-branch)$ git rebase -i HEAD~4 対話的なリベースモードに入ります。このモードでは、最後の3つのコミットを編集できます。テキストエディタがポップアップして、次のようなことを表示します。 pick 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit これを以下のように変えます。 edit 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit これは、"The third last commit"を編集し、他の2つは変更しないでおくことをrebaseに伝えます。その後、エディタを保存して閉じます。 Gitはその後リベースを開始します。変更したいコミットで停止し、そのコミットを編集することができます。これで、最初にコミットをコミットしたときに適用しなかった変更を適用できます。まず編集し、ステージングします。その後以下を実行します。 (your-branch)$ git commit --amend これはGitにコミットを再度作成するように指示しますが、コミットメッセージは未編集のままにします。これで難しい部分は解決されました。 (your-branch)$ git rebase --continue これで残りの部分が実行されます。 (my-branch*)$ git commit --amend コミットメッセージを変更したくないということが分かっている場合は、gitにコミットメッセージを再利用するように指示できます。 (my-branch*)$ git commit --amend -C HEAD 通常、ファイルの一部をステージングしたい場合は、次のように実行します。 $ git add --patch filename.x -pは短く動作します。これにより対話モードが開きます。コミットを分割するために sオプションを使うことができるでしょう。しかし、ファイルが新規のものなら、このオプションはありません。新しいファイルを追加するには、以下を行います。 $ git add -N filename.x それから、追加する行を手動で選択するために eオプションを使う必要があります。 git diff --cachedを実行するか git diff --stagedはどの行がステージされたかを、ローカルに保存したものと比較して表示します。 git addはファイル全体をコミットに追加します。 git add -pで追加したい変更を対話的に選択できます。 git reset -pはパッチモードのリセットダイアログを開きます。これは git add -pに似ていますが、" yes "を選択すると変更のステージングが解除され、それが今後のコミットから削除される点が異なります。これはトリッキーです。私が知っている最も良い方法は、ステージングされていない編集をstash することです。その後、 reset してください。その後、 stash した編集をポップして追加します。 $ git stash -k $ git reset --hard $ git stash pop $ git add -A $ git checkout -b my-branch $ git stash $ git checkout my-branch $ git stash pop ーカルのステージングされた変更とステージングされていない変更を全て破棄したい場合は、次のようにします。 (my-branch)$ git reset --hard # 又は (master)$ git checkout -f これは git addでステージングした全てのファイルをアンステージします。 $ git reset これにより、コミットされていないローカルの変更が全て元に戻されます（リポジトリの��ートで実行する必要があります）。 $ git checkout . コミットしていない変更を特定のファイルまたはディレクトリに戻すこともできます。 $ git checkout [some_dir|file.txt] コミットされていないすべての変更を元に戻すもう1つの方法は（入力は長くなりますが、任意のサブディレクトリから動きます）、 $ git reset --hard HEAD これは全てのローカルの追跡されていないファイルを削除するので、Gitによって追跡されているファイルだけが残ります。 $ git clean -fd -x も全ての ignore されたファイルを消去します。作業コピーの変更の一部を削除したいが、全ては削除したくない場合です。望ましくない変更をチェックアウトし、良い変更はそのままにします。 $ git checkout -p # 削除したいコード全てに y と入力して下さい他の戦略は stashを使うことです。すべての良い変更を stash し、作業コピーをリセットし、良い変更を再度適用します。 $ git stash -p # 保存したいコード全てを選択して下さい $ git reset --hard $ git stash pop あるいは、不要な変更を stash してから、 stash を drop します。 $ git stash -p # 保存したくないコード全てを選択して下さい $ git stash drop 作業コピーから特定のファイルを削除したい場合。 $ git checkout myFile あるいは、作業コピー内の複数のファイルを破棄するには、それら全てをリストします。 $ git checkout myFirstFile mySecondFile ステージングされていないローカルのコミットされていない変更をすべて取り除きたい場合 $ git checkout . 未追跡のファイルをすべて削除したい場合 $ git clean -f 誤ってステージングされてしまった1つ以上のファイルがあり、それらのファイルが以前にコミットされていないことがあります。それらをステージングを解除するには $ git reset -- <filename これにより、ファイルのステージングが解除され、ファイルが追跡されなくなります。ローカルのブランチの一覧を見るには、 $ git branch リモートのブランチの一覧を見るには、 $ git branch -r 全てのブランチ（ローカルとリモート両方）の一覧を見るには、 $ git branch -a $ git checkout -b <branch <SHA1_OF_COMMIT git reflogを使って HEAD が誤った pull の前にどこを指していたかを見ればよいです。 (master)$ git reflog ab7555f HEAD@{0}: pull origin wrong-branch: Fast-forward c5bc55a HEAD@{1}: checkout: checkout message goes here ブランチを望ましいコミットにリセットします。 $ git reset --hard c5bc55a これで完了です。変更をサーバーにプッシュしていないことを確認してください。 git statusは何個のコミットが origin より進んでいるかを表示します。 (my-branch)$ git status # On branch my-branch # Your branch is ahead of 'origin/my-branch' by 2 commits. # (use "git push" to publish your local commits) # （リモートのものと同じにするために）origin と一致するようにリセットする方法の一つは以下を行うことです。 (master)$ git reset --hard origin/my-branch master にいる間に新しいブランチを作成します。 (master)$ git branch my-branch master を以前のコミットにリセットします。 (master)$ git reset --hard HEAD^ HEAD^は HEAD^1の略です。これは HEADの最初の親を表し、同様にHEAD^2はコミットの2番目の親を表します（マージは2つの親を持つことができます）。 HEAD^2はHEAD~2と同じではないことに注意してください（詳細はこのリンクを参照して下さい)。あるいは、HEAD^を使いたくない場合は、masterブランチに設定したいコミットハッシュを調べてください（git logで分かります）。それからそのハッシュにリセットします。 git pushでこの変更がリモートに反映します。例えば、master ブランチがいるべきコミットのハッシュが a13b85eであれば (master)$ git reset --hard a13b85e HEAD is now at a13b85e 新しいブランチをチェックアウトして作業を続けます。 (master)$ git checkout my-branch 何百もの変更を加えた、ワーキングスパイクがあり（注を参照）、全てがうまくいっているとします。さて、その作業を保存するために別のブランチにコミットします。 (solution)$ git add -A && git commit -m "Adding all changes from this spike into one big commit." それをブランチ（おそらくフィーチャーブランチか develop）に入れたいときは、ファイル全体を保存しておきたいはずです。大きなコミットを小さなコミットに分割したいのです。たとえば、スパイクの解決策を含むブランチ solution。solutionはdevelopよりも一つだけ進んでいます。変更を加えたいブランチdevelop コンテンツをブランチに持っていくことで解決できます。 (develop)$ git checkout solution -- file1.txt これでsolutionブランチのファイルの内容をdevelopmentブランチに移せます。 # On branch develop # Your branch is up-to-date with 'origin/develop'. # Changes to be committed: ..." to unstage) # # modified: file1.txt その後、いつものようにコミットします。注：スパイクソリューションは、問題を分析または解決するために作ります。ソリューションは推定に使用され、誰もが問題をはっきりと見えた時点で破棄されます。Wikipedia。 master ブランチにいるとしましょう。 git logを実行すると、2回コミットしたことがわかります。 (master)$ git log commit e3851e817c451cc36f2e6f3049db528415e3c114 Author: Alex Lee <[email protected] Date: Tue Jul 22 15:39:27 2014 -0400 Bug #21 - Added CSRF protection commit 5ea51731d150f7ddc4a365437931cd8be3bf3131 Author: Alex Lee <[email protected] Date: Tue Jul 22 15:39:12 2014 -0400 Bug #14 - Fixed spacing on title commit a13b85e984171c6e2a1729bb061994525f626d14 Author: Aki Rose <[email protected] Date: Tue Jul 21 01:12:48 2014 -0400 First commit 各バグのコミットハッシュに注目しましょう（＃21の場合は e3851e8、＃14の場合は5ea5173）。まず、master ブランチを正しいコミット（ a13b85e）にリセットしましょう： (master)$ git reset --hard a13b85e HEAD is now at a13b85e これで、バグ＃21のために新しいブランチを作ることができます。 (master)$ git checkout -b 21 (21)$ それでは、ブランチ上にあるバグ＃21のコミットをcherry-pickしましょう。つまり、そのコミットだけを適用し、そのコミットをHEAD の上に置きます。 (21)$ git cherry-pick e3851e8 この時点で、競合がある可能性があります。競合を解決する方法については、複数のコミットを一つにまとめたいの章のコンフリクトがあるのセクションを見て下さい。それでは master からバグ＃14のための新しいブランチを作成しましょう。 (21)$ git checkout master (master)$ git checkout -b 14 (14)$ そして最後に、バグ＃14のコミットを cherry-pick しましょう。 (14)$ git cherry-pick 5ea5173 GitHubでプルリクエストをマージすると、マージされたブランチをフォークから削除することができます。そのブランチで作業を続ける予定がない場合は、ブランチのローカルコピーを削除して、古くなったブランチで散らからないようにしましょう。 $ git fetch -p upstream ここで upstream は fetch したいリモートです。定期的にリモートにプッシュしているなら、ほとんどの場合なんとかなるでしょう。しかしそれでも branch を削除してしまうこともあるでしょう。ブランチを作成して新しいファイルを作成するとしましょう。 (master)$ git checkout -b my-branch (my-branch)$ git branch (my-branch)$ touch foo.txt (my-branch)$ ls README.md foo.txt add してコミットします。 (my-branch)$ git add . (my-branch)$ git commit -m 'foo.txt added' (my-branch)$ foo.txt added 1 files changed, 1 insertions(+) create mode 100644 foo.txt (my-branch)$ git log commit 4e3cd85a670ced7cc17a2b5d8d3d809ac88d5012 Author: siemiatj <[email protected] Date: Wed Jul 30 00:34:10 2014 +0200 foo.txt added commit 69204cdf0acbab201619d95ad8295928e7f411d5 Author: Kate Hudson <[email protected] Date: Tue Jul 29 13:14:46 2014 -0400 Fixes #6: Force pushing after amending commits さて、master に戻って、「誤って」ブランチを削除してしまったとします。 (my-branch)$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. (master)$ git branch -D my-branch Deleted branch my-branch (was 4e3cd85). (master)$ echo oh noes, deleted my branch! oh noes, deleted my branch! 改良されたロガーである 'reflog'に精通して下さい。リポジトリ内のすべてのアクションの履歴を保存します。 (master)$ git reflog 69204cd HEAD@{0}: checkout: moving from my-branch to master 4e3cd85 HEAD@{1}: commit: foo.txt added 69204cd HEAD@{2}: checkout: moving from master to my-branch ご覧のとおり、削除されたブランチからのコミットハッシュがあります。削除したブランチを元に戻すことができるかどうか見てみましょう。 (master)$ git checkout -b my-branch-help Switched to a new branch 'my-branch-help' (my-branch-help)$ git reset --hard 4e3cd85 HEAD is now at 4e3cd85 foo.txt added (my-branch-help)$ ls README.md foo.txt ほら！削除したファイルを元に戻せました。 git reflogはリベースがひどく間違っているときにも役に立ちます。リモートブランチを削除するには (master)$ git push origin --delete my-branch 別のやり方としては (master)$ git push origin :my-branch ローカルブランチを削除するには (master)$ git branch -d my-branch 現在のブランチや上流 (upstream) にマージされてないローカルのブランチを削除するには (master)$ git branch -D my-branch 例えば、fix/ で始まるブランチを全て消すには (master)$ git branch | grep 'fix/' | xargs git branch -d 現在の（ローカルの）ブランチの名前を変えるには (master)$ git branch -m new-name 別の（ローカルの）ブランチの名前を変えるには (master)$ git branch -m old-name new-name まずリモートから全てのブランチを fetch します。 (master)$ git fetch --all 例えば、リモートにあるブランチdavesをチェックアウトしたいとします。 (master)$ git checkout --track origin/daves Branch daves set up to track remote branch daves from origin. Switched to a new branch 'daves' (--track is shorthand for git checkout -b [branch] [remotename]/[branch]) これでローカルにブランチdavesをコピーします。リモートにプッシュされた更新も表示されます。 $ git push <remote HEAD もしリモートのブランチを現在のブランチの上流 (upstream) として設定もしたいなら、代わりに以下のコマンドを使います。 $ git push -u <remote HEAD push.defaultがupstreamモードとsimpleモード (Git 2.0 のデフォルトの設定です）になっていると、-uで登録されていたリモートブランチに現在のブランチをプッシュします。 $ git push git pushの他のモードの振る舞いは push.defaultのドキュメントに記載されています。次のようにして、リモートブランチを現在のローカルブランチの上流 (upstream) として設定できます。 $ git branch --set-upstream-to [remotename]/[branch] # 又は以下の略記も使えます $ git branch -u [remotename]/[branch] 上流のリモートブランチを別のローカルブランチに設定するには $ git branch -u [remotename]/[branch] [local-branch] リモートブランチをチェックすることによって、HEAD がどのリモートブランチを追跡しているかを見ることができます。場合によっては、望ましいブランチではありません。 $ git branch -r origin/HEAD - origin/gh-pages origin/master origin/HEAD がorigin/masterを追跡するように変更するには、次のコマンドを実行します。 $ git remote set-head origin --auto origin/HEAD set to master 変更をしたがまだコミットしていない段階で、間違ったブランチにいることに気づきました。変更を stash して必要なブランチに適用します。 (wrong_branch)$ git stash (wrong_branch)$ git checkout <correct_branch (correct_branch)$ git stash apply 現在のブランチに間違ったブランチをマージしたりリベースしたのに、何が起きたか理解できなかったりリベースやマージを完了することができないことがあります。 Gitは危険な操作をする前に元のHEADポインタをORIG_HEADと呼ばれる変数に保存するので、リベース/マージの前の状態にブランチを復元するのは簡単です。 (my-branch)$ git reset --hard ORIG_HEAD 残念ながら、それらの変更をリモートブランチに反映させたい場合は、 force push する必要があります。履歴を変えたからです。 force push しない限り、リモートブランチは変更を受付けません。これが、多くの人がリベースワークフローではなくマージワークフローを使用する主な理由の1つです。大規模なチームが開発者の force push で問題に陥る可能性があります。これするときは慎重になってください。リベースを使用するより安全な方法は、リモートブランチに変更をまったく反映させず、代わりに以下をすることです： (master)$ git checkout my-branch (my-branch)$ git rebase -i master (my-branch)$ git checkout master (master)$ git merge --ff-only my-branch この StackOverflow のスレッドを参照して下さい。 masterに対するプルリクエストとなるブランチに取り組んでいるとしましょう。最も簡単な場合は、全てのコミットを1つにまとめてコミットタイムスタンプを気にする必要がない場合で、リセットして再度コミットできます。 master ブランチが最新のものであり、すべての変更がコミットされていることを確認してください。 (my-branch)$ git reset --soft master (my-branch)$ git commit -am "New awesome feature" もっと細かく制御したい、そしてタイムスタンプを保持したいのなら、インタラクティブリベースをする必要があります。 (my-branch)$ git rebase -i master もし他のブランチに対して作業をしていないのであれば、HEADを基準にして rebase する必要があります。たとえば、最後の2つのコミットを squash したい場合は、 HEAD~2に対してリベースする必要があります。最後の3つをするなら、HEAD~3となります。 (master)$ git rebase -i HEAD~2 インタラクティブな rebase コマンドを実行すると、テキストエディタに次のようなものが表示されます。 pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature pick b729ad5 fixup pick e3851e8 another fix # Rebase 8074d12..b729ad5 onto 8074d12 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out ＃で始まる行はすべてコメントで、リベースには影響しません。 pickコマンドを上の一覧のどれかに置き換えたり、対応する行が削除してコミットを削除することができます。たとえば、最も古い（最初の）コミットをそのままにして、その後に続くすべてのコミットを2番目に古いコミットと結合する場合は、最初と2番目以外の各コミットの横の文字を編集して fとします。： pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature f b729ad5 fixup f e3851e8 another fix これらのコミットを組み合わせてコミットの名前を変更したい場合は、2番目のコミットの隣にさらに rを追加するか、単にfの代わりに sを使用してください。 pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature s b729ad5 fixup s e3851e8 another fix ポップアップされる次のテキストプロンプトでコミットの名前を変えられます。 Newer, awesomer features # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # rebase in progress; onto 8074d12 # You are currently editing a commit while rebasing branch 'master' on '8074d12'. # # Changes to be committed: # modified: README.md # すべてが成功すれば、次のようになるはずです。 (master)$ Successfully rebased and updated refs/heads/master. --no-commitはマージを実行しますが、失敗したマージのように見せかけて自動コミットしないので、コミットする前にマージ結果を調べてさらに微調整することができます。 no-ffはフィーチャーブランチがかつて存在していたという証拠を維持し、プロジェクト履歴を一貫したものにします。 (master)$ git merge --no-ff --no-commit my-branch (master)$ git merge --squash my-branch 上流 (upstream) にプッシュする前に一つにしたいいくつかの進行中のコミットを持っていることがあります。すでに上流にプッシュされているコミットを誤って一つにしたくない場合があります。他の誰かがすでにそれらを参照するコミットをした可能性があるからです。 (master)$ git rebase -i @{u} プッシュしていないコミットだけの一覧を表示し、対話的なリベースが始まるでしょう。安全に一覧の中のコミットを並べ替え/修正/squash することができます。マージによって特定のファイルに問題が発生することがあります。その場合はオプション abortを使って現在の競合解決プロセスを中止し、マージ前の状態を再構築します。 (my-branch)$ git merge --abort このコマンドはバージョン 1.7.4 以上の Git で使えます。 master ブランチ、master から分岐したfeature-1ブランチ、およびfeature-1から分岐したfeature-2ブランチがあるとします。 feature-1にコミットすると、feature-2の親のコミットは正確ではなくなります（feature-2 はfeature-1 から分岐したので、feature-2 の親は feature-1の先頭になるはずです）。これを git rebase --ontoで修正できます。 (feature-2)$ git rebase --onto feature-1 <the first commit in your feature-2 branch that you don' feature-2 まだマージされていない別のフィーチャーブランチからフィーチャーブランチを切り、feature-1 ブランチのバグ修正をfeature-2ブランチに反映させる必要がる厄介な場合にこの方法は役に立ちます。ブランチ上のすべてのコミットが別のブランチにマージされているかどうかを確認するには、それらのブランチの先頭（または任意のコミット）の間で差分をとる必要があります。 (master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll 一方にコミットがあり、他方にはコミットがないかかを表示し、ブランチ間で共有できていない行の一覧を表示します。もう1つの選択肢は次のようにすることです。 (master)$ git log master ^feature/120-on-scroll --no-merges 次のようなメッセージを見たとします。 noop これは、同じコミットのブランチ、または現在のブランチよりも進んでいるブランチに対して rebase しようとしているということです。次のことをしてみましょう。 master ブランチがしかるべき場所にあることを確認する代わりに HEAD~2以前に対して rebase する rebase を正常に完了できない場合は、競合を解決する必要があります。最初に git statusを実行してどのファイルが競合しているのかを確認してください。 (my-branch)$ git status On branch my-branch Changes not staged for commit: (use "..." to update what will be committed) (use "..." to discard changes in working directory) both modified: README.md この例では、 README.mdが競合しています。そのファイルを開き、以下を探します。 <<<<<<< HEAD some code ========= some code new-commit 新しいコミットで追加されたコード（この例では、中央の行から new-commitまでの行すべて）とHEADの diff を解決する必要があります。あるブランチのバージョンのコードをチェックアウトしたい場合は、 --oursまたは--theirsを使います。 (master*)$ git checkout --ours README.md マージするときは、ローカルブランチからの変更を保持するには --oursを、他のブランチからの変更を保持するには--theirsを使用します。 rebase するときは、ローカルブランチからの変更を保持するには --theirs、他のブランチからの変更を保持するには--oursを使用します。なぜ逆になるかの説明は、Gitドキュメントのこのメモを参照してください。マージがもっと複雑な場合は、視覚的な diff エディタを使用できます。 (master*)$ git mergetool -t opendiff すべての競合を解決してコードをテストしたら、変更したファイルを git addしてからgit rebase --continueで rebase を続けます。 (my-branch)$ git add README.md (my-branch)$ git rebase --continue すべての衝突を解決した後でコミット前と同じツリーになった場合は、代わりに git rebase --skipを実行する必要があります。リベースを中止してブランチの元の状態に戻りたい場合は、いつでも次のようにして中止できます。 (my-branch)$ git rebase --abort 作業ディレクトリのすべての編集内容を stash するには $ git stash 追跡されていないファイルも stash したい場合は、-uオプションを使用してください。 $ git stash -u 作業ディレクトリからファイルを1つだけ stash するには $ git stash push working-directory-path/filename.ext 作業ディレクトリから複数のファイルを stash するには $ git stash push working-directory-path/filename1.ext working-directory-path/filename2.ext $ git stash save <message まずメッセージ付きの stash の一覧を確認して下さい。 $ git stash list そして一覧から特定の stash を適用します $ git stash apply "stash@{n}" ここで 'n'はスタック内の stash の位置を示します。一番上の stash は位置0になります。任意のコミットで入れられた特定の文字列を検索するために、以下の仕組みを使うことができます： $ git log -S "string to find" 共通のパラメータ： --sourceは各コミットが達成されたコマンドラインで与えられた参照名を表示することを意味します。 --allは全てのブランチから始まることを意味します。 --reverseは逆の順番で表示します。つまり、変更を加えた最初のコミットを表示します。作者/コミッタごとにすべてのコミットを見つけるには、次のコマンドを使用できます。 $ git log --author=<name or email $ git log --committer=<name or email 作者とコミッタは同じではないことに留意してください。 --authorは最初にコードを書いた人です。一方、 --committerは最初の作者の代わりにコードをコミットした人です。特定のファイルを含むすべてのコミットを見つけるには、次のコマンドを使用できます。 $ git log -- <path to file 通常は正確なパスを指定しますが、パスとファイル名にはワイルドカードを使用することもできます。 $ git log -- **/*.js ワイルドカードを使用するとき、コミットされたファイルの一覧を見るために --name-statusを使うと便利です。 $ git log --name-status -- **/*.js ある関数の変化を追跡するには、次のようにします。 $ git log -L :FunctionName:FilePath revision rangeやcommit limitsのようなgit logのオプションを更に組み合わせることができます。特定のコミットを含むすべてのタグを見つけるには $ git tag --contains <commitid $ git clone --recursive git://github.com/foo/bar.git もし既にクローンしているなら $ git submodule update --init --recursive サブモジュールを作成するのはとても簡単ですが、削除するのはそれほど簡単ではありません。必要なコマンドは次のとおりです。 $ git submodule deinit submodulename $ git rm submodulename $ git rm --cached submodulename $ rm -rf .git/modules/submodulename まずファイルが存在した最後のコミットを見つけます。 $ git rev-list -n 1 HEAD -- filename そのファイルをチェックアウトします。 git checkout deletingcommitid^ -- filename $ git tag -d <tag_name $ git push <remote :refs/tags/<tag_name すでに削除されたタグを復元したい場合は、次の手順に従えばできます。まず、到達不能なタグを見つける必要があります。 $ git fsck --unreachable | grep tag タグのハッシュを書き留めます。その後、git update-refを利用して、削除したタグを次のように復元します。 $ git update-ref refs/tags/<tag_name タグは復元されたはずです。誰かが GitHub でプルリクエストを送ってから、元々のフォークを削除した場合、そのリポジトリをクローンすることも、[giff am]を.diff、.patchとして使うこともできないでしょう。しかし、GitHubの特殊な参照を使ってPR自体をチェックアウトすることができます。 PR＃1の内容をpr_1という新しいブランチに fetch するには、次の手順を実行します。 $ git fetch origin refs/pull/1/head:pr_1 From github.com:foo/bar * [new ref] refs/pull/1/head - pr_1 $ git archive --format zip --output /full/path/to/zipfile.zip master ブランチと同じ名前のタグがリモートリポジトリにある場合、標準のコマンドでそのブランチを push しようとすると以下のエラーが発生します。 $ git push origin <branch error: dst refspec same matches more than one. error: failed to push some refs to '' これを修正するには、ヘッド参照を push するように指示します。 $ git push origin refs/heads/<branch-name ブランチと同じ名前のリモートリポジトリにタグをプッシュしたい場合は、同様のコマンドを使用できます。 $ git push origin refs/tags/<tag-name (master)$ git mv --force myfile MyFile (master)$ git fetch --all (master)$ git reset --hard origin/master (master)$ git rm --cached log.txt 必要なコミットのハッシュがc5f567であると仮定します。 (master)$ git checkout c5f567 -- file1/to/restore file2/to/restore c5f567の前に1コミットだけ行った変更に戻したい場合は、コミットハッシュをc5f567~1として渡します。 (master)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore 前回のコミットとコミットc5f567のファイルを比較したいとします。 $ git diff HEAD:path_to_file/file c5f567:path_to_file/file ブランチに対しても同様です。 $ git diff master:path_to_file/file staging:path_to_file/file これは、設定のテンプレートや、コミットしてはいけない秘密情報をローカルに追加する必要がある場合に役に立ちます。 $ git update-index --assume-unchanged file-to-ignore これはソース管理からファイルを削除しないことに注意してください。ローカルでのみ無視されます。これを元に戻して、Gitに変更に再び気付くように指示するために、ignore フラグをクリアします。 $ git update-index --no-assume-unchanged file-to-stop-ignoring git-bisectコマンドは二部探索を使用して、Git履歴のどのコミットがバグを引き起こしたかを見つけます。 masterブランチにいて、何らかの機能を壊したコミットを見つけたいとしましょう。二等分をし始めます。 $ git bisect start そして、どのコミットが悪いのか、どのコミットが良いと分かっているのかを指定する必要があります。あなたの現在のバージョンが悪く、 v1.1.1が良いと仮定します。 $ git bisect bad $ git bisect good v1.1.1 git-bisectは今指定した範囲の真ん中でコミットを選択しチェックアウトして、それが良いか悪いかを尋ねます。次のようなものが出るはずです。 $ Bisecting: 5 revision left to test after this (roughly 5 step) $ [c44abbbee29cb93d8499283101fe7c8d9d97f0fe] Commit message $ (c44abbb)$ 今度はこのコミットが良いのか悪いのかを確認します。もしそれが良ければ $ (c44abbb)$ git bisect good そして git-bisectは範囲から別のコミットを選択します。このプロセス（ goodまたはbadを選択する）は、検査するリビジョンがなくなるまで繰り返され、最後に最初の悪いコミットの説明が出力されます。 OS XとLinuxでは、git設定ファイルは ~/.gitconfigに格納されています。私がショートカットとして[alias]セクションで使用するエイリアスの例（及び私がよく犯してしまうタイプミス）を以下に挙げます。 [alias] a = add amend = commit --amend c = commit ca = commit --amend ci = commit -a co = checkout d = diff dc = diff --changed ds = diff --staged extend = commit --amend -C HEAD f = fetch loll = log --graph --decorate --pretty=oneline --abbrev-commit m = merge one = log --pretty=oneline outstanding = rebase -i @{u} reword = commit --amend --only s = status unpushed = log @{u} wc = whatchanged wip = rebase -i @{u} zap = fetch -p day = log --reverse --no-merges --branches=* --date=local --since=midnight --author=\"$(git config --get user.name)\" delete-merged-branches = "!f() { git checkout --quiet master && git branch --merged | grep --invert-match '\\*' | xargs -n 1 git branch --delete; git checkout --quiet @{-1}; }; f" できません。 Gitはこれをサポートしていませんが、ハックがあります。ディレクトリに次の内容の.gitignoreファイルを作成できます。 # ディレクトリ下の全てのファイルを ignore する * # ただしこのファイルは除く !.gitignore もう1つの一般的な慣習は、.gitkeepという名前の空のファイルをフォル��内に作成することです。 $ mkdir mydir $ touch mydir/.gitkeep ファイルの名前を.keepとすることもできます。その場合、上の2行目は touch mydir/ .keepになります。認証が必要なリポジトリがあるかもしれません。その場合、ユーザー名とパスワードをキャッシュすることができるので、プッシュとプルのたびにそれを入力する必要はありません。認証情報ヘルパーがこれをやってくれます。 $ git config --global credential.helper cache # git に認証情報をキャッシュさせる $ git config --global credential.helper 'cache --timeout=3600' # キャッシュは一時間だけ有効（秒で指定する）認証情報ヘルパーを検索するには $ git help -a | grep credential # 認証ヘルパーの候補を表示する OS 固有の認証情報のキャッシュは $ git config --global credential.helper osxkeychain # OS X 向け $ git config --global credential.helper manager # Windows 2.7.3+ 向けの Git $ git config --global credential.helper gnome-keyring # Ubuntu や他のGNOMEベースのディストリビューション様々なディストリビューションやオペレーティングシステムに対して、もっと多くの認証ヘルパーが見つかるかもしれません。 $ git config core.fileMode false これをログインユーザーのデフォルトの動作にしたい場合は、次のようにします。 $ git config --global core.fileMode false 全てのローカルリポジトリで使用されるユーザー情報を設定し、バージョン履歴を確認するときにクレジットとして分かる名前を設定するには $ git config --global user.name “[firstname lastname]” 各履歴マーカーに紐付けられるE メールアドレスを設定するには git config --global user.email “[valid-email]” 簡単にレビューできるようにGitの自動のコマンドラインカラーリングを設定するには $ git config --global color.ui auto つまり、あなたは混乱してしまいました。何かを「リセット」したか、間違ったブランチをマージしたか、あるいは force push してコミットを見つけることができません。ある時点で、大丈夫だったことを知っています。そして以前の状態に戻したいと思っているとします。こういう時 git reflogはうってつけです。 reflogは、たとえその先端がブランチやタグによって参照されていなくても、ブランチの先端に対するいかなる変更も追跡します。基本的に、HEADが変わるたびに、新しいエントリがreflogに追加されます。残念ながら、これはローカルリポジトリでのみ機能し、動きだけ追跡します（例えば、どこにも記録されていないファイルへの変更は追跡されません）。 (master)$ git reflog 0a2e358 HEAD@{0}: reset: moving to HEAD~2 0254ea7 HEAD@{1}: checkout: moving from 2.2 to master c10f740 HEAD@{2}: checkout: moving from master to 2.2 上のreflogはmasterから2.2ブランチへのチェックアウトとその逆のチェックアウトを示しています。そこから、古いコミットへのハードリセットがあります。最新の動きは HEAD @ {0}とラベルされた一番上に表示されます。誤って戻ったことが判明した場合は、、誤って2つのコミットを削除する前の（0254ea7）を指すコミットマスターがreflogに含まれます。 $ git reset --hard 0254ea7 git resetを使うと、master を以前のコミットに戻すことができます。これは、履歴が誤って変更された場合の安全策となります。（Sourceからコピーして編集しました）。上記のコマンドの動作に慣れたら、Git Bashのショートカットをいくつか作成したくなるかもしれません。これにより、複雑な作業を、本当に短いコマンドで、本当に素速く行えるようになります。 alias sq=squash function squash() { git rebase -i HEAD~$1 } これらのコマンドを .bashrc や .bash_profileにコピーして下さい。 WindowsでPowerShellを使用している場合は、エイリアスと関数も設定できます。これらのコマンドをプロファイルに追加してください。そのパスは $ profile変数で定義されています。 MicrosoftのドキュメントサイトのAbout Profilesページで詳細を確認してください。 Set-Alias sq Squash-Commits function Squash-Commits { git rebase -i HEAD~$1 } GitKraken - Windows、MacおよびLinux用の、実に豪華なGitクライアント git-cola - WindowsとOS X用の別のGitクライアント GitUp - Git の複雑さへの独特の対処策を備えた新しいGUI gitx-dev - OS X の別のグラフィカルなGit クライアント Sourcetree - Windows と Mac 向けの美しさを兼ね備えた無料のパワフルなGit GUI Tower - OS X 向けのグラフィカルなGitクライアント (有料) tig - ターミナルのテキストベースのGitインターフェース Magit - Emacs パッケージとして実装されたGitのインターフェース GitExtensions - シェル拡張、Visual Studio 2010-2015プラグイン、スタンドアロンのGitリポジトリツール Fork - 速くてフレンドリーなMac向けのGUI クライアント (ベータ版） gmaster - 3者間マージ、リファクタリングの分析、セマンティックdiff、およびマージができるWindows 向けのGitクライアント（ベータ版） gitk - リポジトリの状態を簡潔に表示できるLinux向けのGitクライアント。 SublimeMerge - 3者間マージ、強力な検索およびシンタックスハイライトを提供する、非常に高速で拡張可能なクライアント（アクティブに開発中）。

#LABOT 機械学習エンジニアブログ

0 notes